Restore Urukul Switch TTL MonInj

[connorgoham]

ARTIQ Feature Request

Problem this request addresses

As of ARTIQ 7 (specifically I believe commit 4ede14b) MonInj control of the urukul switches seems to have been removed. Was there a specific reason for this? If not, may it be restored?

Describe the solution you'd like

Restoration of MonInj override for the urukul switch TTLs.

[Spaqin]

The reason for this change is that for controlling DDS output, you should be using the DDS tab. Having both the TTL option and DDS (CPLD) could cause confusion, where toggling one of the switches would have no effect.

DDS tab allows you to change the output frequency and toggle the output. In order to also work with Urukul cards connected with just 1 EEM that do not have TTL switch available, both 1 and 2-EEM cards use only the CPLD to toggle the output with moninj.

Of course I'm open to potentially changing it again, but I'd like to hear why the DDS tab is not enough. If you are using the dashboard, RF switching speed shouldn't be of concern.

[connorgoham]

Thank you for the thoughtful response. I was specifically asking about MonInj for the switch TTL, not the DDS. Some relevant points for why I argue this MonInj functionality should be restored:

Unfortunately from my day-to-day experience, the current implementation of the urukul MonInj as a whole results in extremely limited (actually IMHO no) utility. I can generally imagine two use cases of MonInj:

1. manually setting the DDS parameters (a convenient use case)
2. providing "monitoring" or overriding control of the urukul output (IMHO the much more important use case)

For case 1, the urukul widget does not provide sufficient control (#2361) of the DDS to be useful (no control of amplitude, or attenuation), and as a result in my experience it is better to write a standard ARTIQ experiment one submits themselves to achieve this manual control.

As for use 2, with the loss of the switch TTL MonInj, the current implementation offers neither proper monitoring nor injection of the urukul output state:

• Monitoring is currently limited to the DDS frequency setting, not the switch state, which is necessary for quickly determining if the channel is outputting RF without walking over to the core device to look at the switch LED.
• As for proper "overriding" injection functionality, there is now none at all for urukul. AFAICT using the "set" feature of the urukul MonInj GUI merely submits an experiment to the scheduler to set the DDS & switch state. There is no proper "injection" overriding the switch state (extremely useful for debugging experiments) as there is for other TTLs or as there was prior to ARTIQ 7.

I recognize supporting proper injection "everywhere" (i.e. frequency, phase, amp, etc.) is ridiculously complicated; restricting my request to merely restoration of proper injection for the switch.

As an example, when debugging an experiment using urukul as an RF source for an AOM, I would like to override the AOM to remain off as the experiment runs. With the current psuedo-injection implementation, clicking "off" in the GUI merely pauses the current experiment, turns the switch off, returns to the original experiment, which then turns the AOM back on as it proceeds; the RF output does not remain "overridden" in the off state.

[dnadlinger]

+1 for bringing back the RF switch override, most people here would find this very useful, especially in the early days of setting up an experiment. In fact, the absence of a "force-off" override as a quick way of sanity-checking the apparatus was already annoying for SUServo – if I hadn't been using bare Urukul when initially setting up my experiment, I would have long added override support for it myself. One can do without it, but imho switch override support clears the complexity vs usefulness tradeoff bar.

[Spaqin]

Thank you for your detailed responses. As simple as the fix is (and a workaround would be changing ttl_urukul* into something else in device_db), I can now agree that DDS TTL channels should be still available.

[sbourdeauducq]

The original code was quite brittle anyway, looking at device names (which can be arbitrary) instead of inside Urukul device entries and removing the corresponding TTLs, which would have been the proper way of doing it.