32 replies to this topic

[Mario Vernari]

Chris? How long takes a single ADC read? Why not perform a free running of ADCs (i.e. background), then the "managed read" would be a mere ram access? Another way could be every slow-clock tick...

[sism3477]

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?

[Mario Vernari]

Good morning everybody! (at least here is a sunny morning)...

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
            |
            |
          ground

I 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

[Nevyn]

+12V ---R2------ ADC in
            |
            |
           R1
            |
            |
          ground

I don't know what's the English name of this pattern/cell: we call it as "partition of resistances".

Could use one of two terms:

Voltage divider
Potential divider

Regards,
Mark

[Chris Walker]

Hi Mario, Here's how to help narrow down if it's a software or hardware issue: Reflash your Netduino Plus with the "regular" Netduino firmware. This will disable all the networking features of the software. Once you connect an Ethernet cable, the lwIP network stack starts firing off a bunch of interrupts. These can interrupt the analog readings--skewing the results. We're looking at possible side effects of disabling interrupts during analog readings, and hope to have a good test case baked into an upcoming beta firmware release. You can also play with the source if you'd like... Analog inputs are tricky. Let's see if we can get this taken care of... Chris

[Mario Vernari]

I read about the solution with the standard N fw, but I like actually the features of the plus one. It was only a concrete test to inspect what exactly is the cause of the misreading. If you remember my "attempt" to make a simple signal processing, I abandoned the project because the results were unreliable at all. Part of the project is the "Silverlight web server", which is the only section working very well! Now, I may reconsider the project as soon the ADC problem will be solved. Since that app requires the web connection, it makes no sense at all reflash my board. I asked you on another thread: why don't perform a free-running readings of the ADCs, so that the analog port "Read" method is much like a RAM access? ...or, could we consider making all 6 ADC readings every slow-clock (always putting the results in a cached array)? Thanks

[Chris Walker]

Hi Mario,

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).

To use the external AREF pin (Rev B+ boards), you need to switch the AREF from internal to external in code.

    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

[Mario Vernari]

To use the external AREF pin (Rev B+ boards), you need to switch the AREF from internal to external in code.

I have a Rev.A board.
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

[sism3477]

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.

[Chris Walker]

Has this issue ever been addressed? I am curious about continuing with my project but cant until this is sorted out.

We're looking at it in detail as part of the .NET MF 4.2 release (and the new AnalogPort classes).

[Igor Kondrasovas]

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.

[Chris Walker]

Hi Igor,

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?

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

[Igor Kondrasovas]

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,