ADC Reading wrong?
#21
Posted 12 May 2011 - 03:12 PM
#22
Posted 12 May 2011 - 03:32 PM
That's very helpful feedback.
The analog inputs do not block the Ethernet interrupts when they measure readings. We may need to tweak this so that all interrupts are disabled temporarily. That's not a bad thing to do if we're conducting a quick operation--but for extended readings it could be troublesome.
We'll explore it. Thank you again for the testing.
Chris
So is there any work around I can do for the time being?
#23
Posted 13 May 2011 - 07:16 AM
Today I made some test around the ADCs, because I had some suspect about the correctness of the readings.
The test circuit is very simple:
a regulated power supply (a lab one);
my Netduino Plus powered by USB connector;
a LCD 16x2 module driven by the N+ (via HC595);
6x different combinations of resistors.
The USB (from PC) supplies power to the N+, to the LCD and nothing else.
The reg supply (+12V) feeds energy to 6 voltage-divisors, one for each analog input:
+12V ---R2------ ADC in | | R1 | | groundI don't know what's the English name of this pattern/cell: we call it as "partition of resistances".
Anyway, each cell has different R1,R2 values so that the voltage seen from each input will be different also.
However, all of the inputs have a voltage under +3V, so below the Vref=+3.3V limit.
Each cell has a 5-10uF capacitor in parallel to R1.
The Vref is just +3.3V, but *NOT* supplied from the N+ power. That's to avoid any noise/spike coming from the N+ board. Is the same reg supply providing the Vref by a dedicated partition of resistances (and capacitor).
By using a multimeter (3 1/2 digits), I checked any of the voltages: they are very stable. The least digit of the meter won't change.
Let's go to the software side.
The test app is trivial. There is the LCD driver only, then a silly "while(true)" loop that reads each analog input and prints it on the screen, as an integer 0..1023.
When the app starts, the values shown on the LCD are pretty stable: +/- 1 units out of 1024.
Taking a value and dividing it by 1023.5 (the logical scale of the ADC), gives exactly the same ratio of the analog input divided by the Vref.
In other words: everything going very well!
What's the problem?
By the way there is not any problem, until I leave the Ethernet cable disconnected!
As soon the cable is plugged to the board (even without managed software using it), the ADC readings going crazy literally. Of course, the Ethernet cable is connected to my router at this other side.
At this point the values shown have lot of noise, even +/- 8 units out of 1024, without any (apparent) reason.
As soon the cable is disconnected again, the values become stable also.
Of course, by checking the analog inputs with the multimeter, they are stable in any conditions.
As for me, it looks much more an hardware problem instead a software one, or a very low-level issue.
Hoping that these infos could be useful for Chris, I will wait for some tips from him.
Cheers
#24
Posted 13 May 2011 - 07:49 AM
Could use one of two terms:
+12V ---R2------ ADC in | | R1 | | groundI don't know what's the English name of this pattern/cell: we call it as "partition of resistances".
Voltage divider
Potential divider
Regards,
Mark
To be or not to be = 0xFF
Blogging about Netduino, .NET, STM8S and STM32 and generally waffling on about life
Follow @nevynuk on Twitter
#25
Posted 13 May 2011 - 10:14 AM
#26
Posted 13 May 2011 - 10:23 AM
#27
Posted 13 May 2011 - 10:27 AM
To use the external AREF pin (Rev B+ boards), you need to switch the AREF from internal to external in code.The Vref is just +3.3V, but *NOT* supplied from the N+ power. That's to avoid any noise/spike coming from the N+ board. Is the same reg supply providing the Vref by a dedicated partition of resistances (and capacitor).
OutputPort internalArefSelect = new OutputPort((Cpu.Pin)56, false); internalArefSelect.Write(false); // disables the internal AREF, enabling the external AREF.The internal aref is selected by default. We'll be adding a class to do this in an upcoming firmware release (using AnalogInput), but this will allow you to switch it manually in the meantime.
Chris
#28
Posted 13 May 2011 - 05:26 PM
I have a Rev.A board.To use the external AREF pin (Rev B+ boards), you need to switch the AREF from internal to external in code.
Right now I tried to detach the Aref pin from the source and the LCD shows all 1023's.
I'd consider a free-running conversion, at least for the plus version.
Cheers
#29
Posted 04 August 2011 - 10:11 PM
That's very helpful feedback.
The analog inputs do not block the Ethernet interrupts when they measure readings. We may need to tweak this so that all interrupts are disabled temporarily. That's not a bad thing to do if we're conducting a quick operation--but for extended readings it could be troublesome.
We'll explore it. Thank you again for the testing.
Chris
Has this issue ever been addressed? I am curious about continuing with my project but cant until this is sorted out.
#31
Posted 28 August 2012 - 02:01 PM
That's very helpful feedback.
The analog inputs do not block the Ethernet interrupts when they measure readings. We may need to tweak this so that all interrupts are disabled temporarily. That's not a bad thing to do if we're conducting a quick operation--but for extended readings it could be troublesome.
We'll explore it. Thank you again for the testing.
Chris
Hi Chris,
Is there any progress about this (since it is a relatively old post)? Am I writing to say that even today, I might get better results with Netduino classic firmware?
Regards,
Igor.
Igor Kondrasovas
www.inovativatec.com
#32
Posted 28 August 2012 - 07:18 PM
Large and irregular current draws like Ethernet traffic can create ripples on the 3V3 rail and therefore a bit of bounce on analog readings.Is there any progress about this (since it is a relatively old post)? Am I writing to say that even today, I might get better results with Netduino classic firmware?
Generally microcontroller developers will average out several readings which gives more accurate readings.
If you're having trouble getting a good analog input, there are quite a few ways to deal with that. One option is to average out analog inputs. Another is to flash your board with the non-Ethernet firmware (or simply unplug the Ethernet cable). The best real-world solution is to place a 100uF cap between the 3V3 and GND headers...providing some bulk smoothing on the 3V3 rail.
We have taken a similar approach with the Netduino Go hardware line, using a fast-response DC-DC switch on the mainboard and placing bulk smoothing caps on the Shield Base to help offset sudden current draws (from other modules).
Chris
#33
Posted 28 August 2012 - 07:22 PM
Hi Igor,
Large and irregular current draws like Ethernet traffic can create ripples on the 3V3 rail and therefore a bit of bounce on analog readings.
Generally microcontroller developers will average out several readings which gives more accurate readings.
If you're having trouble getting a good analog input, there are quite a few ways to deal with that. One option is to average out analog inputs. Another is to flash your board with the non-Ethernet firmware (or simply unplug the Ethernet cable). The best real-world solution is to place a 100uF cap between the 3V3 and GND headers...providing some bulk smoothing on the 3V3 rail.
We have taken a similar approach with the Netduino Go hardware line, using a fast-response DC-DC switch on the mainboard and placing bulk smoothing caps on the Shield Base to help offset sudden current draws (from other modules).
Chris
That's sounds great for me!
Thank you,
Igor Kondrasovas
www.inovativatec.com
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users