NerdKits - electronics education for a digital generation

You are not logged in. [log in]

NEW: Learning electronics? Ask your questions on the new Electronics Questions & Answers site hosted by CircuitLab.

Support Forum » Multi sensors part three Bad readings

April 06, 2010
by Ralphxyz
Ralphxyz's Avatar

Note the Sensor readings on the LCD at the right.

PC0(Sensor0),PC2(Sensor2) and PC4(Sensor4) are at VCC 4.92 volts.

PC1(Sensor1),PC3(Sensor3) and PC5(Sensor5) are at GND.

Sensor0 (PC0) is reasonable accurate with 494 at 4.92 volts.

Sensor2 (PC2) is approximately 2 times Sensor0.

Sensor4 (PC4) is approximately 3 times Sensor0.

Both Sensor2 and 4 should also read 494.

Sensor1 (PC1) should be 0.00 but at 499

Sensor3 (PC3) is approximately 2 times Sensor1.

Sensor5 (PC5) is approximately 3 times Sensor1.

Sensor 1, 3 and 5 should read 0.00

To see the code and more pictures.

The other pictures illustrate using multiple LM34s and one pot.

This is my first project and I really do not know programing, electronics or microprocessors so I relly need your help.

I have seen other threads where people had problems with multiple sensor readings but did not see a applicable solution for my problem.



April 06, 2010
by hevans
(NerdKits Staff)

hevans's Avatar

Hi Ralph,

I have to admit we were quite perplexed by this one for a while, but I think we found the issue. Take a look at this section of your code, and pay particular attention to how it does the averaging:

for(i=0; i<100; i++) 
  last_sample = adc_read();
  this_temp = sampleToFahrenheit(last_sample);

  // add this contribution to the average
  temp_avg = temp_avg + this_temp/100.0;

      //...sets the right sensor to temp_avg


Your code ends up with an average reading by taking each sample, dividing it by 100, and adding it to a running total (this is mathematically equivalent to adding up the 100 samples and then dividing by 100). However, this only works if temp_avg starts at 0. In your code, you forgot to reset temp_avg every time you switch to a new mux channel and begin taking new readings. This explains why the next channel is always the average reading of the previous channel plus the average reading of the current channel. If you add temp_avg = 0 right after ADMUX=mux; it should solve this issue.

On another note, you mentioned in your comments that averaging over 1000 was not working. Remember that the variable i is an 8 bit integer which means it can only store values up to 255 before rolling over back to 0. In the case where the test in your for loop is i<1000, i will always be less than 1000 because it can only go up to 255! So it never exits that loop. If you want to have longer for loops you need to make the counter variable a uint16_t or uint32_t as necessary.


April 06, 2010
by Ralphxyz
Ralphxyz's Avatar

"we were quite perplexed by this one for a while"

That is because I act like I know what I am doing and you didn't even consider that a "programmer" would overlook something so obvious.

I knew what it was doing "the next channel is always the average reading of the previous channel plus the average reading of the current channel" but could not figure out why.

re: the i<1000 my last post was confirming I understood your explanation. That too would have been caught by a experienced programmer.

Thank you so much this is really exciting, taking longer than expected but I was starting from almost scratch.


Post a Reply

Please log in to post a reply.

Did you know that you can make a huge, multi-panel LED display? Learn more...