I am using the G120’s onboard ADC with .NetMF 4.3 2014 RTM QFE1 and NETMF and Gadgeteer Package 2014 R5.
I understand there is a push to move to the TinyCLR OS, however I cannot move to the new libraries\framework just yet.
Problem:
On rare occasions, the ADC values read from the LPC1788 may read 0 (and remains until the G120 is power cycled), despite the component monitored measuring a non-zero voltage. When this occurs, not all channels read 0, most work and usually only one channel doesn’t.
Discussion:
If this was a hardware issue with the chip I would simply replace the Cobra board with another, however I am seeing this across multiple boards.
My next thought was the 3.3v reference voltage to the ADC chip may not stable but then I would most likely see an incorrect voltage rather than a 0 from the ADC.
I was reading through the LPC1788 user manual, page 820 and the ADC control register has a Burst mode which reads through all enabled ADC channels.
Some further reading on NXP’s errata, page 6 says when reading from the ADC in Burst Mode, the read value should be obtained from the individual ADC channel registers rather than the Global Data Register.
tl;dr Question:
Are the G120 ADC reads coming from the ADC Global Data Register (GDR), or the individual ADC Channel Registers?
Apologies if this topic already exits, I have not found it.
We have noticed this also, but have never solved. We currently just have our code check if we are getting valid ADC readings off the power input on init. If not we reboot until we do see a good reading.
I am in the process of writing some native code to disable Burst mode and read the individual ADC registers.
Plus power cycling the ADC chip on G120 bootup.
I’m not 100% sure if this will resolve this issue.
The ADC on the G120 is very noisy and really only works well if your sensor is ratiometric and can be powered from the 3.3V supply. With a decent digital filter it cleans up but not nearly as well as a decent ADC with a stable reference.