Scan mode

[dtcallcock]

It would be good to be able to repeatedly scan an output and then observe the response on the corresponding input (eg. a cavity resonance or an atomic feature) in real time on a PC. This sounds fairly trivial to implement on the Stabilizer side, however a good interface to the PC may need some thought and I mention it now as it's relevant to #54.

[jordens]

I don't see this as relevant for the choice of command interface infrastructure (#54). It's more part of some gui functionality.

[dtcallcock]

It's more part of some gui functionality.

Are you saying you would implement this entirely in the GUI (ie. have the GUI set the DAC, then request the ADC value for each point in the scan)? Wouldn't network latency be an issue? It seems like it would be more efficient to have some simple firmware code that generates the scan points on the fly based on a set of parameters (eg. start, end, step size) and then returns the whole scan.

[dtcallcock]

We'd like to use stabilizer in anger but we really need this to do it. Would you be willing to prepare a contract to expedite this feature?

[jordens]

Sure.

[jordens]

• Implement two independent fully parametric triangular signal generators (one for each DAC channel).
• They have runtime-adjustable frequency, amplitude, asymetry through the networking interface.
• They should compute their output just in time. AWG functionality from uploaded waveforms + interpolation is a different issue.
• Offset Implemented through the existing IIR filter offset ~or as a separate offset in the triangular signal generators~.
• These triangular signal generators may be unified with the (sinusoidal, or square) lock-in modulation signal generator.
• There is a reference CLI implementation to configure them.
• To use them (in typical spectroscopy alignment mode) you'd disable the IIR filters (setting their gains to zero or just disabling the integrator) and then configure/enable the triangular generators. Move the offset to where your spectroscopy feature is, decrease scan amplitude to zero, then enable PID gains.
• If the offset is handled by the IIR filter, you'd get bump-less transfer (when disabling the sweep generator and enabling the IIR filter) for free.
• If the signal generation ends up being costly (in terms of CPU time), we'll have to reduce the ADC/DAC sample rate or find other tweaks to compensate for that, e.g. some interpolation with possible signal quality trade-off.
• Other user interfaces (graphical or not), digital trigger output/input for the signal generator, streaming of ADC/DAC/sweep data for GUIs/network analysis etc. would be separate features for now. Graphical user interfaces operating on the stream data can just trigger on output curvature.

[dtcallcock]

They have runtime-adjustable frequency, amplitude

It'd be nice to have an asymmetry parameter too (for example, where 0 is a sawtooth, 0.5 is a triangle, and 1 is the opposite sawtooth). This is useful for driving piezos where the rapid flyback of a sawtooth causes ringing, but triangle is annoyingly slow.

digital trigger output.... would be separate features.

Until there is a decent GUI I imagine a lot of people will use a scope for live tuning (eg. optical cavity alignment). For that, a digital trigger out is nice so, unless it is particularly difficult, I'd move that higher up the priority list.

streaming of ADC/DAC/sweep data

I think we could just guess the DAC/sweep data from the known parameters. For one of my applications I want to be able to view the cavity signal on the WAND so would need to be able to stream the ADC data.

[jordens]

Ok. Asymmetry sounds pertinent. There is no digital output in hardware. That makes supporting one in software difficult. You'd maybe connect a DIO EEM but that connection is currently more tailored to SPI. Streaming is #150. It's orthogonal to this IMO.

[dtcallcock]

There is no digital output in hardware

For some reason I recalled the two front panel DIO being direction selectable. In retrospect that may have been a good idea.

You'd maybe connect a DIO EEM but that connection is currently more tailored to SPI.

What's the problem - just the pin assignments making it tricky? Does that limit what's achievable?

Streaming is #150. It's orthogonal to this IMO.

I was thinking the scan might define and initiate the stream somehow. But I can see how you could decouple the two if the sweep generator could report some kind of timestamps so you can sync up your streamed data during analysis or in a GUI.

[jordens]

What's the problem - just the pin assignments making it tricky? Does that limit what's achievable?

Many things are achievable. But you'll need to be more specific about what you actually need. Then after that it makes sense to propose approaches and discuss them. If you say you want to be able to use X to do Y and the implementation should be Z, then you're preempting entire solution spaces to what may be your actual requirement W.

[dtcallcock]

you're preempting entire solution spaces

No, I'm asking for a clarification of what you meant by "but that connection is currently more tailored to SPI."

[jordens]

Well, take a look at the schematic. The hardware is populated to suit SPI EEMs, not DIO. You can certainly change the hardware. But the outer product of all these hardware variants would need to receive support in firmware.

[dtcallcock]

Well, take a look at the schematic.

I don't see any barrier to using the 2x EEM_GPIO input and 2x EEM_GPIO outputs without hardware modification. Am I missing something on the uC side?

Obviously having to add a whole DIO card just to break out 4 digital signals is pretty unwieldy but, you know, just exploring the options.

[jordens]

Which DIO EEM do you want to use for that, in what configuration?

[dtcallcock]

I think the most straightforward would be a DIO_MCX. You'd have to make a custom ribbon cable to get the inputs and outputs on different banks - not great, but like a 2 min job.

On one hand, DIO_MCX is a bit overkill but on the other hand, it's actually a pretty minimal board. You could also economize by omitting the mezannine or using the other 8 channels with a Kasli or another Stabilizer.

Again, not saying this is a good/best idea. Just exploring if there is something that would work with existing hardware.

[jordens]

Custom ribbon cables and 2-minute duct tape jobs with so many rough edges and traps can typically not be maintained and supported sustainably. You can always use them yourself but I see no way to mainline them.

[dtcallcock]

Twisted ribbon cables are a sound solution, not rough edge duct tape job: https://www.nostalgianerd.com/why-are-floppy-cables-twisted. Easier to support a new cable than a new PCB. Also, not sure what needs 'mainlining'. The DIO is just transparent to the stabiliser.

I'm still not convinced this is the best way to get a digital output from stabiliser but want to keep that solution space wiiiide open you know.

[jordens]

I know how ribbon cables work, I built hundreds. But that floppy cable is irrelevant as it won't work here and I'm not aware of anyone building custom IDC rewired cables. Even if there was, it's likely not a solution anybody will be willing to provide support for (reasons above). Again, feel free to configure ribbon cables any way you like. But to get your firmware support in (or developed), you need to sit down and specify detailed requirements and convince others that they have merit. This repository is about firmware. Mainlining the firmware support for certain user configurable GPIOs on certain events with certain pin configurations and directions while documenting what works and supporting people that want to use that. I still don't know your requirements well enough to generalize them and delineate them against constraints. Simple questions like: How many? How fast? What? When? How configurable?

[dtcallcock]

that floppy cable is irrelevant as it won't work here

Just an example of wide deployment to make clear it's not a duct tape hack.

I'm not aware of anyone building custom IDC rewired cables.

I imagine Technosystem have an IDC tool.

this repository is about firmware.

Yes, I'll move the discussion to: https://github.com/sinara-hw/Stabilizer/issues/86

I still don't know your requirements well enough to generalize them and delineate them against constraints. Simple questions like:

For triggering a scope from the scan generator:

How many? - 2 digital outputs, one per scan generator

When? - A rising edge at the start of ramp up and a falling edge at the start of ramp down. For sawtooths with instantaneous ramp up or down there would have so be a minimum gap between rising/falling edges. Perhaps 1us but not critical.

How fast? - Presumably the edge speed will be dictated by hardware. Synchronization with the actual scan coming out of the DAC output needs to be reasonable, say better than 1us.

How configurable? - Ability to turn off and free the digital channels up for other features would be useful if/when those other features exist. The ability to switch rising/falling edges might be useful for triggering dumb hardware that expects a certain edge (though obviously not needed for triggering scope).

[jordens]

Implemented as of #388 including host side support through MQTT. Digital outputs are in #86. Other user interfaces or integrations along the procedures outlined above can become separate enhancement issues.