Setting Urukul Channels independently

Kaisky

We're using the RAM feature on two Urukul channels for our laser lock. It's running in looped mode.
When we set another frequency or write the register for a frequency Sweep on another channel, the first two channels always get interrupted and the lock fails.

We made similar observations when just using normal frequency and sweep mode in parallel on two channels.

I believe the cause is that the neccessary
self.urukul0_ch0.cpld.io_update.pulse_mu(8)
call applies to all 4 channels because they share the same CPLD.

Is there a workaround to configure the CPLD to only update certain channels?

dpn

You might be able to use the MASK_NU bits for the channels in question to turn off forwarding of the IO_UPDATE signal (see https://github.com/quartiq/urukul/blob/af67d56c0158d61d0232a491cf123a5e6767ecbf/urukul.py for the relevant CPLD code).

Kaisky

I've tried setting the mask_nu in the urukul.cpld.cfg_reg. It seems to be all 0 by default anyway and changing it didn't seem to help.

Here I'm trying to visualize the issue:
Channel A: UrukulCH0 in RAM-Mode, 10MHz with +-1MHz frequency Modulation
Channel B: UrukulCH1 in RAM-Mode, 0MHz with 1Mhz sawtooth phase modulation (so its phaselocked to the modulation in channel A, both running on same profile)
Channel C: UrukulCH2 in Sweep Mode, initating sweep from 20MHz down to 10MHz in the moment of trigger
Channel D: ttl0 as trigger

As you can see, there is a phase-jump for channel A and B the moment we're instructing UrukulCH2 to start a sweep. It seems like the RAM-counter (which goes from 0 to 1024) resets, since CH1 phase is only dependend on that.

In the script executed here Channel 0 and 1 are not touched except their CPLD through an io update pulse for initiating the sweep on Channel 2. I'm also not calling any init function.

dpn

I am not using continuous updates in my experiments, so am not too familiar with the details. But if IO_UPDATE causes the discontinuity, surely turning off forwarding of that by setting high the mask bits would have to cause it to disappear? From a quick look at the CPLD code, it really seems like it ought to work (the mask is inverted; 1 means "soft" control via the CPLD register), but you might want to double-check that or measure on the PCB.

Kaisky

I didn't invert the bits.
Thanks for the help,
it seems to work now.