Ok no worries @WebDust21 your code posted above should be pretty easy to insert locally and test. If you’d like to learn more about Git and Github, there are literally a bazillion videos on youtube. You can also read the various official docs (harder).
This thread started recently and I have high hopes that we can get more folks up-to-speed on github.
What is the status of this improvement? I am trying to use the photon for power measurement with a current sensor and I am getting +/- 20 counts of “noise”. I know all about decoupling caps and input impedance but I’d really like to try a version with this dual interleaved mode turned off and where a single call to A/D sample doesn’t execute 10 samples.
Since I’m using a photon instead of a core I’m not sure how to make this firmware change.
I would also like to be able to set ADC mode for Photon as described here: Why dual slow interleaved?
I am experiencing issues with ADCs when combined with SPI use on pins A5, A4, A3 and A2 for chip select - would the conclusion of this thread provide a reason as to why the analogReads I see for AC current sampling are all over the place and perhaps a solution? At the moment I am exploring an I2C external ADC.
Has this fix been implemented…There are probably 100 posts indicating that the ADC isn’t accurate due to the implementation. Some folks have fixed it by building localy but their changes are not available on the IDE. I just tested my code again (building with the IDE) and I’m still getting 20 counts of noise.
Honestly if you need an accurate ADC I think you’ll have to either build locally or buy an external ADC. Since I can’t get the code to build locally I’ve given up several times.
That is 0.4% (or ±0.2%) which I’d say is not bad considering possible influences as DC quality, temperature, signal to be measured, measuring setup (saying this not knowing your setup).
Measuring analog signals properly with higher precission is more involved than just picking a sample.
It needs a fair bit of statistics too.
BTW, have you checked the output signal of your sensor with an oscilloscope?
I’m using analogRead() to check the output of a variable 5k resistor (one turn pot) that seems to be a little wonky.
I am using a proton system firmware version 0.6.2, programming via the Web based IDE. I am flashing the proton several times a day while fine tuning my code. My Particle Reference Documents still support the ability to adjust the ADC sample times.
What is the end result of this “Interesting results…” conversation? Has the subsequent firmware updates addressed this Issue?
Maybe you should show us your wiring (photos are great) and your code and we can help more. I have tried the various samples times and got reasonable results.
Just as a start, your 5k variable resistor needs to be configured like a voltage divider with +3.3V on one leg, ground on the other, and the ADC input connected to the wiper.
You also have to understand that the on-chip ADC is an environment with lots of potential noise from the WiFi radio and the ADC does not have a separate clean power supply. I see +/- a few counts out of 4096 due to these kinds of issues. So the ADC works great for most purposes but if you are looking for super accurate measurements you might have to add an external ADC and power supply conditioning. Long wires or wires over the antenna and other problems can hurt performance and so you have to be a bit careful.
Thanks for responding, BKO.
First, my wiring is set up just as you describe. I’ve used this in other setups with the Spark, Photon, arduino with “success”.
I’m using this to track the position of a solar panel, and drive a 12vdc motor to move the panel to the ‘correct’ position. I read the pot, drive the motor a bit, read the pot. And repeat as needed, then goto sleep for 30 minutes, and repeat the process.
Occasionally, the motor would drive the wrong way. Checking the serial.prints, my reads would show counts being inconsistent with expectations. That led to my search of the forum.
Your comments seem to indicate that the problems in this thread have been addressed.
Right now, my project is a messy hack on my office desk. however, after setting up a second photon and making a test setup, I found the same issue, and ‘fixed’ it by reading 3 times for an average, with 250msec between reads. I’ve incorporated the fix in my project code,thus avoiding the sample rate issue.
As aside note, there appears to be no examples of how to issue a sample rate adjustment in the reference docs.
So far, my project is performing as expected.
Are you using the ADC with the default sample rate? Or do you change it for your readings?
I do not think many people have played with the ADC settings and they were provided in the firmware because a few people wanted them and it was easy for Particle to provide. I just checked github and there are no currently open bugs in this area.
A lot of the “problems” with the ADC actually related to the input on the ST-Micro ARM chip being unbuffered and having a relatively low input impedance. These problems are easily fixed with an op-amp in my experience. You have to drive the chip with a source impedance of less than around 20k ohm to get good readings.
At the time I tried using the various sample rates, I was trying to get a faster set of readings but then @rickkas7 wrote some nice code that did that better and I used his instead. I remember making a spreadsheet with all the settings and some test values but I’m sure I don’t have it anymore.
Are you sure to only read the ADC when your motor is not moving? That could be another source of noise. Conducted noise and droop on the power supply directly affects the ADC readings, so that would be the first thing I would look at. RF shielding and wire routing would be next.
I am using the default sample rate.
When I wrote my project code, I was somewhat aware and concerned about the noise and “problems” with ADC from my previous projects, and from reviewing other forum comments. I was aware that my read/drive cycling could be suspect. That led me to investigating the Particle Reference and Forum. This “Interesting results…” thread was both scary and reassuring at the same time.
I do not need fast, just consistency. I am confident that my fix of 3 reads averaged and delays between reads will provide the stability needed for this backyard project.
As I move from prototype to installation, I will be sure to keep your comments in mind.
Thank you for your assistance.