I had a unusual experience today with a field device where I thought I had either a bad thermistor or bad field wiring. The reading was very erratic. After some troubleshooting, I realized I had changed my code from sampling (averaging) 50 times before doing my calculations to just 10 times. After I changed it back to 50, the problem largely went away. It was further improved by increasing the sampling to 100 times. Most of our installations involve commercial HVAC systems and I now suspect they are electrically noisy. Surprisingly, the previous platform we used (SolderCore) did not seem to experience this problem. Then again, on those PCBs I had included a 0.1uF capacitor from each port to ground to mitigate this possible problem. When I designed my boards for the Electric Imp (imp001 and imp002), I did not include these capacitors, assuming they were likely not needed. Perhaps I was being too frugal.
After this long-winded prologue, is there any advise for “standard” input connections to reasonably mitigate electrical noise? Should I reintroduce the 0.1uF capacitors as before?
Also, is there any downside to sampling 50 or 100+ times before calculating?
If the reading is slow-changing, then a cap is a good idea to filter noise.
Was this an imp001 or an imp002? 001 has only a single ground connection and no VDDA breakout which means that wifi transmits (which take a lot of current and hence will move ground relative to the signal you’re sampling) which means that generally you’d want to not be transmitting when sampling; you can ensure this won’t happen if you disconnect when sampling, then reconnect afterwards.
The subject device is an imp002, but I have the same issue with imp001’s. Doing the additional sampling (on both devices) has really helped smooth out the data being logged. I’m assuming it’s not a problem, since the practice was not rebuked.
I may re-introduce 0.1uF caps in my next board design to shunt noise to ground. Yes, these are slow-changing inputs (thermistors and contact closures). That being said, I’m now a bit worried about trying to use 1-wire in this type of environment.
I turn off the WiFi radios before reading any of my thermocouple amplifiers, and that has removed the occasional odd reading that I used to see when it was on continuously.
Just to confirm, if SUSPEND_ON_ERROR is in effect (default), I would simply do a server.disconnect() just prior to reading the inputs and server.connect() immediately afterwards. Is it that simple? I guess I also need to be sure I test for server.isconnected() prior to any server.log calls!
Since many of my devices connect via cellular-MiFi, it will be interesting to see if this measurably increases bandwidth consumption.
Here is how I am doing it. The Imp disconnects immediately on boot so it can take a reading, and then immediately reconnects to send its first reading. After that the onidle function schedules the next wakeup and the process repeats.
Just remember that server.log will always bring up WiFi.
`//Disconnect before taking the first reading on cold boot - implicit server.disconnect()
if (server.isconnected()) {
server.expectonlinein(12);
}
//Take first temperature readings
probe1();
probe2();
server.log(“Probe:1 | Probe:2”); //Bring WiFi back up
My devices are not battery powered, so I’m not too worried about putting them to sleep. That being said, is there any disadvantage in doing what I indicated?
Also, although server.log brings up WiFi, does it also do an implicit server.connect()? Is the same true for agent.send()? I just don’t want to put my device into a condition where it’s halted waiting for a server connection that needs to be requested.
If you have SUSPEND_ON_ERROR then server.log() will bring up the connection. If you have RETURN_ON_ERROR and the link is down then it won’t connect - it’ll just return an error.
As far as squirrel is concerned, connected = connected to server. There’s no way to tell it to bring wifi up and not connect.