Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Sensors cross effect


  • Please log in to reply
17 replies to this topic

#1 Traveling Tech Guy

Traveling Tech Guy

    Advanced Member

  • Members
  • PipPipPip
  • 36 posts

Posted 30 May 2011 - 08:41 PM

Hi,
Still messing about with my Sensors project. Reminder: light sensor + temperature sensor + LCD - posting to Pachube.

Everything works well now, and updates the Pachube feed correctly. My next step would have been to use Szymon's shift register idea, to go down from using 10 pins for the LCD to 3 pins.

Only while taking a Youtube video of my creation, I noticed (and documented) an undesired behavior: if I shine a bright light at the light sensor, the temperature drops considerably (from 20C to 14C) and jumps back up when I move the light away.

Logically this has to do with resistance (as the resistance in the light sensor grows, it lessens in the temp. sensor), and with some co-dependency in the way I wired the circuit. But I'm not experienced enough to find the root cause.

So here's a Fritzing diagram of my board (again, pardon the wire mess and 2 boards - it'll hopefully go away soon). The two sensors are on the lower left, and are connected as follows:
- TMP36 temperature sensor: right leg -> GND; middle leg -> analog1; left leg - Netduino 3.3V
- CdS light sensor - right leg -> Netduino 5.5V; left leg -> analog0 + 1kΩ resistor to ground

Attached File  Sensors_bb.png   106.4KB   52 downloads

I figured since one sensor goes to 3.3v and the other to 5.5v they are separated. But maybe I've mixed the GNDs?

The code, as well as the full Fritzing file, can be found on github. The video can be found on Youtube (the effect can be seen at 1:48 into the 3 minute video).

As always, any help appreciated. And as always, I'll learn
Thanks!
Guy

PS: Fritzing question: I have this 330Ω resistor connected to the LCD at the lower part of the screen. Fritzing shows it as a 4-ring orange-red-brown-gold, while in reality it's a blue 5-ring orange-orange-black-black-brown. I guess they amount to (almost) the same thing, but how can I tell Fritzing to draw the right one?

#2 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 31 May 2011 - 03:56 AM

About the Fritzing resistor colors. The Fritzing drawn resistor is a 330 Ohm, granting an error within -/+ 5%. Orange is 3, black is zero and the 5% tolerance is gold. The resistor you used is much better: -/+ 1% (last ring brown). Since its precision, it has a ring more, so: orange-orange-black-black ==> 330.0 About the strange value. I noticed a strange jitter on the ADC readings on my Netduino PLUS, when the ethernet cable is plugged-in. As soon you unplug, the readings are stable. No workarounds, maybe an average. Could be that? Cheers
Biggest fault of Netduino? It runs by electricity.

#3 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 31 May 2011 - 04:24 AM

Hey Guy, If you move your 2 analog inputs to analog pins 4 and 5 (instead of 0 and 1), does that change anything? I know it sounds like an odd request. :) Chris

#4 Traveling Tech Guy

Traveling Tech Guy

    Advanced Member

  • Members
  • PipPipPip
  • 36 posts

Posted 31 May 2011 - 07:19 PM

Hey Guy,

If you move your 2 analog inputs to analog pins 4 and 5 (instead of 0 and 1), does that change anything?

I know it sounds like an odd request. :)

Chris


Hi Chris,
I tried your suggestion (temp. sensor A4, light sensor A5) and got the opposite result: when I shine a light at the light sensor, the temperature reading now jumps up considerably. I get readings of 230C in my room (luckily, untrue :) ).

The temperature sensor then proceeds to go up and down in a loop. It won't reset back to the 22C temperature unless I remove the flashlight.

But the cross effect is still there. May ask what were you anticipating?

Thanks,
Guy

PS: Something else I just noticed. After transferring the temp. sensor from A1 to A4, it now jumps up and down over the span of 4C, even without me doing anything. It's like something else on the board "irritates" it.

#5 Traveling Tech Guy

Traveling Tech Guy

    Advanced Member

  • Members
  • PipPipPip
  • 36 posts

Posted 31 May 2011 - 07:23 PM

About the Fritzing resistor colors.
The Fritzing drawn resistor is a 330 Ohm, granting an error within -/+ 5%. Orange is 3, black is zero and the 5% tolerance is gold.
The resistor you used is much better: -/+ 1% (last ring brown). Since its precision, it has a ring more, so: orange-orange-black-black ==> 330.0

About the strange value.
I noticed a strange jitter on the ADC readings on my Netduino PLUS, when the ethernet cable is plugged-in. As soon you unplug, the readings are stable. No workarounds, maybe an average.
Could be that?
Cheers

Mario,
My problems started before I added the Ethernet/network component (as you could see in the video) to the equation, and it keeps on happening now.

As for the resistor coloring in Fritzing - I realize both representations end up as 330 Ohm. I was just wondering if I could have Fritzing draw my actual resistor (i.e. 5 rings), rather than a similar one, or do I need to manually add a part?

Thanks,
Guy

#6 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 31 May 2011 - 08:01 PM

Hi Guy,

I tried your suggestion (temp. sensor A4, light sensor A5) and got the opposite result: when I shine a light at the light sensor, the temperature reading now jumps up considerably. I get readings of 230C in my room (luckily, untrue :) ).

Just to rule anything else out--were you operating without a network cable plugged into your Netduino during this test?

I'm just trying to sort out all the potentials here :) We've found a few analog sensors which don't work well...whether it's because they can't drive enough current or otherwise...that's what we're trying to sort out. Analog inputs should be pretty simple things.

Chris

#7 Traveling Tech Guy

Traveling Tech Guy

    Advanced Member

  • Members
  • PipPipPip
  • 36 posts

Posted 31 May 2011 - 11:21 PM

Hi Guy,

Just to rule anything else out--were you operating without a network cable plugged into your Netduino during this test?

I'm just trying to sort out all the potentials here :) We've found a few analog sensors which don't work well...whether it's because they can't drive enough current or otherwise...that's what we're trying to sort out. Analog inputs should be pretty simple things.

Chris


Hi Chris,
I tested twice - with, and without the network. The ranges of variance with the network cable are greater than without, but I can confirm bad behavior even when the network cable is not in use.

I then tried 2 modes of cable disconnect: one where the cable itself is still connected to a router, but the router is disconnected from electricity; and one where the cable is completely out. In the second case, it looks like the variance is smaller - almost to the point of no trouble at all, but once in a while the application gets frozen - the last 2 values remain on the screen and won't change again until a forceful reboot. I hope I have not damaged my Netduino with all these games.

To sum it up:
* if I do not have the network cable in, I get accurate results;
* if I have it in but with the router off, I get discrepancies and the program gets stuck after
several such jumps;
*if I have the cable in and the router on, I get crazy discrepancies (that get posted to Pachube sadly - my sensor graph was 14-24 C - it's now -30 - 306 :))

How's the Ethernet port affecting the analog pins? Anything else I can try?

Thanks,
Guy

#8 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 01 June 2011 - 02:58 AM

Hi Guy, When the Netduino Plus is talking to a network, there are a lot of interrupts firing the background. These may or may not affect the analog input values. We're doing some tests here to determine if we can disable interrupts completely during analog readings...to see if that clears things up. It's also possible that the ARM microcontroller on the Netduino has reduced analog accuracy when the embedded network MAC is in use, but it's more likely to be a software issue (resulting in different setup times, readings, etc.) Many microcontroller apps take multiple readings--and then average them. This may be a scenario with that sort of approach would be appropriate as well. Chris

#9 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 01 June 2011 - 03:44 AM

Try this average:

const float N = 4;
float actual;

actual = (adc.Read() + (N-1) * actual) / N;
The higher is N the smooth will be the filtering.
The step-response is somewhat exponential.
Cheers
Biggest fault of Netduino? It runs by electricity.

#10 Traveling Tech Guy

Traveling Tech Guy

    Advanced Member

  • Members
  • PipPipPip
  • 36 posts

Posted 01 June 2011 - 05:09 AM

Hi Guy,

When the Netduino Plus is talking to a network, there are a lot of interrupts firing the background. These may or may not affect the analog input values. We're doing some tests here to determine if we can disable interrupts completely during analog readings...to see if that clears things up.

It's also possible that the ARM microcontroller on the Netduino has reduced analog accuracy when the embedded network MAC is in use, but it's more likely to be a software issue (resulting in different setup times, readings, etc.)

Many microcontroller apps take multiple readings--and then average them. This may be a scenario with that sort of approach would be appropriate as well.

Chris


Hi Chris,
Thanks for clearing it up. Coming from software problem resolution background, I've seen plenty of problems that are caused by "environmental factors" - i.e. factors surrounding the actual issue, that you'd never even consider to be the root cause. The Netduino+ contains so many layers and functions (network, analog, digital, sd card...) that some background noise is sure to seep in once in a while. I'm glad to see you guys are on top of this. Hopefully it IS a software issue, and can therefore be solved in a future release (any news on 4.2 BTW?)

As for averaging readouts - yes, I thought of that, but how do you average -30 and +300? The behavior is such that the temperature jumps up (or down) and takes several seconds to normalize. If during that time a bright light shines on the senor, it jumps even higher. I'll have to have a longer period of time in my averaging equation - and that would mean losing some resolution (no biggie - it's a fun project, not a crucial application).

One other thing I thought of is registering when the light conditions change drastically, and ignore the temp sensor for several seconds afterwards - using the last sane reading. That would get rid of the peaks as well.

Guy

#11 Traveling Tech Guy

Traveling Tech Guy

    Advanced Member

  • Members
  • PipPipPip
  • 36 posts

Posted 01 June 2011 - 05:11 AM

Try this average:

const float N = 4;
float actual;

actual = (adc.Read() + (N-1) * actual) / N;
The higher is N the smooth will be the filtering.
The step-response is somewhat exponential.
Cheers

Mario,
I think the result of your equation is non-deterministic: you are using actual before initializing it.
But I see what you're trying to achieve. Still, as I told Chris, the sudden peaks are so far above the norm reading, that even with averaging I'll get crazy results.

#12 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 01 June 2011 - 05:30 AM

I proposed you an algorithm that we used tons of times, and it is working very well. Of course you must init the vars' values. The very first "actual" value should match the ADC read. If you own an Excel-like tool, try that function on the cells. Cheers
Biggest fault of Netduino? It runs by electricity.

#13 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 01 June 2011 - 05:38 AM

(any news on 4.2 BTW?)

There will likely be an early first beta of .NET MF 4.2 before the end of June. There's no official timeline, but Microsoft has already released and alpha and is really close to hitting the beta milestone.

Chris

#14 Traveling Tech Guy

Traveling Tech Guy

    Advanced Member

  • Members
  • PipPipPip
  • 36 posts

Posted 01 June 2011 - 05:38 PM

I proposed you an algorithm that we used tons of times, and it is working very well.
Of course you must init the vars' values.
The very first "actual" value should match the ADC read.

If you own an Excel-like tool, try that function on the cells.
Cheers

Thanks Mario,
I wasn't suggesting the algorithm doesn't work. Just that it seemed like the variable was uninitialized in the sample you attached.
I'll give your suggestion a try.
Regards,
Guy

#15 Mike Y

Mike Y

    New Member

  • Members
  • Pip
  • 8 posts

Posted 02 June 2011 - 12:35 PM

Gents,

I wanted to start a new thread to ask this question, but came across this discussion, which seems to be relevant.

I am trying to build a reflectance sensor array using one analogue input. The wiring diagram is as attached.

The example code is like this:

OutputPort ControlPort = new OutputPort(controlPin, false);
AnalogInput ADC = new AnalogInput(adcPin);
int[] Voltages = new int[10];
for (int i=0; i<Voltages.Length; i++)
{
// Read ADC
Voltages[i] = ADC.Read();
//Send a pulse to control line to move to the next sensor
ControlPort.Write( true);
Thread.Sleep(10);
ControlPort.Write( false);
Thread.Sleep(10);
}

I am using controlPin = D11 and adcPin = A2. After the completion of this algorithm one would expect Voltages array to be filled as following: 9 sensor readings (low voltage - dark, high voltage - light) and one array member reading higher than the others - the '0' IC leg is connected directly, not through the phototansistor. The high reading is not nesessary in Voltage[0] as the chip is not being reset.

What I found was exceptionally strange. The readings fluctiate a lot, which includes the direct voltage reading (pin '0') as well. Sometimes it reads what is supposed to - ca 1000 (I adjusted the pot to read 3.1V on the A2 input pin, while on '0' line), sometimes significantly less. I have a scope hooked up to the output, the voltage is fine and does not fluctate at all.

I modified the wiring by hooking up the Reset to another digital output (D10). The code is as following:

OutputPort ResetPort = new OutputPort(resetPin, false);
OutputPort ControlPort = new OutputPort(controlPin, false);
AnalogInput ADC = new AnalogInput(adcPin);
int[] Voltages = new int[10];
// send reset pulse
ResetPort.Write( true);
Thread.Sleep(10);
ResetPort.Write( false);
Thread.Sleep(10);
for (int i=0; i<Voltages.Length; i++)
{
// Read ADC
Voltages[i] = ADC.Read();
//Send a pulse to control line to move to the next sensor
ControlPort.Write( true);
Thread.Sleep(10);
ControlPort.Write( false);
Thread.Sleep(10);
}

Now I would expect Voltages to be as following: Voltages[0] - the highest reading, then 9 readings of something less, depending on light. No luck. The ADC reading continue to fluctuate a lot. Some runs, it works perfectly, sometimes some of the sensors are reading near-zero.

I suspected the sensor interference, so replaced the phototransistors with 1K, 10K and 20K resistors. Same problem - the readings are not stable, sometimes way lower than expected. The scope shows the perfect "staircase," but the ADC sporadically reads near-zero voltage!

What I mentioned, was another thread running on my Netduino - serving the serial port and inputs A0 and A1 (the first one is measuring the battery voltage and the other one is connected to Sharp distance sensor). The more frequently I send the requests to that thread, the more pronounced the ADC problem becomes. Killing the serial port thread improves the situation. Also, moving from A2 to A5 improves the readings (less number of sporadic readings, but still present). And, while the multiple calls to A2 are going on, A1 distance seems to jumping quite a bit.

May be I am wrong, but something very fishy is going on with ADCs while the processor is busy or doing interrupts! Or, may be I am doing something stupid?

Anyway, would be nice to know how the ADC code works...

Best regards,
Mike

#16 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 02 June 2011 - 12:51 PM

Mike, the jitter around the ADC reads is a known behavior if you own a Netduino Plus with the Ethernet cable plugged in. Is it that? Follow my previous tip to trim any dispersion around the actual value. Cheers
Biggest fault of Netduino? It runs by electricity.

#17 Mike Y

Mike Y

    New Member

  • Members
  • Pip
  • 8 posts

Posted 02 June 2011 - 11:41 PM

How interesting! First of all, disconnecting the USB and going to battery power does not change anything - the ADC is still glitching, the busier the serial port thread the more glitches to be seen. However, as soon as I moved all the Read() calls for all the analogue ports to the same thread, everything had began working without glitches, and for all the ports (A2-A5, while A0 and A1 are acquired in the same thread). My question is: "Are we positive that the AnalogPort.Read() is thread-safe"? E.g. lets assume the Read() is called for port A2 on the thread ONE. While it is executing, the serial port creates an event on thread TWO, that in turn calls Read() for ports A0 and A1. The thread TWO receives the correct ADC values and quits the event, returning control to the Read() still executing on thread ONE. That one does not receive the right value for some reason, e.g. a static variable is lurking some place in the code... More troubleshooting to follow. --Mike

#18 Mike Y

Mike Y

    New Member

  • Members
  • Pip
  • 8 posts

Posted 02 June 2011 - 11:59 PM

Just in case, the overview of setup, in case I have overlooked something...

Attached Files






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.