[v1.1 hw] spikes on specific voltage levels about stabilizer HOT 11 CLOSED

• Does it happen on both channels?
• The input signal is definitely clean?
• If you do small 10 mV amplitude around an offset close to those levels, does it occur more often?

If it's really code dependent: I think the ADC SPI clk is now twice as fast as before (v1.0). Maybe it's hitting a timing issue. I'd check slower SPI clk (25 MHz) and with a scope on the bus.

from stabilizer.

• It happens on both channels.
• Input signal is clean.
• At small amplitude around these voltage levels it happens more often.

Channel 0
** 50Hz, 2 Vpp, 0 mVDC**

** 10Hz, 2 Vpp, 0 mVDC**

** left-hand side of previous screenshot**

** right-hand side of previous screenshot**

** 400 Hz, 2.5 mVpp, 160.8 mVDC**

** 400 Hz, 10 mVpp, 160.8 mVDC**

with reference signal from generator

same for channel 1

Ch 1, 400 Hz, 0.5 Vpp

from stabilizer.

160 mV is exactly at the 10 bit carry toggle. My guess is ADC sample/conversion/SPI timing.

from stabilizer.

I think multiple spikes at low amplitudes are due to noise at the input.

from stabilizer.

I think multiple spikes at low amplitudes are due to noise at the input.

Noise as a root cause isn't consistent with it being triggered at a specific digital code independent of offset, amplitude, slew rate.

@nkuh
If you want to play with the ADC SPI timing, read up on how the sampling and processing is timed and what the datasheets want, check the ADC SPI lines on a scope, and then mess with this:

from stabilizer.

Noise as a root cause isn't consistent with it being triggered at a specific digital code independent of offset, amplitude, slew rate.

I didn't mean as a root cause. I mean that the noise at the input causes the error, that happens at an exact voltage, to appear multiple times in quick succession because the input crosses that threshold multiple times.

from stabilizer.

Sure. Among other things the intrinsic ADC input noise is finite. That's sufficient. But it's not the problem.

from stabilizer.

I did some investigation here and this appears to be caused by the DAC hardware when transitioning across specific binary code boundaries. Below is a capture of the CSn line (dark blue) and the stabilizer output (light blue). Note that in the middel pulse, the small spike can be seen in the negative direction immediately after the DAC code is updated.

Note that probing the CSn line introduces some noise on the output. Below is what the capture looks like without CSn probed:

Upon further analysis, it appears that this glitch was specifically occurring when the DAC transitions across the 10-bit boundary (e.g. from 0x83FF to 0x8400) and is transient. In the following sample, stabilizer output was modified to output 0x83FF and 0x8400 in an alternating pattern at a 50KHz update period. The SPI frequency was also lowered to 5MHz.

It can be observed that every transition causes a transient spike in the opposite direction of the transition (e.g. we get a positive spike when transitioning from 0x8400 -> 0x83FF).

This appears to be a hardware issue and there's not much we can do to mitigate this in firmware. I'm spawning an issue in the hardware repository to track this.

from stabilizer.

Because this appears to be a hardware issue, this is being continued in sinara-hw/Stabilizer#83 and I'm closing the issue here.

from stabilizer.

Sound analysis. Is ch2 in this shot between DAC and output AFE opamps ro after the AFE at the SMA output?

from stabilizer.

CH2 is measured at the SMA output connected over a 50 Ohm impedance coaxial cable into the o-scope.

from stabilizer.