PLL poluted by laser sidebands

[ALartaux]

Hi,

We have a set up to phase lock two IR laser heads using a RedPitaya. However, for experimental reasons, we need to lock them using green beams produced by SHG on both IR laser. The SHG are inside cavities locked using PDH with sidebands which leads us to have on our PLL detection photodiode :

• a main green beam with sidebands at +/- 12.4 MHz (and weaker sidebands at +/- 24.8 MHz)
• an auxiliary green beam with sidebands at +/- 50 MHz (and weaker sidebands at +/- 100 MHz)

We want to phase lock both lasers with a frequency shift of 40 MHz on the green carriers. Do to so we tuned the auxiliary laser head crystal temperature to be close enough to the 40 MHz frequency shift, so that we can use this same laser head PZT to do the PLL.

After alignment of the main and auxiliary beams on the photodiode, using the spectrumanalyser on the RedPitaya we can see the different beatnotes present (the stronger one is between the two carriers) mainly from sidebands.

So when we use the pfd tool on an iq to derive an error signal for the PLL, when scanning the laser PZT, we have too much zero crossing with some of them due to the sidebands. Consequently, to lock on the carrier beatnote at the chosen frequency shift, we have to first tune the PZT starting offset to be close to the correct zero-crossing.

Do you have an idea of a way to do the PLL everytime on the carrier beatnote without having to manually find the starting offset, not being stuck by a sideband beatnote ?

Angélique

[lneuhaus]

If I understand correctly, you always want to lock the highest peak to 40 MHz.

If this peak is initially too far from that value, I suggest doing a pre-alignment step using python, i.e. take the spectrum, identify the largest peak, modify the actuator voltages, and repeat until the peak is reasonably close to 40 MHz.

For the actual lock, I suggest using a second (so far unused) IQ module as tuneable band-pass filter around the peak. Looking at https://pyrpl.readthedocs.io/en/latest/gui.html#iq-widget, I would aim for settings around the following:

• input: in1
• acbandwidth >1 MHz
• frequency 39 MHz (maybe still better to not exactly set the center frequency to the PLL frequency,in case a small offset causes a peak at the demodulation frequency)
• bandwidth 5 MHz for both settings (to suppress the sideband peaks)
• output_signal: output_direct
• amplitude and quadrature factor: 0
• gain 1 (you probably need to play with this value to optimize the peak amplitude, by looking at the spectrum analyzer with input set to this iq module)

You should see a bandpass filter attenuating everything that is not your central peak. With that as the input to the PDF, things might get a little better.

An alternative approach could be locking at a quadrature of the input demodulated at 40 MHz, but the actuators will likely be too slow to keep the phase fluctuations below pi/2, where this would make sense.

Also please not that the PFD uses a very trivial algorithm. There have been discussions in issues here about improving that, just never had time for this. There is however another project that might be better suited for this particular application: see https://www.nist.gov/services-resources/software/fpga-based-digital-control-box-phase-stabilization-frequency-comb

[lneuhaus]

I think you might not see a free IQ module to use as bandpass. In that case, just don't use the network analyzer, and right-click "free" on the iq module used for the NA, and reconfigure it.

[ALartaux]

Thank you for your answer. We see with Samuel and Michael for the python step. For the bandpass filter, we saw that the best bandwidth was around 1 MHz (with an order 4).

[alexandrejourneaux]

Hi, Alexandre and Samuel here ! we are following up on this problem. Up to now, thing have worked quite well with what you suggested (adding a bandpass filter centered around 40 MHz). We can now lock the 2 lasers' beatnote with a precision of a fraction of a radian.

As you pointed out in your previous post, now we believe we are limited by what you call the "trivial algorithm" for the PFD. Essentially, the dephasing between the beatnote and the 40 MHz reference is encoded as a kind of "pulse width modulation" on the pfd signal (the signal jumps for a fraction of the cycle to +1 if the frequency reference is in advance, or to -1 if it is retarded). However, as there are only a small number of 8 ns intervals in the 40 MHz period (25 ns), we can only tell that the two signals are starting to dephase when their phase difference reaches 2 pi 8 / 25 approx pi/2 (things should work better if one tries to lock the beatnote at a smaller frequency though...).

We have been able to make a "proof of concept" lock in the lab where we sum up the pfd error signal with the quadrature signal from another iq. The idea is that the pfd stabilizes below +-pi/2 phase excursion (with a large feedback bandwidth), while the quadrature signal does the stabilization in the region where the PFD is not sensitive (with a slow bandwidth).

That seems to work quite well, however this uses many resources (in fact we had to chain 2 redpitayas together plugging the analog output of the first one into the analog input of the second to have enough resources).

We are quite motivated to add the necessary changes in the hardware to make a large dynamic range pfd error signal available (going from many times 2 pi down to a fraction of 2 pi). As you know, we are very far from being experts in the FPGA development, but given our first "analog test", we are quite confident that relatively simple solutions might do the trick (for instance, replacing the current pfd output by a signal that would be the concatenation of the 7 Least Significant Bits of the current pfd with the 7 most significant bit of the quadrature error signal.

We have been also looking at the paper you referenced above, clearly, all the beauty resides in the extraction of the Arctan, that allows to have a perfectly linear error signal over many times 2 pi phase interval. Unfortunately, we have no clue (even after looking at their source code), how this arctan is calculated. A good approximation of Arctan over a small region would be I/Q, but I don't know if this calculation would be doable in real time (ideallly a single clock cycle)...

I am willing to invest some time on that problem, and I would be very interested to have your feedback before choosing one or the other direction.

[SamuelDeleglise]

OK, I believe the arctan extraction is done via the CORDIC algorithm. Basically, any angle is reached by iteratively rotating the coordinate system by an easily calculable rotation, using tabulated values of arctan (2^-n). More precise descriptions here...

Probably the algorithm is already built-in xilinx developpement tools ?!

The only drawback is that it has a latency that seems to be comparable to the number of bits in the angle, but it is fully piplineable. I guess that would not be a major problem to have approx ten bits latency in the PFD signal (anyways, the quadrature filter is already dominating the latency)... Again, I have no experience with developing fpga code but I have the feeling this would be the right way to go (at least the cleanest solution ...)