Channel SMPS/switching/SPI/update spur differences

[jordens]

• Kasli, EEM0 -> Fastino channels 24-31 -> IDC-BNC
• battery powered
• modules close together (that does not make any difference)
• in a shielded crate (admittedly not fully RF-tight but that doesn't make a difference)
• voltages in the 6-9 V range (channel << 11 loaded into the DACs)
• all DACs continuously updating at 2.55 MS/s with 21 ns SPI period
• 6.9 kHz bandwidth, 1 M impedance, look at the green trace

The DAC channels are pretty different in terms of their spur performance. 27 is really nice and clean, 31/26/24 are pretty dirty. They have spurs at 450-600 kHz and in the MHz range.

Probably layout tightness, layer crossings, and general routing.

channel 27:

channel 24:

channel 26:

channel 31:

[hartytp]

Many thanks for posting that data @jordens

To check I understand the units, is the worst-case spur you've observed something like -85dBVrms=56uVrms.

For a first hw revision, I find that pretty encouraging. Out of curiosity, what's the noise BW from these measurements/what in-band noise floor do you measure?

Still, worth looking again at the layout with this data and seeing what we can do to improve for the next revision...

[hartytp]

Crudely, by eye, the filter response looks about right, which is good!

[jordens]

See #51 for that.

[dnadlinger]

Is this with the swapped output filter resistors manually reworked, or with an unmodified board (i.e. with the extra output offset)?

[gkasprow]

@jordens did you try that on another Fastino board?

[gkasprow]

Output traces of affected channels

[gkasprow]

I don't see why these channels are noisy. Did you generate 3.125 sinewave on all outputs?
Can you measure the noise without updating the channels?

[hartytp]

@gkasprow can you remind me which channel is which on that diagram? Also, can you remind me where the refs for each channel are routed?

[hartytp]

27 is really nice and clean, 31/26/24

27 is right by the connect edge of the board, while 31/26 are close to the SMPS/FPGA so it somewhat makes sense they would be nosier.

24 is right next to 27 and derive from the same ref buffer so that difference isn't obvious.

[gkasprow]

other channels like 23, 29 is as close as 31 and 26 to the SMPS. Channel 8 is the closes to the FPGA
Channels 29, 23, 26 are the closest to the SMPS.
SMPS is sitting on the copper island to avoid current loop below.

[gkasprow]

It needs careful investigation. I'd disable the SMPS first or at least correlate its frequency with the spur.

[hartytp]

Easier said than done. In most of our lab space I’d struggle to reproduce @jordens data since the ambient emi is a nightmare.

[gkasprow]

The same in my lab. I have a few FM and DVBT transmitters nearby. It's impossible to measure 100mV 100MHz signal with a scope...

[hartytp]

Supposedly our shiny new building will have low EMI. I've budgeted some time to test Fastino once the software is ready. If I can reproduce this then I'll have a look at it (I suspect the easiest thing is to measure the frequencies of the various noise sources and see how they compare to the measured spur frequencies).

[gkasprow]

This is exactly what I do. Make a small air coil and sniff with scope in search of EMI sources.

[jordens]

This is the only v1.0 I have with all output networks patched. The patch works. Voltages are ok.

I didn't generate a 3.125 sine wave (MHz? V?).

This is a 25 year old office building, with a massive mains/network/phone cable duct running 2 m away from the setup, a bunch of office and lab/RF equipment in the same room, a tram line outside in 50 m distance, the corresponding tram substation in 20 m distance, kitchen with microwave at 20 m, a forest of cell towers at 100 m (20m up), and other labs and companies doing high power audio and wireless development in the adjacent floors and buildings. Certainly not clean. It's a really nice exercise to figure out what matters and what doesn't matter.

The really weird difference is between 24 and 27.

[hartytp]

The really weird difference is between 24 and 27.

Indeed.

From a quick skim over the schematic, the most likely offender for the 450kHz stuff looks to be the 3V3 SMPS. It's also not filtered (beyond the main switching LC) and goes all over the board due to e.g. LEDS, signals like REF shutdown, etc. I haven't looked at the layout in enough detail to offer an explanation for the difference in noise between ch 24/27 though.

@jordens if you have time at some point, it would be really interesting to grab a trace of the P3V3 rail and compare the spectral content on that to the noisy DAC outputs.

[jordens]

@gkasprow ah you mean the lowest FFT bin at 3.125 kHz? That's just window leakage from the DC 0 Hz bin.

[pathfinder49]

Edit: I shouldn't make posts when in a rush. I now see there are a quite a few things in the above setup I missed... Will have a more careful look tomorrow.

I've just attempted to replicate this measurement on a 4GHz scope using a 500 MHz probe. I believe the noise peaks above are aliased.

Sampling at 20 MS/s (I believe this is how the above data was taken) I get this spectrum:

Sampling at 2 GS/s the 500 kHz features disappear and significant 100 MHz noise becomes apparent:

Sidenote: all channels I've looked at show a ~1 us beat between 100 MHz signals. The time basis trace looks like this:

Focusing on a noise spike we see this:

[hartytp]

Glad you got that up and running. Let's have a look tomorrow, but I suspect that with a scope probe that's largely pickup from the lab.

[gkasprow]

How did you connect the GND clip?
Please repeat the same measurement, with the same GND connection. Just touch the GND connection with the probe tip and post the results. In this way, you will measure what induces on the probe cable shield.

[pathfinder49]

The GND clip is connected via a 20 cm ribbon cable. The cable is is broken out to a header with soldered wires. I'm using DAC N as ground.

Here are 2 (savgol-filtered) measurements I made today. The y axis should be comparable.

clipped on DAC P	Touching GND clip (not moved)

[gkasprow]

SO, you are essentially measuring the ground loop noise. Try to substract the two :)

[pathfinder49]

• all DACs continuously updating at 2.55 MS/s with 21 ns SPI period

@jordens How did you configure the DACs to continuously update? From our discussion on Mattermost it sounded like you didn't use DMA. However, I only see the SCLK toggling when
my experiment continuously writes values to the DAC.

[jordens]

You need to change the gateware to make it update all the time.

[jordens]

For a first hw revision, I find that pretty encouraging.

What's "good" level of spurs?
"One LSB" doesn't make much sense and figuring out a generic and practically meaningful bandwidth to integrate the wideband noise over is pretty much impossible.
But there is one value to compare the -87 dBV to: This is only 13 dB better than what would be allowed on conducted emissions on the power line coming from domestic device (CISPR 22 class B requires less than 46 dBµV).
Maybe something like -120 dBV (46 dB better than CISPR 22 class B and about 70 dB better than a 10 mV ripple on a SMPS power supply rail, depending on harmonic content) would be a worthy goal for a low-noise/low-spur DAC output.

[hartytp]

@jordens any objections to closing this? This is quite different on the new layout and AFAICT most of the spurs you pointed to are gone.

[jordens]

As long as you keep track of the underlying issue, sure.

[hartytp]

As long as you keep track of the underlying issue, sure.

For the avoidance of confusion, which issue exactly do you mean?

[jordens]

Given that there are several issues potentially playing into this, we should document a specification for the spurs and ensure that we track and look at several/all channels and all spurs, each time there is an attempt to fix class of spurs. I don't have the overview of assigning the spurs displayed here to the different underlying issues (SMPS on 12V from Kasli, cross-talk from CS/CLK/MOSI through the chip, cross-talk from the terminations through vias or cuts or radiatively, cross-talk from the SMPS on Fastino, through the references or onto the analog path). But I'm happy if someone says that those issues are being addressed and are reasonably likely to have caused the spurs in v1.0.

[hartytp]

ACK. I think all that information does exist in the issues, but not in a form that's easy to follow.

I believe that we understand the vast majority of the spurs now and v1.2 should be very clean (v1.1 already looks good on all but a few channels). It will be interesting to see the data though...