ATMega328 internal resonator for MySensors sensor?

PaulRB wrote:

mrbwa1 wrote: If the calibration data is available, then you should be good to go.

Here is a link to a page about these sensors. There is some calibration data, these are "cheap and cheerful" sensors!

That's awesome! I hadn't run across those yet. I eventually want to add wind instrumentation and was looking at hacking the 433MHz radio stream from one of the Oregon Scientific units so that I didn't have to do so much work myself.

wind speed/direction isn't too big of a deal for me at the moment because we have a local Weather Underground station I can get that data from. I would eventually like to try and hack a handheld anemometer to get a more portable solution

wergeld wrote: I have it running at 8 MHz and off of 2 AA batteries plugged directly into the ardunio's VCC... In the mySensors sleep mode (power down) i draw 50 microAmps.

I am using the internal resonator and will drop this down to 1 Mhz as well.

Hi all, I have my MySensors sensor running on the ATMega328 now. I had some trouble at first, and may have "bricked" the first '328, no idea why/how. I was careful with it. It ran at first. but following a minor code modification, it refused to run or accept further uploads from the Arduinio IDE. I may try ISP programming it later, in case the bootloader got corrupted.

But the second '328 works great. Similar to wergeld, I am running the sensor directly off the batteries, but I am using 2xAAA rather than 2xAA. I have a BMP085 pressure, an SHT21 temp/humidity and an LDR connected. Also an LED which flashes once per minute as the sensors are read and the data is transmitted, which gives a reassuring "heart-beat"

Initially the whole circuit was drawing around 350~400uA during sleep, which was quite a bit more than wergeld's. With my multimeter I soon figured out why. I had the LDR, connected to +V, and a 10K resistor, connected to ground, acting as a voltage divider to feed an analog input. This combination was drawing 300~350uA. So instead of connecting the LDR to +V, I connected it to a spare output on the '328. The sketch switches that output to HIGH before reading the analog input, then back to LOW. To allow the LDR time to settle, the sketch reads the other sensors between switching the output HIGH and performing analogRead(). During sleep the current is now only 34uA!

So there is little point reducing the '328 clock to 1MHz in order to reduce current consumption. However, according to ATMEL's data sheet, the '328 needs around 2.4V to run at 8MHz and only 1.8V at 4MHz. So that should enable the sensor to run a longer on batteries. The SHT21 sensor has a minimum of 2.1V, so that would be the first thing to fail as the batteries discharge.

Running at anything below 8MHz means that the bootloader will not run. It can be recompiled to run at lower speeds, so I may look into that later.

There is another thing I had trouble with while working on this. Uploading the sketch with my new FTDI USB to serial adaptor was very unreliable. For short sketches like blink, rf24 scanner, and the test sketches for the sensors, it seemed fine. But the full MySensors sketch is 25K long. 4 times out of 5 it would fail part way through, giving a "programmer not responding" error. Any ideas why this could be?

Hello,

today i played with this battery powered pro mini and burned fuses and noticed the same as PaulRB - unreliable uploading the sketch. I tried with ftdi usb and with usb tiny.
I was getting avrdude: verification error, first mismatch at byte. Also interested in solving this catch.

gasper wrote: I was getting avrdude: verification error, first mismatch at byte. Also interested in solving this catch.

Hi gasper. It does not sound like your catch is quite the same as mine. Let's hope I am wrong!

I admin the error is different, but the point i can succesfully upload some simple sketch like blink every time made me think it is simmilar error like yours. Maybe it has something to do with lower pro mini speed (1mhz) or usb power supply? Im just guessing beacuse i have no idea...

I wondered if the internal oscillator, being less stable than an external crystal, was leading to inaccurate timing of the serial data, causing apparently corrupt data to be received or transmitted to the ftdi chip. I'll google that theory.