Project: EOGee – Noise, Part 1

Previously we have focused on the mains interference component of noise in the EOG signal. This is because it has been the dominant source. However we have seen that this noise can be significantly reduced with appropriate shielding and we could reduce it further still with shorter leads.

Now that the 60Hz noise is reduced, there is a very clear spiking signal coming from somewhere. The signal does not have any obvious periodicity but it is significantly larger than the other noise and also generally affects only one sample. It is easier to see the noise if I remove R108 which means that the final gain stage is disconnected from previous gain stages so the ADC is driven to midrail and is not affected by 60Hz noise at the input.

Screenshot 2020-04-11 at 17.58.50

The signal spikes occasionally

It’s not a giant spike, only about 10mV, but it is significant compared to everything else. My original thought was that this would be due to noise on the power supply. USB power tends to be generated by a switch mode power supply in a laptop and so is not always the cleanest power source.

To test this I make a quick interposer board so I could still communicate over USB while injecting a different power source – in this case a 9V battery which should produce a clean voltage (my voltage regulator accepts up to 30V, obviously this isn’t a good idea if your equipment expects 5V from USB).

IMG_5779

Protoboard to inject power for a USB device

Testing showed that using a battery didn’t make a difference when viewing the waveform over USB. To see what was going on I probed the power rail and the input to the ADC with the oscilloscope and noticed that when the PCB was connected to USB the noise was worse than when it was not connected to USB, even though in both cases it was powered by the battery. It is important to note that at this point I was doing initial probing and was not using a good probing technique, however this suggested it was actually the USB data that was causing an issue, and not the USB power.

SCR47

Spikes on the voltage rail (yellow) and ADC input (green)

To test, this I wanted to view the ADC samples while not using USB. Unfortunately, USB is the interface that I use to view the data so this was not a simple task. In theory, I could try to ensure that no USB traffic occurs during the ADC sampling time, but because the EOGee PCB is a slave on the USB bus it doesn’t get to decide when USB transactions occur.

To solve this I decided to output the data over a different protocol and use my oscilloscope to capture the data. I was able to reuse one of the LED pins and an unused pin on the microcontroller to output the data over SPI which I then captured on my oscilloscope.

SCR48

10 samples being streamed over the SPI bus to the oscilloscope

I captured about 44000 samples which is about 1 minute of data. I then copied that data to my Mac for processing. I captured the equivalent data over USB and compared the two.

Screenshot 2020-04-12 at 00.22.43

Comparison of data streamed over USB vs data streamed over SPI

There is a clear improvement in the data streamed over SPI. It is worth saying that this is not necessarily due to the USB lines being noisier than the SPI lines (though I would guess that they were). The most important difference here is that, as the master of the SPI bus, the microcontroller only performs SPI operations between ADC samples and not during and therefore does not introduce noise to the measurement, whereas for USB this is not an option.

Ideally at this point I would then run the experiment again with both USB and SPI active simultaneously to show that the data over SPI was also noisey when USB is active, however the USB stack takes up a lot of space in flash memory and the microcontroller I am using doesn’t have enough flash space to store both the USB code and the SPI code simultaneously. At this point the data strongly suggests there is an interference issue between USB and the ADC.

I wanted to understand how the noise was coupling between the two subsystems, ultimately it is either a radiated effect or a conducted effect. The layout of the PCB is definitely far from ideal as it was intended to be a quick proof of concept. To test if this was an EMI issue, I stuck some grounded copper tape over the USB traces but did not see a noticeable difference. While this is definitely not ideal shielding, I would expect some kind of difference if the noise was radiated.

IMG_5772

Shielding over the USB lines

To see if this was a conducted issue, I created a much higher quality probing setup by soldering wire loops to points of interest and ground to ensure the smallest ground loop possible (w2aew talks about this technique in a video).

IMG_5776

My probe setup minimises loop area

I measured the digital and analog power rails right at the bypass capacitors of the microcontroller, first with the USB off (not transmitting) and secondly with the USB on.

DVDD_AVDD_USB_OFF

DVDD in yellow, AVDD in green, shows noise levels down in the noisefloor of the oscilloscope with USB disabled (oscilloscope sampling at full bandwidth)

DVDD_AVDD_USB_ON

DVDD in yellow shows noise spikes when USB enabled and some of this also shows on AVDD in green (oscilloscope sampling at full bandwidth)

There is a clear difference in the noise levels of the digital rail when USB is enabled and it seems like a very small amount of this also appears on the analog rail although it would seem too small to account for the spikes we are seeing. The spikes here are much less than we saw previously, but that is the effect of good probing – we aren’t seeing spurious noise from other sources of interference.

Probing the ADC input didn’t show any effect due to the USB but there was a clear spike during ADC sampling as the SAR ADC’s sample capacitor is connected to the signal, but this is expected.

ADC_GULP

We see a clear spike during ADC sampling but this is expected for a SAR ADC

Although we don’t see much effect on the analog rail, it is possible that there is a larger voltage spike internal to the chip. This is likely because this version of this chip has only one ground pin which means that both the analog and digital current is sharing one path. We also end up with quite a large analog ground loop as the ground pin is far from the analog power pin.

Screenshot 2020-04-12 at 00.58.50

Illustration of analog (yellow) and digital (blue) current loops

In the above image I have plotted the current path from the positive side of the bypass cap, through the supply pin, through the chip, out the ground pin and back to the negative side of the bypass cap for the analog (yellow) and digital (blue) rails. This shows that the digital and analog current cross paths and therefore may be interfering with one another.

The new EOGee design (EOGee2) uses a different microcontroller with separate analog and digital grounds resulting is shorter ground loops and separated digital and analog current.

Screenshot 2020-04-12 at 01.06.35

Sneak peak of EOGee2 which has much shorter ground loops and separate analog and digital ground

The new design also has shorter USB traces so if it is a radiated effect this should be improved too.

Overall, we don’t yet have a definite answer to what is causing the issue, but we have a strong suspect and reason to believe it will be improved in the new design. If it is not resolved with the shorter ground loops, I will be able to perform the experiment with simultaneous SPI and USB to show that it truly is USB causing the issue, as the new chip has significantly more flash space. I will also be able to try improving power supply decoupling to see if that helps.

One thought on “Project: EOGee – Noise, Part 1

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s