Firmware feature requests

[hartytp]

I'd like to see Stabilizer become a really nice lab tool for data acquisition, feedback, etc. The first version of the firmware will be very minimal (just a PI loop), but I want to start having a think about "killer features" that would be nice to have in the long run (pending securing funding for M-Labs/Quartiq or finding a student to implement them).

• complex configurable loop filters, implemented with low latency (the Oxford B-servo is an example of a fairly complex servo loop we use in the lab)
• record ADC traces (noise measurements, step response)
• transfer function measurement (AC signal generated by DAC, record ADC trace, probably perform FFT and other analysis in python code on a PC)
• python code to use the transfer function measurement to determine an optimal loop filter with a give bandwidth, phase margin, etc
• integrator enable/disable using TTLs/EEMs
• read/write to/from the analog + GPIO headers
• set point control via the EEM connector (n.b. this will probably be asynchronous to the sample clock)
• setting the DACs to fixed output values (override the loop filter)
• playback of waveforms from the DAC? (e.g. use this for 50Hz modulation of the coil current to cancel ambient fields, that would involve playing back a waveform in a loop, using a TTL to trigger it for synchronisation with the mains power cycle)
• modulation of loop set point from RAM for feed forward?

[hartytp]

A really nice use of Stabilizer will be combining it with a variety of mezzanines. e.g. the current stabilizer board we're already designing.

Another example could be a phase locked RF source. The mezzanine would contain VCO + phase detector. If one wants to be fancy, we could add the usual extras (pre-amp, attenuator, etc). It would only be a simple design -- just a handful of MCL bits -- but could be nice for things like fibre phase noise cancellation. Obviously, this could also be done by driving Urukul from Stabilizer using the EEM connector, but that may be overkill for some applications.

[jordens]

By "phase locked RF source", do you mean the same function that a PLL chip gives you, i.e. Mirny? Apart from things like integrator hold and more flexible software controls, that is.

[hartytp]

Yes, just a PLL with a digitally programmable LF.

[hartytp]

Anyway, even though one could do this kind of thing with Mirny in principle, it's nice to have the option of building a simple mezzanine card with some mini-curcuits bits that's tailored to a specific application such as fibre phase noise cancellation.

[gkasprow]

We can reuse verified design of WR-DDS board I designed for CERN some time ago.

[gkasprow]

I placed the CubeMX config file in the repo.

[hartytp]

One of the features I see for stabilizer is really good diagnostics. e.g. being able to get noise spectra for the locked system. I've hacked a proof-of-principle of that onto @jordens code here https://github.com/OxfordIonTrapGroup/stabilizer/tree/adc_log

The really killer feature for me is automated system transfer function measurement. e.g. finding the open-loop system poles so that one can design an appropriate compensator. I've had a go at doing that as follows:

• simple state machine that resets whenever a user connects to port 1234
• when started, we log every ADC sample into a buffer
• when started, we add PRNG noise to the DAC output
• in reset, we clear the ADC buffer and reset our PRNG back to its seed
• python script on the PC connects and records a number of samples before disconnecting
• recreate the PRNG sequence on the PC. Transfer function is given by the ratio of the DFTs of the noise and ADC values.

Works nicely. Here is a simple test on HW. Configuration is:

• no digital LF on Stabilizer
• DAC connects to 10k series resistor, followed by 15nF shunt capacitor in parallel with the ADC input. i.e. LFP with fc at approx 1kHz

Plot looks like this after DFT (y-scale in dB)

• Orange is the PRNG noise (red is mean)
• blue is ADC samples
• green is inferred system TF (purple is same after decimation)
• brown is a model fit with pole at 1.3kHz

So...needs proper testing and some polishing, but seems to work quite nicely. That should make tuning up complex loops much faster :)

[jordens]

You may want to consider choosing the PRNG period properly and take samples for exactly that period. Then the PRNG noise is strictly flat, the ADC trace doesn't need normalization, the noise is much less, and non-linearities due to uneven power disappear. This worked really well for redpid. Nowadays with the benefit of hindsight, I would do it the way audio people do it with an exponential sweep. That has numerous advantages (works well with non-linear transfer functions, gives you extremely good inferred impulse response, even separated by response-order, has useful -- i.e. logarithmic -- power distribution accross the spectrum, much better signal to noise, works well at arbitrarily large modulation amplitudes even with nonlinear response as long as it is locked, etc. see the literature about it).

[hartytp]

You may want to consider choosing the PRNG period properly and take samples for exactly that period. Then the PRNG noise is strictly flat, the ADC trace doesn't need normalization, the noise is much less, and non-linearities due to uneven power disappear. This worked really well for redpid.

Nowadays with the benefit of hindsight, I would do it the way audio people do it with an exponential sweep. That has numerous advantages

Yes, I did consider things like that. This was intended as a simple PoC and a fun way of dipping my toes in rust (speaking of which, I was quite pleases when I realized I can do things like this with smoltcp https://github.com/OxfordIonTrapGroup/stabilizer/blob/a66670ee7b882070c62f4a98cc35e2fc6a500f20/src/main.rs#L669-L673 ). More the easiest than the best approach.

If someone can provide funding for implementing these things in a less hacky and more sophisticated way then that would be ace.