Electron Asset Tracker - issues with noise susceptibility on analogue inputs

Hi All,
Just wondering if anyone else has had issues with noise on their Electron Asset Tracker hardware. I’ve built analogue sensing hardware and software - but I seem to be getting quite a bit of noise coupling into the circuit. Much worse when the battery is low. And I suspect the modulation of the “breathing LED” is also causing some issues. Anyone know a hack to turn off that LED so I can see if this eliminates the issue?

@antman, no hack required!

https://docs.particle.io/reference/firmware/photon/#rgb

As for the noise, can you describe your analog front end a bit better. If the dynamic range of your analog voltages is small, especially at small voltages, your design will be susceptible to “environmental” noise including RF and switching PSU noise.

1 Like

Hi peekay123,
Thanks - I will try disabling to see if it knocks out the peaks in the noise I’m seeing.

Some background; I have an (audible) noise sampling circuit in the tracker - so I am receiving raw (well, pre-amplified) microphone input on A0. And I have an AC-coupled filter downstream of that, producing “sound pressure level” signal into A1. However, this seems to be quite susceptible to noises in the box. I am using this “sound pressure level” as the trigger for “noise events”. E.g. when the sound pressure level exceeds a noise threshold, I do some analysis on the raw sound input on A0.

There are 2 apparent problems:

  1. There seems to be some sort of charging or switch mode hardware kicking in when my battery gets down to around 70% “fuel level”. It basically renders my analogue sensing hardware useless as I’m getting multiple false positive triggers each second. Strangely, if I observe this problem and start re-charging the battery, I can re-flash the firmware to make it recover quicker (i.e. I suspect something, perhaps in the power management hardware, is latching on and causing noise issue). Still to be investigated…

  2. When the battery is charged, and the apparent charging hardware issue described above is behaving; I have this smaller noise signal (10’s to 100’s of mV once coupled through the filter pre-amp circuit). The only thing I can point it to is the LED modulation. I would like to knock this out to make the system more sensitive to actual noise events if possible.

Cheers.

@antman, can you share your analog circuit design? How are you powering you analog circuit. Are you decoupling the power rails? Also, since you are monitoring audio, have you considered a bandpass filter to exclude unwanted frequencies?

hi there - I have just been using the freetronics microphone module. I did replace the electret with a piezo contact mic though - this may not be the best amplifier arrangement for this sensing device. I’ve spotted some other examples for pre-amps that I need to try, but this is the device I have:

Taking another crack at trying to isolate the noise source again - I didn’t get much improvement disabling the RGB LED. It seems the 3V3 rail is stable while the external supply to the asset tracker is in use (and the solid red LED is active - i.e. charging). The rail goes haywire once the charge cycle is complete and the red LED shuts off (while the external supply remains on) - reverting the supply back to the battery. This scenario causes havoc with the sensing circuitry. It’s not from the external supply - i’ve put a clean source on this (10V, <40mv p2p).

Once the battery is charged, if I turn off the external supply; the circuit behaves . I was previously observing a similar problem at the bottom end when the battery is low.

Any similar observations out there? Recommendations? I’ve tried decoupling caps at various locations - not notable improvement.

Cheers

@antman, can you provide scope traces of the noise you see. How are you integrating your hardware with the Asset Tracker? The folks at Particle have indicated that they have not seen this type of noise on the ADC inputs though they did thoroughly test for this.

I’ve also had problems with the electron analog inputs. I was trying to sample a TMP36 temperature sensor, and simply could not get it to work reliably on a breadboard unless I shut off cellular. I figured the lack of the ground plane on the breadboard might have something to do with it. (I tried all sorts of filtering configurations, decoupling, even using an op-amp voltage follower to drive the analog input.)

I finally did a PCB and got my boards back last weekend… with ground pours on both top and bottom and plenty of vias to join the two. After populating the PCB and plugging in a fully-charged LiPO, everything looked good… I was getting reliable temp readings with cellular enabled. But, not so fast… once the LiPO dropped to around the mid 70% charge level, my temp readings went back to totally erratic.

My circuit right now (on the PCB) is just the TMP36 feeding a low-pass filter, then the analog input on the electron. This weekend, I’ll play around with the RC values and see if I can make any progress. I’ll also poke around with the scope and report back here.

My sample rate is super low (once per minute).

Hi @JeffInCO

There have been lots of problems with the TMP36 and the STMicro chips used in Particle. The fundamental problem is that the input impedance of the ADC is fairly low at around 40kOhm and so the sensor and its resistor are not low enough impedance to overcome that input. A capacitor helps, but the real solution is to add an op-amp that buffers the sensor/resistor and provides very low output impedance.

I’m not saying that your problem is not RF or conducted noise from the cellular radio, I am just saying that I would fix the impedance problem before try to debug the much more difficult issue of RF or conducted noise.

As I mentioned, I tried driving the electron analog input with an LM358 op-amp, after reading the TMP36 threads here. This was when I was still using the breadboard.

The op-amp didn’t help. I.e., I still got correct readings with cellular off, but worthless readings with it on. At that point, I gave up on getting the TMP36 to work with a breadboard.

I also have one Photon, and saw similar issues with it… that went away if I shut off WiFi.

With the electron on the PCB, my initial (qualitative) observation is that it seems to not depend on whether cellular is on or off, but instead on the charge percentage. It could be that the charge percentage had something to do with the noisiness on the breadboard, but maybe I didn’t notice it then.

Anyway, now that I know I still have a problem even with a good ground, I’ll try to further isolate.

So I have done this experiment: a TMP36 with LM358 configured as a follower driving a Photon. I was able to get reliable readings on a breadboard short-term repeatable to within around +/-5 LSB’s of the 4096 level ADC, so around +/- 0.1% full-scale error. All the time the WiFi radio was on and working, but not close-by. Another way to look at the +/- 5 LSBs is that represents around +/- 4mV which I think is quite good.

The sensor itself is only +/- 2 to +/- 4 deg. C with a linearity of 0.5 deg. C, depending on grade and range of measurement. It is not a precision device.

http://www.analog.com/media/en/technical-documentation/data-sheets/TMP35_36_37.pdf

I didn’t try the LM358 with the Photon (just various low-pass filter RC values). The LM358 was only with the Electron.

I know I could switch to a 1-wire temp sensor, but it’s been kind of bugging me that I can’t get the TMP36 to work.

In any case, it’s good to hear that someone is successful at this.

Readings over the last 24 hours are below. The setup is sitting on my desk at home, with the thermostat set to 68ish (This is the electron on the PCB, no op-amp, ~16kHz first-order low-pass filter R=100 ohms, C=0.1uF). The peaks look like they’re pretty close to the actual temp. The TMP36 also has a separate 0.1uF decoupling cap on its 3.3 supply, which is using the electron’s 3.3 Volt regulator.

Battery readings from 6 hours of the day before:

Temp readings from the same 6 hours the day before… fairly stable until the end, where the battery percent hit around 75. The craziness starts then and continues indefinitely thereafter:

I think I’ve had some success - but in the process of validating still. I suspect the symptom I was observing was a side effect of this smart charging IC. The way the manual reads; it tries to use the battery once the battery is fully charged:

The Electron will intelligently source power from the USB most of the time and keep the battery charged. During peak current requirements, the additional power will be sourced from the battery.”

It appears this applies when on external (12Vdc input) to the asset tracker board too.

Good in theory; but if you have sensitive (high gain) analog sampling hardware also calling on the 3V3 rail (potentially at the same time as cellular data interaction) - this causes instability of the supply - causing it to bounce between battery and external supply. In my case; I’m using the 3V3 rail to drive an op-amp (65kHz frequency response in my case) into 2 analog inputs.

So to remedy, I’ve just swapped out the battery for a larger capacity version (2600mAh Li-Ion), and put in a separate 3V3 supply for my op-amp circuit - i.e. an isolated/filtered reference from the on-board device on the Electron.

So far - all is running beautifully, the battery started at under 50% capacity - no problems with or without the external supply (I wasn’t able to get it to behave anything under 75% previously when using the on board 3V3 to power my amplifier circuit). It also solves the issue at the top end (when trying to use battery to source current while external supply is still connected but not in use). Just the one blip which couples through my amplifier as the power management IC switches on/off the charge circuit - no instability though.

I guess the short version is; make sure you understand the current limitations on the on-board rail (800mA at the pin according to the manual for Electron):

https://docs.particle.io/datasheets/electron-datasheet/#schematic

I guess I under-estimated the consumption of the amplifier in my application.

@antman, the op-amp is drawing how much current? Which op-amp would that be cause that seems awfully wrong.

1 Like

It does doesn’t it. I can’t really devise a test on getting that instantaneous current with what I have. It may also be a symptom of the battery too though; perhaps nearing end of life (and essentially getting a higher effective series resistance) - which may be contributing the the bounce in rail voltage I was observing intermittently…

@antman, perhaps. It will be interesting to see what happens when your new higher capacity battery starts charging.

The power chain is comprised of 2 switching regulators on the Electron. It doesn’t surprise me to see some power supply induced noise in your configuration. Since the ADC uses the 3.3v rail as the reference, some sampling noise is to be expected. However, to be clear, the 800ma rating on the 3.3v regulator is an absolute maximum. Subtract from that the STM32 and supporting chips and the available current drops to below 600ma I suspect. Still, you analog front end should draw nowhere near that.

I’m a bit curious. You mention the analog front-end is ac-coupled with a 65KHz frequency response. Exactly how fast are you sampling the ADCs?

1 Like

Yeah,
Behaving like it should now with the new battery and new 3V3 supply i’ve fitted.

Re. the amplifier; this circuit has been altered slightly - but is basically the same:

It’s essentially 2 ac-coupled amplifiers, cascaded. I have installed a bypass cap accross Vcc / Gnd on that device (10u tantalum) too.

On that point; the electron datasheet:

https://docs.particle.io/datasheets/electron-datasheet/#schematic

shows 2 10uF caps (C23 and C24) on the 3V8 rail - refer “PMIC” section… Searching for where they are fitted - expected they’d be a reasonable size, and should be doing the voltage smoothing needed…

Can’t spot them on the device, or from the layouts online…

I am doing a burst of 8 samples every loop() (3 us sample mode). But doing a burst sample of 1000 while the noise event is observed (~110kHz, some overhead on the loop execution) - so this would be consuming some current too.

[quote=“antman, post:16, topic:30043”]
I have installed a bypass cap accross Vcc / Gnd on that device (10u tantalum) too.
[/quote] Do you also have a small 0.1uf decoupling cap as well?

The 10uF caps are 0603 parts so not that big (and not tantalum). However, not knowing how you distribute power to your analog front end, you need to ensure proper decoupling at the op-amp.

[quote=“antman, post:16, topic:30043”]
I am doing a burst of 8 samples every loop() (3 us sample mode)
[/quote]Which sampling mode is the 3us mode? The faster the ADC read time, the more noise/error will be introduced. The analog circuit has a first-order low pass filter as the final stage with a 1.2K/2.2uF RC configuration. At the target frequency, I would need to calculate the impedance of that circuit. Ideally, it is below the 40kOhm input impedance of the ADC.

The processor activities can account for 80ma or so but not much more IMO. Still, the fact that you reported noise on the Electron 3.3v rail intrigues me still. Your hunch on the battery degradation may be right.

1 Like

Hi @peekay123,
No additional bypass - but the on board 2.2uF on the op-amp the comes with the board is still there. I went for the larger end with the bypass because I could see low frequency bounce on the rail (probably due to cellular traffic).

Error above - not 3 us sample - rather, 3 instruction cycle mode.

I am over-sampling (with a first order lag calc) for the triggering - but keep the sample fast as is necessary to perform FFT over a wider frequency band (i.e. around 2 x frequency cutoff of amplifier).

As for the new hardware configuration - its been operating (without entering any sleep mode) for 15 hours now and going strong (no false triggering). Seems to have done the trick.

Cheers.

1 Like