The OOK relay to pass on 433 and 868 MHz signals from other devices has been extended:
Spaghetti!
The following functions are now included:
- 433 MHz signals from KAKU transmitters
- 868 MHz signals from FS20 and WS300 devices
- the time signal from the DCF77 atomic clock
- pressure + temperature from a BMP085 sensor
Each of these functions is optional – if the hardware is not attached, it simply won’t be reported.
The BMP085 sensor in the top of the breadboard could have been plugged directly into port 3, but it’s mounted on a tiny board with the old JeeNode v2 pinout so I had to re-wire those pins.
Sample output:
There are still a few unused I/O lines, and additional I2C devices can be connected to port 3. Room to expand.
The source code for this setup is available here. It compiles to 10706 bytes, so there is plenty of room for adding more functionality.
This code includes logic for sending out the collected data to another JeeNode or JeeLink with acknowledgements, but I’m working on a refinement so it gracefully stops retransmitting if no receiver is sending back any acks.
As it is, this code will forever resend its data every 3 seconds until an ack is received, but this doesn’t scale well: all the “rooms” nodes do the same, so when the central receiver is unreachable every node will keep pumping out packets while trying to get an ack. It would be better for nodes to only re-send up to 8 times – and if no ack ever comes in, to disable retransmission so that only the initial sends remain.
I’m also still looking for a way to properly mount all this into an enclosure. There is some interference between the different radio’s, maybe all in one very long thin strip to maximize the distances between them?
Instead of resending data every 3 seconds forever or up to 8 times, you could wait an exponentially increasing amount of time between two sends. (eg. 2s, 4s, 8s, …) Old messages would have a chance to make it eventually but won’t saturate the network.
This is what NTP clients do (or should do…) to avoid overloading servers.
I like everything on this site a lot. Please keep making great stuff!
Yes, in general I think exponential back-off is a good idea. But here, I’m not sure it has quite the right behavior. Room nodes will send out a new reading every minute, or every few minutes, anyway. When they do, there is no longer a need to resend older values. I don’t want to change that, so this is just about whether to retry in between or not. With exponential back-off, each minute nodes would start resending again (quickly at first, then slower, etc) – what I’d like to do is to never retry, unless the previous packet got an ack.
All this will probably become less of an issue when listen-before-send is implemented, to avoid collisions. Somewhat similar to what the big guys would call CSMA. I don’t want to implement a full-blown “stack” for the RF12 when simpler solutions like these are sufficient.
Glad you like this weblog :) – please keep ideas and comments coming. The best way keep this going is by having information flow both ways. Ideas need a wall to bounce off, not a vacuum to fade in! And for more substantial discussion there is always http://talk.jeelabs.net/ …