This forum has moved to forum.jeelabs.net - this read-only archive is for reference only!
Hello!
I just declared my weather station project to be in be beta stage!
It uses a JeeNode with 4 sensors gathering weather data and it is all "home made", it even includes some power saving features. I will try to write something about it here soon, along with the code I used.
You can check some pictures in:
Happy New Year!
I like you anemometer!
Regarding battery life: I see currently you send packets every 10 seconds, have you considered switching off the RF12 for a while (a minute or so) and sending a batch of packets?
Thanks!
I send the packets every 10 minutes, more is not really necessary for weather data, and even that might be too much...
In between I switch off the power to the sensors, and put the Atmega in some power down state, from which it wakes up every 2 seconds or so, after many times, I read the sensors and send the package.
I tried with the power saving as was described until http://news.jeelabs.org/2009/07/05/ligthy-power-save/ , but the thing hang every once in a while and I could never find an explanation - debugging is difficult... - mostly it hang when I placed it outside, so I think it could be some clock problem leading to a conflict in the watchdogs, but this was when outside was about 10C, not even as cold as now...
So I found this http://interface.khm.de/index.php/lab/experiments/sleepwatchdogbattery/ and it works...I do not power down the RF12...
My multimeter, admittedly not the best one, not even close, can not measure any current going into the jeenode when the sleep mode is on, so I guess it is very low.
Powering down the RFM12B as @kellerza suggests will save a lot of power - see http://news.jeelabs.org/docs/rf12sleep().html
I also use the avr watchdog timer and the RF12 sleep mode (mode 0 and -1), that works fine. The RF12 sleep timer doesn't work. After on or two hours the jeenode stops working.
I've had some problems with the RFM12B as watchdog as well. Some units work fine, others stop - usually within hours. I suspect it's caused by lost interrupts, but I haven't investigated further yet. Can take some serious head-scratching to figure this stuff out, it's very hard to debug. I may go back to the ATmega watchdog - it's good enough for low-power use.
Glad to know that the problem is, if not reproducible, at least, recurring, and that I was not the only one to experience it.
I will try the RF12 sleep mode, as anpfeiffer suggests, not using the RF12 watchdog.
But now I am curious to see how far these batteries will take it. It is now almost 1 month. At 15 days I measured the voltage and it was down to about 4.1V, so I expect another month or so out of it. Then I can do the RF12 thing and compare!
Meanwhile, it has just registered -5.1C!
It is possible to check the battery state with the RF12 and send it, but this cost some milliseconds:
change:
#define RFIDLEMODE 0x820D // enable Lowbatt interrupt
add this to the rf12.cpp/h
uint8t rf12getbattstate(void)
{
unsigned char ubatt;
unsigned int status;
ubatt = 0;
do
{
rf12xfer(0xC040 + ubatt);
delay(10);
status = rf12xfer(0x0000);
ubatt++;
}
while (!(status & 0x0400) && (ubatt < 0x10)); // 0x0400 ist LowBattDetector (LBD)-Bit
rf12recvStart (); // clear interrupt
return ubatt+22-1;
}
P.S. that only works, with a accu connected to the 3.3v pin.
Great trick! Is 10 ms the minimum delay needed? If it's less, maybe we could do this while the receiver is on, and then read-out just before starting a transmission? That way we'd overlap with things which already take a few milliseconds. Hm, I need to read the datasheet ...
One advantage is that it could be used to see when the 3.3V drops (even with a battery tied to PWR), hopefully in time to still have enough voltage to send out some packets. An alternative approach would be to dedicate an analog pin to read from a 1 M? + 1 M? divider between PWR and GND.
My pressure jeenode still works with reported 2.8v. But i think it is dead at 2.7v...
The 1M+1M solution is the better way, i think.
You're not running at 16 Mhz, though, right? Because it's already slightly out of spec @ 3.3V, my concern would be whether a JN can function at 3.1 .. 3.2V, just enough to see the VR voltage drop, yet still enough to report the impending battery failure...
The other thing to watch out for is that the voltage drop will probably only show up during high current use (during transmission would be the worst case). Not sure - don't know how the voltage of an unloaded battery acts when nearly discharged.
I just put the source code I used (still without the sleep of the RF12) on the wiki
http://wiki.jeelabs.net/p/79
As for low voltage, while I was debugging the code, I had it working with a set of cells that went down to 3V, and that was measured with no load on the AA cells.
Maybe it would also be interesting to get the JeeNodes to work in their specified range, by getting them to run at e.g. 8MHz, since not only would that save power, but would make them more reliable for this kind of extreme applications. For nodes that are only collecting data and sending it, not much processing is required at the node anyway
Yes it is out of spec with 16Mhz and today 2.7v, but it still runs.
@amvv - You could make the JN run at approx 8 MHz by setting the fuse bits to run on the internal oscillator, the 10% (uncalibrated) accuracy should be ok for basic sensor node operation. It might not be good enough for the serial port baud rate, though.
@anpfeiffer - Nice. I see that the low power detector needs only 0.5 µA extra, and is accurate to within 5%. It might be an idea to fix the level to 3.1V and add a small function to pick up the low/ok bit for sending as part of the packets. Won't give insight in actual battery state, but it might be enough as warning system.
So we can use this flag with the next release of rf12.cpp?
I've added a new "rf12lowbat()" function - see http://news.jeelabs.org/docs/rf12lobat().html
Also added an example of use in the rooms sketch - see http://code.jeelabs.org/viewvc/svn/jeelabs/trunk/rooms/
The low-battery detector circuit is now permanently enabled at 3.1V.
Neither of these have really been tested yet. Haven't gotten to hooking up a node yet, to see what happens when the supply voltage is gradually lowered. One concern is that the LBD flag will generate an interrupt, but I don't really know what clears that interrupt again. It may be necessary to disable the LBD circuit once the threshold has been reached, to be able to continue normally.
Hint: if you order an dallas 18x20 in germany for the room board, you get perhaps an ds18S20 (note the S, first byte of the address is 0x10). This chip always calculate 12bit and the conversion time is always 750ms! To get the 12bit precison, the code for this is completly different.
The DS18S20 (note S) is not recommended for new projects. As I noted on SparkFun:
A brief description of the differences between versions: The DS18B20's have 12 bit resolution capabilties. The original DS1820's (note lack of B or S) have 9 bit resolution. The DS18S20 (note S) was meant as a drop-in replacement for the original DS1820. It gets a 12 bit temp value but rounds it to a 9 bit value. You CAN however get 12 bit resolution with the DS18S20's but it requires extra calculations/reading of registers to be done that the DS18B20's don't require. The DS18B20's also allow you to specify 9, 10, 11, or 12 bit resolution programmatically. Taking 9 bit values takes less time and power.
How to decrease battery usage:
- sleep for longer.
- decrease oscillator frequency.
@amvv: I don't think you get the best usage from you batteries. You can easily sleep 8000x longer,-
My understanding of sleep mode:
Once you put the system to sleep, your'e normal loop() function will basically stop executing -right at the systemsleep() command.
The code will continue executing after the sleep command once its awaken. (Continue with the main loop())
ANY HARDWARE INTERRUPT will cause the system to wake.
The Arduino code base has a millis() function which uses a timer0 overflow:
See wiring.c, line 44: SIGNAL(TIMER0OVFvect).
That means you get waken up every millisecond and your main loop executes once (only once, since you have a systemsleep() at the end. Only until wdt also wakes you, and sets WDT=1
To get MUCH better battery usage, I would recommend the following.
-Disable TIMER0. (You cant use millis() then, or any function that depends on it for timing)
In your current code WDT will wake you up every set seconds
-Kill the counter/Period loop and the wdt variable - you only need this if other things disturbs your precious sleep.
- Serial UART activity will still wake you, but I assume the Rx pin is not connected
You loop() would become:
void loop() {
// DO THE STUFF
// will happen every WDT interval
systemsleep();
}
This approach kills millis(), but you can sleep for 8 seconds - this would be great for the battery!!
Note that you should probably enable TIMER0, when doing your stuff, since most Arduino related libs uses this (even the RF12 driver uses millis()). millis() would be correct in a relative way, not a correct absolute value (since uC startup).
void loop() {
ENABLETIMER0;
// DO THE STUFF
// will happen every WDT interval
DISABLETIMER0;
systemsleep();
}
If you want a absolute time value, you can count your wake-ups and multiply by the sleep time.
Hope it helps!
You can also use the power down mode, then TIMER0 is automatically disabled. I'll be going back to this soon since the RF12 watchdog approach isn't good enough yet. See http://news.jeelabs.org/2009/05/16/power-consumption-more-savings/ etc.
I wouldn't worry too much about waking up, even once a millisecond - the trick it to start up fast (fuse settings), to do little, and to go back to sleep as quickly as possible.
Thanks for the hints Kellerza!! I will try to check properly what is happening and compare with the current situation.
But yesterday I was too eager to just verify that the timer was indeed waking it up every msec, so I uploaded the sketch into another JeeNode, and added a serial port output on the loop. I was expecting a lot of output in between the 2 seconds wakeup of the watchdog, but these didn't come - all I got was a print every 2 seconds...so maybe indeed the power down mode is switching off the TIME0 like the key-master :) Jean-Claude said above.
I will try to investigate better these cases.
Meanwhile, just would like to report that the station has been outside, during the polar weather spell we are having here with consistent negative temperatures, for 25 days now, and still broadcasting! next time I open it I will try to implement the battery measuring with the 2 big resistors divider.
Sorry amvv, missed the power down mode in your code - Jean-Claude is right about that one disabling all timers.
I decided to implement the extra power saving by switching off the radio while sleeping, so today I opened up the weather station.
Good news: the battery, after more than one month is still at 4.08V while the system sleeps, which is the same as when I opened it a couple of weeks ago for water proofing...I start to think that they will last long!
So I put in the RF12sleep() with no radio watchdog, and did some optimizations in the code, e.g. to switch off the light sensor as soon as possible, and reduce the processing instructions in the loop (there was one unnecessary "for"). I am also now sleeping for 8 seconds between cycles, and sending the packet 3 times in a row, to decrease lost packages...I was getting about 50% reception recently...Lets see if it improves.
I will put the code on the wiki soon.
With the multimeter, I could read 1.2uA, but it is not a very good multimeter...I could not make a reading when the sketch didn't have the rf12sleep...couldn't figure out why...
Weather station update!
Finally, after 11 and a half months the thing died! in the coldest night of the year, after sending a packet indicating -8.1C outside at 3 in the morning...funnily enough, the FS20 switch that turns the boiler on and off died (stopped receiving) at approximatelly the same time...can't explain it, it wasn't cold in the room where that one is located... It sent 51273 messages on a set of 3AA GP branded units (I have seen similar ones in JC's posts), which were not new when it was put outside. Since for each packet I measured the wind for 1 second, this means the JeeNode was in full power mode for a bit over 14 hours. Anyway, I opened it, days later, and when the temperature outside was up to -1 and the batteries read about 1.9V, or about 0.6V per cell. I wonder if the fact that the Atmega runs at 16MHz, which is out of the specs at 3.3V (let alone 1.9V), contributed to it failing at low temperature/very low voltage as well, or if it could have been pushed any harder! It is out now with a new set of batteries, since yesterday, 8/12/2010, but I need to redo the anemometer, so I don't think these will be out until the batteries die again!
I think this was a victory for a JeeNode in low power mode!
Amazing. And great news indeed!
Running at 16 MHz on 1.9V, I would not have expected this. Note that the ATmega often fails to work with an AA Power board and the new diode in the JN v5 (i.e. roughly 2.5V).
The RFM12B is also running out of spec, which is 2.2..3.8V.