How to avoid noise when writing to the microSD?

Status
Not open for further replies.

flipflop

Active member
In any ADC acquisition system, there are a moment when your must be write in the microSD, but when this happen the noise induced when are writing in the microSD are registered whith the ADC acquisition system, there exist some kind of filter o some more elaborate approach to avoid this problem? thanks in advanced!!!
 
Some steps to mitigate this noise, but without success:

* Use GND for the microSD circuit and AGND for everything else.
* The only connection between AGND and GND is found in the teensy.
* Use separate battery and regulator circuit (3.3v for the digital part and 5v for the analog part).

Here is showing some evidence of this noise:

noise.jpg

There exist the possibility that something is needed between microSD GND and teensy GND, or in the SPI conections?

The schematic circuit can be see in the upverted repo (upverter is very slow and almost unproductive)

regards!
 
Last edited:
Sdd a 270uF cap and 1M bleeder resistor. I had to do that on my teensy++ 2.0 in order for it to work right.
 
What kind of decoupling caps do you have at the SD card? I'm assuming the noise you're seeing is due to the write current on the flash, rather than SPI communication . . .


Edit: just saw your link to the schematic . . .
 
Last edited:
How did you measure/observe that waveform ? Where was 'scope GND, and what node were you probing ?

Some steps to mitigate this noise, but without success:

* Use GND for the microSD circuit and AGND for everything else.
* The only connection between AGND and GND is found in the teensy.
* Use separate battery and regulator circuit (3.3v for the digital part and 5v for the analog part).

Here is showing some evidence of this noise:

View attachment 1621

There exist the possibility that something is needed between microSD GND and teensy GND, or in the SPI conections?

The schematic circuit can be see in the upverted repo (upverter is very slow and almost unproductive)

regards!
 
Last edited:
What kind of decoupling caps do you have at the SD card? I'm assuming the noise you're seeing is due to the write current on the flash, rather than SPI communication . . .


Edit: just saw your link to the schematic . . .

why is necessary decoupling capacitors if the batteries of 5v and 3.3v are different? (they aren't already decoupled?). The only conection between they is the inductance in the teensy board, of course there are capcitors (without bleder resistor) in the 5v and 3.3v LDO circuits.
 
I only see that 0.6 V going to the two filter ICs. Where did you have your 'scope ground ?

One way to see if the scope is picking up spurious signals is to probe the same signal as its GND is connected to -- you shouldn't get anything.

How are you clocking the filters (U64 & U43) ? Seems you have added 2*200 pF to the clock inputs -- that's not good (and especially to AGND)
 
the waveform was writing in the microSD with the teensy 3.1 board at 4ksps

you can see the complete circuit in the upverter repo (upverter is very slow and almost unproductive): https://upverter.com/flipflop/7acf334d8f9af913/geocentinela

the signal are from a geophone: http://en.wikipedia.org/wiki/Geophone

So are you saying the the waveform in the graph is created from the data you wrote to the SD card rather than observed by a scope? If you don't have a scope, what gets written to the SD card if you short the +/- inputs of the instrumentation amplifier? The reason I asked if the SD card was decoupled is to keep transients generated by the current spike when writing to flash local: otherwise the only other path (than through the SD card) to GND is back through the SPI lines to the Teensy, no? You could drive a passive load rather than the SD card from the SPI bus to see if it is SPI comms itself that is causing the problem . . . but you'd need a scope to observe it . . .
 
The bandwidth you are interested in is very low (<< 100 Hz ?); can't you just (digitally) filter the ADC output ?

Also, noise on the ADC's output can come from noise coupled to the input, but it can also come from the reference. I don't know what the ADC reference's PSRR is. Are you using the internal or an external reference for the ADC ?

Generally, if there is a supply transient while writing to the SD card, it would reduce the supply voltage. If this couples to the reference, it will lower its value, and this would reflect as an increase in the ADC reading. One way to check is to send in a DC value that is low (say 0.1 V), and look at the 'noise'; then send a high DC value (near full scale). If the 'noise' is (significantly) higher in the 2nd case, then it is likely coming via the reference (because for instance, for an input signal of 0, noise on the reference is immaterial).
 
Last edited:
I'm thinking that instead of 3 instrumentation amps + filters + using the Teensy's ADC, why not a 3 channel differential programmable gain ADC - might be a lower total component cost - then your analog ground plane can be isolated from anything digital, with clean power and reference on it . . . and then the digital side of the ADC would be SPI to the Teensy and use the FFT functions being hashed out in the audio thread to filter . . .

Although it's worth finding out what's going on . . . and how to resolve it . . .
 
This is the kind of noise I saw when I was trying to do ADC and sdcard writing, and I was doing much faster sample rates.

I wanted to mention that I saw on another site not specific to arduino, that someone claimed it was the SDIO CLOCK PIN. Not sure how to deal with that though.
 
Paul will forget more about this than I'll ever know but I'll just add that the Analog pins are spread all around the K20 chip. How Paul managed to pull them all to one side with the digital stuff going in the other direction is a testament to his skills. Along the way, it would not surprise me if a couple of analog pins came close to or even intersect the SPI data lines that could cause some naughtiness re: EMI. I'd try some low cost approaches to fixing any input issues and then I'd consider going external re: the ADC.

For example, a shunt-style voltage reference diode on AREF is a good idea. Perhaps even add a 10uF cap there as a charge reservoir.
A 0.1uF cap on the input (input-AGND) will likely help also.
Going with an external buffer is likely more expensive and space-intensive than finding a good external ADC that runs on I2C or SPI.

To me, the internal ADC is certainly useful. It may even attain 12ENOB under the right circumstances. But I've gone a different route because I had the fortune of finding the MCP3911/MCP3910 series of analog front ends to do power measurements with instead.
 
I'm working with Teensy 3.6 and I have big problems with radiated emissions. I have a GPS receiver near the Teensy (completely decoupled from the electrical point of view); as soon as I start writing to the SD card the signal to noise ratio of the satellites goes down and the GPS losses the position fix. When I stop writing on the SD card, after a couple of seconds the satellites appear again. There is no electrical connection between Teensy 3.6 and GPS receiver, all the disturbances are radiated from Teensy.
How can I reduce the radiated emissions?
 
I've got to add that I'm seeing this same GPS issue on a Teensy 3.6. If my code writes to the SD card, the satellite signals drop badly. If I stop (but still hold the file open) then the GPS is fine. I'm using the SdFat library.

I've got some more experiments to do; maybe some shielding will work.
 
How to solve the SD - GPS noise problem

I've got to add that I'm seeing this same GPS issue on a Teensy 3.6. If my code writes to the SD card, the satellite signals drop badly. If I stop (but still hold the file open) then the GPS is fine. I'm using the SdFat library.

I've got some more experiments to do; maybe some shielding will work.

Shielding doesn't improve the noise immunity, I solved the problem running the CPU at 192MHz.
 
@MorganS: Is the GPS running off the Teensy 3.3V? On a breadboard? It may be a power draw issue? My T_3.6 could power the GPS, I was not using SD card - but I did pull 3.3v from T_3.6 in two spots to feed the power rail on the breadboard to the GPS. Working on same project somebody else was using external power (with common GND) on the GPS as his similar unit was failing to function - so the power draw may be an issue as the SD does draw some current … as it makes noise.

@paoloboatto - interesting F_CPU speed change helped - what was the F_CPU when it was failing - 180/216/240/256?
 
.

@paoloboatto - interesting F_CPU speed change helped - what was the F_CPU when it was failing - 180/216/240/256?

I would also compare SD clock speed.

I had a scenario where 30 MHz SPI clock was interfering with low-noise preamplifiers by adding energy to the power supply (voltage fluctuations corresponded to SPI bursts)
Only way around was to physically separate as much as possible teensy from preamp power supply.
 
Status
Not open for further replies.
Back
Top