Fast Mode Implementation

[andrewvh4]

I'm having trouble getting Fast Mode working on Linien. We are generating the Sweep through Linien and Demodulating using an external device. When I plug the output of this device into In2, I see a nice Demodulated PDH signal:

When I plug into Ch1 in normal mode, I do not see the PDH signal (I assume because it is performing a second demodulation on an already demodulated signal):

However, when I then enable "Fast Mode", the waveform does not change and I don't have anything to lock to:

Am I missing something here? The documentation states to connect the error signal to "Fast In 1", however when I do that, I do not see an error signal on the monitor to which I can lock.

[systemofapwne]

The UI is still a bit buggy: Some settings are not ignored or unchangeable, if Fast-Mode is enabled.
What you want to do is setting the Modulation Frequency to 0 MHz:

I was able to reproduce your issue in our lab when the modulation frequency is non-zero.

[bleykauf]

@andrewvh4: Thanks for pointing this problem out! I would also suggest that you try setting the modulation frequency to 0. This should disable modulation/demodulation also if "fast mode" is not enabled.

In any case, as @systemofapwne correctly pointed out, the modulation settings should be grayed out. However, the fact that the modulation frequency does have an effect points to a deeper issue. In "fast mode" demodulation should be bypassed completely.

[andrewvh4]

Thank you. I followed your instructions and was able to view the PDH signal and get a lock.
It's not a huge deal for our current system, but I'm curious if the input signal is still going through the Demodulator when we are in fast mode, thereby incurring the demodulation latency.

It might be helpful to make this step clearer in the Fast mode documentation.

[systemofapwne]

In principle, the demodulation unit should be omitted in Fast-Mode with having the demodulation frequency set to zero. At least the behavior of how the signal looks and the RPy reacting speaks for this. If you want absolute certainty about any delays introduced by the FPGA, you might want take a look at the gateware code (the FPGA's "firmware" so to say), because this dictates, how the signal processing is performed.

[andrewvh4]

We also observed the same issue with other parameters in the modulation module (such as modulation amplitude). It may be helpful to go through the modulation module and make sure default values are set appropriately when fast mode is selected.

[bleykauf]

Since it is a common issue, I mention problems with fast mode in the README now, see #331

[andrewvh4]

I observed another issue with the fast mode settings.
Using Linien 0.7.0.

Here is the signal I am trying to lock:

I am setting a signal offset and using a manual lock.

With fast mode disabled:

With fast mode enabled:

It's as if the signal offset value is getting set to 0, preventing the integrator from changing signs

[bleykauf]

The new release 0.80 addresses the initial issue; modulation/demodulation is now automatically disabled if fast mode is used.

@andrewvh4 Regarding the offset: we tried to remove as much from the signal chain as possible to increase bandwidth. However, I do see that adding a manual offset might still be useful as you describe. I doubt that I will look too much into this and test the influence on the bandwidth but I encourage you to have a look into the gateware and adjust it accordingly.

Closing this issue since the original problem has been addressed. Opened #345 regarding the offset issue.