Hi

If I use the sample Code for the temperature sensor the actual temperature is not displayed on the LCD. Instead it says nan for the number it's supposed to display there.

I'm using Ubuntu Hardy Heron. How can I read the data the Kit is sending through the USB port?

Thanks for your support

Christof

Christof, I had the exact same problem. It stems from using an older avr-libc version. You can check your version using :

dpkg -l avr-libc

from the console. I'm using 1.6.2

To upgrade (if needed) you can use this (safe) deb to install a working version : avr-libc

You may need to uninstall your original first.

Hope this helps!

Forgot to mention : If you do have to remove the old one use "sudo apt-get remove ..."

It should work after that!

Thanks a lot for your fast reply. Everything works fine now.

How can I read the data from the USB connection to the Kit?

haha : I also asked the Nerdkits team that question too :)

You need to use minicom

sudo apt-get install minicom

Look at the "Serial Port Communication -> Linux" section of this page : servosquirt

It describes the setup for this.

All the above information is basically what the nerdkits team suggested I do when I asked the same questions - I wouldn't have figured this out myself.

If you have any more questions, do not hesitate to ask. (Welcome to the forums btw!)

Thanks again. Works fine.

I am having similar issue, except mine displays 'inf' for the temperature value. Upgraded avr-libc-1.6.7 with no change. I used C-kermit to connect over serial port and it displays the same thing. Using the serial port I printed the values for each variable in main(). It seems that the result (or lack of) from sampleToFahrenheit() function is returning zero. I printed last_sample to the serial port, and manually ran the formula in sampleToFahrenheit() and I get back the correct temperature. Trying to print any result beyond that returns 0.

Running openSuse-11.1 and the following avr tools... cross-avr-binutils-2.19-9.1 cross-avr-gcc43-4.3.3_20081022-9.3 avrdude-5.5-111.33

double sampleToFahrenheit (uint16_t sample) {
    return sample * ( 5000.0 / 1024.0 / 10.0 );
    }

Never mind, after posting this I noticed the space between the function declaration and the arguments. Cleaning that up fixed the problem! :)

Hi apurcell,

I think that avr-libc was likely your issue. The space itself isn't anything wrong -- but changing it would update the timestamp of the file, and would force your next execution of "make" to recompile it against the new version of avr-libc. (Make tries to be smart about recompiling, and only does it when the named source code file has changed more recently than the output file. But it didn't notice that avr-libc itself was upgraded!) Does that make sense with what you observed?

Mike

That does indeed make sense. I wonder what was wrong with the previous avr-libc that would allow the program to build yet have that one function misbehave.

Thanks for the feedback.

Anthony

There seems to be another way to make this work with avr-libc 1.4.x: apply floating point conversions to 8-bit numbers. I made the following two changes to the suggested code:

// double sampleToFahrenheit(uint16_t sample) {

double sampleToFahrenheit(unsigned char sample) { // Now this function takes an 8-bit argument

return sample * (5000.0 / 1024.0 / 10.0);

}

...

int main() {

...

// this_temp = sampleToFahrenheit(last_sample);

this_temp = sampleToFahrenheit((unsigned char) last_sample); // Call with 8-bit argument

...

}

With these changes the code works with avr-libc 1.4.x. So it seems that the problem is in casting 16-bit unsigned integers to floating point numbers. Does anyone know if such a bug is known in avr-libc 1.4.x? I could not find a relevant bug report online.

Thanks!

Deepak

It's still early so I may not be thinking straight yet, but I'm seeing a function call with an unsigned char as a parameter, and an unsighed 8 bit char can carry a max value of 255 (0 to 255), whereas I believe the function is meant to take values of 0 to 1024 no?

0 to 1023 I mean If I am correct on what the ADC returns....