I looked at the amount of residual AM left by the south path 14.75 MHz EOM. This is a concern as it will add some offset to the error signal when mixed down along side the field that has interrogated the refcavs. It can be measured directly by offsetting the reference cavity away from any refinances and viewing the PD RF signal on a spectrum analyzer. Previously this value had been as low as -112 dBm (see PSL:1382). When I measured it it was ~ -35 dBm. This is will be a slightly different number depending on total power etc, but that value was too high.
I installed a lambda/4 plate before the 14.75 MHz EOM in the south path and fine tuned between the lambda/2 and lambda/4 plates until the residual RF power was -100 dB. I doubt it will stay at this value with temperature variations of the EOM and wave plates, but it is now much closer to ideal. This is something to tune up closer to a science measurement.
I will check the north path tomorrow.
--
It was now possible to lock the south path with reasonable gain (I didn't take a transfer function for UGF). However, we are now limited by ringing in the loop at ~30 kHz. This was the original problem I started with. When I checked BB EOM used for HF actuation it was railed at its upper rail. Shifting around the offset didn't seem to get it off this. I'm not really sure what is going on here. It could be that the gain combinations (both <300-400 clicks at the moment) are not providing enough gain for the high frequency EOM part of the loop to take over in that part of the frequency domain. There is frustratingly no adjustability at the very high frequencies or ablity to turn it off for diagnostic purposes. What I found about 1.5 weeks ago was that there was some ringing that counterintuitively went away once I got the gain high enough. Maybe this is because the EOM can then take over.
--
Koji came to the lab to help me diagnose why no error signal was being produced. I had forgotten that the 'test' switch we use to disengage the loop also turns off the error signal. Stupid. You have to physically unplug something to break the loop properly. So much about this design doesn't make sense to me.
| Quote: |
|
After another couple of restarts I found that the output channels were not responding to changes of values of their associated soft channels (the human friendly channel names). Pinging the IP address of the output acromag card at 10.0.0.41 yielded no response. Turned the whole chassis acromag power on and off and found it responsive after that. I must have restarted modbusApp over fifty times in the last week, maybe it wasn't happy on one exit and froze up.
As a side note: when I load the outputs with 50Ω (internal setting on oscilloscope) the output looks fine. When I switch back to 1 MΩ loading it has a bunch of drift/noise (only looked in time domain). Not sure what this means, I didn't think they needed to be loaded.
|
|