7
\$\begingroup\$

I backed the RFduino project on Kickstarter to use it in my next project. It is basically a tiny Arduino compatible board with built in Bluetooth LE that supports additional shields.

I've also got a regular Arduino Uno with an Ethernet Shield.

What I'd like to build

I'm thinking about a sensor network (humidity and temperature) for indoors using multiple RFduinos with the coin battery shield lying around the house. The Arduino Uno with the ethernet shield and a bluetooth shield connected to a router would send the data to my server, so I can monitor the stats remotely.

Question

I'd like to transmit data every 10 mins to keep energy consumption low. How can I wake up the sensors and my mainstation (the uno) at the same time, transmit data (from sensors to mainstation and from mainstation to my server) and put them back to sleep again? Is there any risk at losing data because one of the sensors might be awake when the mainstation is still sleeping? Can the Uno Bluetooth shield interfere with the Ethernet shield?

I'm not asking for code but does the idea make sense? Links to related projects would help a lot. I also thought about using xbee for data communication but i found it quite complicated and now that Bluetooth LE needs less energy I can't see any advantages of xbee over Bluetooth LE.

\$\endgroup\$
2
\$\begingroup\$

It sort of makes sense.

There isn't much of a problem keeping the Uno on 24/7 (it doesn't consume much energy). Instead of connecting it to a battery, get a good wall wart for it. This way, you don't have to worry much about synchronizing the RFduinos as well. Just have it wait patiently for an RFduino to connect to it. However, if you do want to keep them in sync, then just use the Time library, somehow turn them all on at the same time (easy if you use the reset pin), and pray that their power source is uninterrupted.

About the RFduinos: you probably can keep them on as well, on a loop that breaks every 10 minutes to turn on bluetooth and send data. Even better, use a library like this one which gives you a power efficient sleep mode to work with.

If you don't want to keep the RFduinos on, though, a simple circuit using a 555 timer and a relay ought to suffice to turn it on every few minutes (it can turn itself off via the RESET pin of the 555). As long as the Uno is on 24/7, you need not use any special sync and can have the RFduinos sending values at staggered intervals.

Here's a schematic:

enter image description here

Connect the part that says "To Pin" to some pin on the RFduino. Send a constant HIGH output on it. When you want to shut down, send a LOW signal.

The "To Vin" and "To GND" parts go to the respective pins on the RFduino.

If you can't find a 866K resistor, something of a nearby value ought to work. Basically, ln(2)*R2*C2 should be 600 seconds.

Note that 555s have different RESET behaviors. We want the one which goes on it's LOW cycle when reset.

\$\endgroup\$
  • \$\begingroup\$ Do I really need extra hardware? I found this interesting article yesterday How to run an Arduino on a 9V battery for weeks or months. Have you ever worked with a software only solution? \$\endgroup\$ – zeMirco Apr 11 '13 at 12:26
  • \$\begingroup\$ @zeMirco: I already mentioned the software solution: Keep them on, in a loop that breaks out every 10 minutes to turn on Bluetooth (I'll edit in a bit about that library if you wish). I gave you the hardware solution because you mentioned that you wanted them to be off in the question. \$\endgroup\$ – Manishearth Apr 11 '13 at 12:33
  • \$\begingroup\$ Yeah, you mentioned a software solution in general but didn't provide any details. If you've got some more insights that would be wonderful. For example: How can I make sure that the timers on my mainstation and the RFduinos are synched? \$\endgroup\$ – zeMirco Apr 11 '13 at 12:55
  • \$\begingroup\$ @zeMirco: Added a bit in an edit. IMO, keeping the Uno on means that you don't need to worry about sync. However, the Time library will let you keep them in sync. However, I don't have experience with that and I'm not sure how accurate that library is. \$\endgroup\$ – Manishearth Apr 11 '13 at 13:05
  • \$\begingroup\$ The time library is a bit less accurate than the accuracy of the clock source: In the case of the Arduino, which does not used a Temperature Compensated Crystal Oscillator (TCXO), this isn't very accurate at all. Also, bit less accurate because some interrupts will be missed in practice, adding inaccuracy. \$\endgroup\$ – Anindo Ghosh Nov 2 '13 at 4:39
1
\$\begingroup\$

As an alternative, you could develop your program to listen for connection requests and collect and send data from the sensors as the return value. This would avoid the need for the timer circuit or loop, although it would necessitate leaving both the Uno and RFduinos on constantly. Given the power consumption, the ability to change the sampling rate easily might be an excellent gain for you. You would simply change how often your computer polled the Uno, nothing on the Uno or sensors would change.

\$\endgroup\$
  • \$\begingroup\$ An interesting approach but as you said it means I have to leave both on constantly which reduces battery time extremly. \$\endgroup\$ – zeMirco Apr 11 '13 at 12:38
  • \$\begingroup\$ True, but as Manishearth mentioned, you could just as easily get a good wall-wart for power. Especially if you want to put the sensors in "hidden" or not-normally-accessed places. \$\endgroup\$ – John Apr 11 '13 at 12:53
0
\$\begingroup\$

A few observations.
1) will your uno be placed so that it can reach all the sensors via bluetooth?

2) why not just add bluetooth to your central server and avoid the time synch wakeup altogether, since the central server will be on all the time.

3) dead reckoning using the timer will eventually drift. You will want them to have your peer to peer network sync on each wakeup cycle and coordinate on the next sleep.

The arduino sleep details are here, (but I am not sure if the RFDUino will work the same way):

http://playground.arduino.cc/Learning/arduinoSleepCode

you would probably be looking at waking up with a watchdog timer, since there are no specific events other than time triggering your readings.

Good overview of that here: http://donalmorrissey.blogspot.com/2010/04/sleeping-arduino-part-5-wake-up-via.html

I think you can eliminate the uno from your architecture, and conserve battery life using hardware shutdown. Make sure your central server has bluetooth and can see at least one of the units. I would peer to peer the solution so that all the sensors aggregate each others information. That way as long as all the RFDuino's can see at least one other RFDuino, they can pass their information forward.

In that design, an RFDuino would wake up, and post its reading to any and every neighbor that it sees, then read any and every neighbor for the values that the neighbor has collected until all the expected readings are present (you would need to preconfigure the network so that you know how many peers to expect). Once each sensor has collected all the information from all the others, you could send a sync signal and shutdown. That avoids sensors shutting down if they do not have all the readings from everyone else, and the sync will ensure that hopefully the sensors do not all stay on too long. So if a sensor wakes up early, it will wait till all the others have sent their data to the network before shutting down. If it wakes up late, the other sensors will all be waiting for it. The sync signal should ensure that the next sleep cycle starts relatively close for everyone, and the system is somewhat self correcting.

In this design, If one of your sensors disappears due to battery life/failure, all the other sensors will stay awake waiting for it. So you would need some emergency code that kicks in after a sensor has stayed on waiting on a peer on missing sensor data for longer than two normal intervals. Then remove that peer from the wait list and continue operation.

Sounds like a fun project, let us know how it turns out.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy