This little project has certainly taken on a life of its own. I've been at this for several weeks now watching what goes on with batteries and various components and software. My latest set of revisions is almost a start-over.
I removed the Ardweeny I was using and replaced it with an Arduino Pro Mini. The little Pro Mini is designed for folk that want the power of an Arduino without the bells and whistles. There's no place to plug in wires, no screw holes to mount it, take a look:
The disadvantage is that it has an LED and a voltage regulator on it. Voltage regulators waste power by having a ground reference and a small amount of current through it that can run my batteries down. However, this regulator is a SE5509BALG and it has a ground current of only 21 uA, so that may not be a problem. I've run across folk that pull the regulator out to decrease the current draw, but I need some kind of regulator to supply the XBee with 3 volts. More on that later.
The LED is no problem, I can just pull it off the board if I can see it well enough.
I also switched from the TMP36 temperature sensor to an 18B20 one wire device. The reason I didn't start with the 18B20 was that I didn't have one to try. During the testing of battery operation, I ordered some and decided that now was the time to try them out. My decision to switch was partly curiosity and partly laziness. When I tested my code on the Pro Mini, I found a problem with the analog to digital converters. It seems when you switch them around to read the processor voltage, they don't settle out correctly on the different version of the 328 chip on the Pro Mini. I was going to research the problem and work around it, but realized that the one-wire 18B20 didn't need analog conversion, it's all digital. Problem solved.
Then, I went to three batteries. All the experiments indicated that I just didn't have enough voltage range to get long battery life. The AA batteries supply power very well all the way down to about 0.9V, and then they drop off pretty rapidly. With two batteries, that means I can't get close to the maximum capabilities of the batteries because my circuitry drops out at just under 2.8V. I can only drag the batteries down to 1.4V each and that means I'm wasting almost half a volt of useful power.
Using three batteries and a 0.9V limit I can drag most of the power out of the AA batteries and do useful things with it.
Now do you see why I need the voltage regulator? Three AA batteries will give me 4.5 volts and a very hot XBee. With the low dropout, low current voltage regulator on the Pro Mini, I should be able to get a long period of life before I have to change the batteries and still power the XBee just fine.
This is what it looks like right now:
I tried to hide the LED so the picture would be clearer. The 18B20 is on top, bent over a bit so it can catch whatever breeze may happen along. I used the same rubber band, but it may have to be replaced soon, starting to dry out and crack. Things are really crowded on purpose, I'm trying to keep all the circuitry on a half sized protoboard. At some point I'm going to solder all this stuff down and actually use it.
So, it's in service right now measuring temperature every minute and sending it to my house controller. I loaded it with dead batteries from the previous attempts. Not only is that saving me money, it should also die more quickly from draining the batteries. Similarly, I left the LED in to consume more power to get to that point. Battery operated tests take a long time to learn what happens at the end if you don't do something like that to hurry things along.
The compromise is that the processor voltage is after the voltage regulator. That means my measured voltage is going to be level until the batteries are nearing the drop out point. I could get around that with some clever rewiring, or a separate regulator for the XBee, but this test may give me all the information I need. I'm just going to look for a level voltage reading until the end where the voltage regulator drop out happens. With the LED running, it shouldn't take too long. If it does take too long, I'll think a bit about a voltage divider from the unregulated voltage to give me a sample measurement. If anyone's interested the code will be in GitHub in about an hour or so.
More later.
The next post in this series is here <link>
The DS18B20's are all I use.....
ReplyDeleteHi Dave, wanted to understand why did you choose to not connect the Temperature sensor directly to xbee. This question is more relevant for the TMP36 project that you published. Was it purely because you had to average out the readings before you would send it to the house controller? Xbee S2 2mW radio can operate down to 2.1 volts. Just curios. As always thank you for this great post!!
ReplyDeleteHG
Heh, I was wondering when someone would comment on that. There were a number of reasons I did it this way. But first, you're totally correct about using the XBee directly and that is what I leaned towards at first.
DeleteHowever I also wanted to PLAY with battery operation. There's so many posts out there about battery operation, but nothing I could trust except some folk that did really good work getting the current consumption down on an Arduino like device. I wanted something that I understood and could count on actually working.
Next, I wanted some smarts in the sensor. See, this is just a platform for more sophisticated sensors, ones with alarms that send a special message when it gets too hot or too cold. A freeze sensor would be really great in some locales. With a processor in there I can take the temperature curve of a food thermometer and have a barbecue sensor, I could have a barometer in there, It could sense voltage so we know the state of the battery we have in the quad out in the shed and send an alarm when it went nuts. That kind of thing.
Basically, the real answer is that I plan this thing to be much more than a temperature sensor over the long haul, I want a bunch of them out there telling me things about the house, environment, equipment, etc.
Heck, it could wake up every ten minutes, take a GPS fix, send it and I would never lose my keys again.
Thanks Dave, that totally makes sense. HG
ReplyDeleteHi, I see that you have capacitor on the circuit - wanted to know the value and any specific reason for the capactor - Thank you in advance! - HG
ReplyDeleteIt's a 10ufd and I have it there to make sure there's enough reserve power to run the XBee transmitter while the arduino's awake. Sometimes those little guys can pull enough power from a low current regulator to shut themselves down. I probably don't need it, but it was in the parts box and ...
ReplyDeleteHi Dave,
ReplyDeleteThere could be other ways of designing this type of sensors.I can think of two ways of going about this design. First one would be to use a sleepy microprocessor which would control/wake up an xbee or transmission device to send data to a gateway. The second method would be to have an xbee connected to relay to power ON or off a microprocessor. Assuming what you want to do with the microprocessor could be implemented eitherways, i wonder what would be a better design and why? Appreciate any inputs and Thank you! HG
What I've done here is exactly what your first suggestion is. I have a processor that sleeps 55 seconds out of 60, wakes up takes a reading and sends it through an XBee. The Xbee is also asleep because the processor causes it to sleep. So, everything is asleep except the temperature sensor itself, but it draws so little power it doesn't matter.
DeleteOh, the led is on as well, but I did that to drain the batteries faster for testing. The XBee could power on the processor, but I'd use one of those MOSFET digital switches so I wouldn't have to power the relay coil; they also don't wear out over time.
The problem I see with waking the processor is that I wouldn't have any intelligence to determine when to shut things off again. Currently I ask the XBee if it has a connection to the coordinator, and if not, I wait until it does to send. That way I can be almost totally certain the message got out.
I also thought about powering the whole thing off a timer that uses very little power, but gave up on that due to complexity.
Besides, this way I get to play with the sleep features of the chip.
Hi Dave,
DeleteI did some profiling with your code and at a high level.
Below is what is I got.
Get Temperature - 829 ms
Get Voltage - 3 ms
Xbee Ready - 2055 ms
Xbee Network Check - 22 ms
Xbee Send - 40 ms
So it was a full 2 seconds to startup the xbee and get it ready for transmission.
During this time the current consumption will be around 5 ~10 mA.
I was wondering if there is any way to reduce the the xbeeReady time.
Thank you for all your posts.
HG
There's certainly the possibility of leaving it on all the time, but that will eat more power. I haven't found a way of making it come up faster. It's true that if you sleep less time, the network doesn't forget about it, but then you are awake more often eating up power.
DeleteYou might set the off time lower and see how long it takes to rejoin, that could actually be a better way of doing it, but it didn't seem to save anything when I tried it.
What do you want to do, cut down on the awake time? If you transmit every 2 minutes instead of every minute, that lowers battery consumption a lot because you still have the 2 second connect time, but only half as many.
Thanks Dave - I think I will leaving it running for now, was just curious and want to share my findings. HG
ReplyDeleteI really appreciate your checking this out. This made me think about something I should check out. The time to rejoin is heavily affected by long it's been asleep. If you stay asleep longer than the network timeout, then the coordinator forgets about you and you have to reestablish the connection.
DeleteI thought I'd taken care of that, but I may have messed it up. Now, I have to check it out and see.
Just to let you know, I did try to reduce the transmission interval to 15seconds so that the coordinator does not drop the end device, that did not make any differance to the 2 seconds initialization process.
ReplyDeleteThank you - HG
I went the other way. I set mine to fire every 10 minutes, so the network would have forgotten about it, and sure enough, it took a little over six seconds to connect back up. That was a problem at first since I had it set to go back to sleep in five seconds.
DeleteI'm going to see if two seconds is normal, but it may be that it's already as short as it can get.
I will post this observation on Digi's website, will post back if there are new learnings.
ReplyDeleteI was thinking of trying to confine and co-ordinator and the end device to a single channel but that may not help much.
I posted the question there and got a silly answer with the suggestion that I contact customer support. That's the problem with these support forums, people answer with, "I don't know".
DeleteSilly.
I posted the question there and got a silly answer with the suggestion that I contact customer support. That's the problem with these support forums, people answer with, "I don't know".
DeleteSilly.
Hi Dave,
DeleteI did some more testing and research, few folks have already documented the 6 seconds delay.
One more testing that i did was to run the XBEE in PIN Hibernate mode SM=1.
I was not able to get this to work with SM=1, wanted know how have you configured the xbee connected to the pro-mini?
As always - greatly appreciate any inputs from you. Thank you!
HG
I used SM = 1, but you also have to raise the sleep pin to knock it out; if I remember correctly, it doesn't go to sleep until you raise the pin. So at init time, set the pin low, do whatever you need to first, then set it low just before you sleep the arduino. When the arduino wakes up, set the pin low and then wait for the CTS pin. If you send too soon, it goes nowhere.
DeleteThank you very much, I have this working with SM =1.
ReplyDeleteWith respect to my previous issue to performance, I changed my coordinator to have SP=AF0 and SN=15, now the entire reading is sent in under 1 second :-)
HG
Thank you Dave, this fixed my issue. On another note i changed SP = AF0 and SN=15 on the coordinator.
ReplyDeleteAfter the change the xbee is able to transmit temperature in less than 1 second all steps combined :-)
It will take longer as you get more devices. As the traffic increases, it take longer for the XBee to fit the message into the mesh, and it may have to retry. However, good job.
DeleteIn the interest of people reading this post.
ReplyDeleteDave's step up consumes 10 mA when awake and 19.3 micro Amps when sleeping per the eevblog micro current meter. Assuming the AAs give 2700 mHA and you send the reading ones every 5 mins @.92 seconds wake up, the battery should last about 5.25 years !!! Congrats Dave !!
HG
HG, thank you so much for measuring this. I tried to get one of the meters, but couldn't, so I just played it by ear. It looks like I'm really near the shelf life of the batteries that we buy from the big box stores and such. And, frankly, a year would make me ecstatic.
DeleteThanks again.
Hi Dave, for one of my projects I was trying to read the voltage from the voltage divider to an XBEE Series 2 ADC pin. D1 ADC Option 2.
ReplyDeleteWhen I connect the Temperature sensor to D1, I get the correct readings, in my case 0.71volts and Analog value 621. However when I connect the voltage divider to D1, multi-meter shows 0.69 volts because i have 9v or 6 AAs. The coordinator xbee does not get the right value, it always shows as 1023 the max value. Appreciate any guidance or suggestions.
Thank you! , HG.
That must be frustrating. The only time I see this is when I've messed up and forgotten to ground the voltage divider and it rises to source voltage. However, there are a couple of possibilities that spring to mind. Did you mix up the commands and turn the XBee pin into a digital input? Is there a capacitor in the circuit somewhere that is holding a charge?
DeleteIf you have a potentiometer handy, put one end on ground, the other at Vcc and the middle to the pin and experiment a bit. That could turn up something that you're overlooking.
Hi Dave, the circuit is the same as your diagram on this post. Essentially I copied the voltage divider circuit from your post above. So yes it does have a capacitor.
DeleteI will try to play around with a potentiometer today to check if that would make any differance.
Thank you, HG
Ok, you're using the multi megohm voltage divider. That does mean that you need a cap to lower the impedance of the pin. Double check the programming of the pin on the arduino. If you have accidentally programmed in the pull up resistor, it will max out the reading. You can't use the internal pullup resistor with megohm voltage dividers, it will overpower the circuit and give you a maxed out reading. It'll also cut the battery life some
DeleteThanks Dave, that could be the reason. The XBEE's do have the internal pull-up enabled by default. I will disable the pull-up on D1 and try. Should I also connect 1 micro farad cap between D1 and ground?
DeleteOK, I'm confused, are you using an arduino (or something like that) or strictly and XBee? It doesn't really matter though since the result would be the same, I just want to make sure I'm trying to answer the right question.
DeleteLike I said though, when you're using a very high value voltage divider, any stray resistor sneaking in can mess it up. However, mine is working really well keeping track of the source voltage.
Hi Dave, actually i have to two projects, one was the temperature sensor (pro mini and xbee) which i built similar to yours and which is running fine and now 24/7 and its day 10. Thanks to you !!
ReplyDeleteThe second one does not have any micro-controller and is intended to operate a water solenoid with XBEE and is battery operated. So i copied the voltage divider only and this is the one i "was" having issues with the ADC on D1 until you came to my rescue. I have now have disabled the internal pullup on D1 and the ADC is working fine :-). PR=3FF7 did the job per your recommendation. So ones again Thank you very much!
Glad I could help.
DeleteThanks Dave, I am new to electronics and learn a lot from your posts.
ReplyDeleteNow that I have this working, I am getting ready to connect my water solenoid to the XBEE.
For the water solenoid (I am using an N-Channel FET and a kickback diode).
The water solenoid and the voltage divider are both connected to a 12VDC supply.
I have protection on the XBEE pin driving the solenoid (FET and kickback diode), however the ADC pin D1 is directly connected to voltage divider, wanted to know if i should put kickback diode in the front of the divider? I am worried that my XBEE might get damaged if there reverse flow of current from the solenoid which needs 1.6amps to actuate, Appreciate any suggestion or recommendation.
Thank you - HG!
You're going to get a huge spike from the relay when you opereate it, so put the kickback diode right across the relay coils. Literally solder it right to the coil wires as close as you can get to the coils.
DeleteDon't run any wires along with the coil wires that can pick up the spike from inductive coupling. Make sure the diode is a power diode, not a signal diode, a signal diode will last about three times before opening up and letting the spike get through.
Do all that and you should be fine. I always put a small value cap and a large value cap side by side somewhere in the power circuitry to keep the various RF signals and periodic pulses that hang around the circuitry away from the processor, and so far, this has worked great for me.
Thanks Dave.
ReplyDelete