The RF12 driver has a 5-bit slot in its header byte to identify either the sender or the destination of a packet. That translates to 32 distinct values, of which node ID “0” and “31” are special (for OOK and catch-all use, respectively).
So within a netgroup (of which there can be over 250), you get at most 30 different nodes to use. Multiple netgroups are available to extend this, of course, but then you need to set up one central node “listener” for each netgroup, as you can’t listen to multiple netgroups with a single radio.
I’m using JeeNodes all over the place here at JeeLabs, and several of them have been in use for several years now, running on their own node ID. In fact, many have never been reflashed / updated since the day they were put into operation. So node ID’s are starting to become a bit scarce here…
For testing purposes, I use a different netgroup, which nicely keeps the packets out of the central HouseMon setup used for, eh… production. Very convenient.
But with the new JeeNode Micro, I actually would like to get lots more nodes going permanently. Especially if the coin cell version can be made to run for a long time, then it would be great to use them as door sensors, lots more room nodes, and also stuff outside the house, such as the mailbox, humidity sensors, and who knows what else…
Now the nice thing about send-only nodes such as door sensors, is that it is actually possible to re-use the same node ID. All we need is a “secondary ID” inside the packet.
I’ve started doing this with the radioBlip2 nodes I’m using to run my battery lifetime tests:
(BATT-0 is this unit, BATT-1 is a JNµ w/ coin cell, BATT-2 is a JNµ w/ booster on 1x AA)
This is very easy to do: add the extra unique secondary ID in the payload and have the decoder pick up that byte as a way to name the node as “BATT-<N>”. In this case, it’s even compatible with the original radioBlip node which does not have the ID + battery levels.
Here is the payload structure from radioBlip2, with secondary ID and two battery levels:
struct {
long ping; // 32-bit counter
byte id :7; // identity, should be different for each node
byte boost :1; // whether compiled for boost chip or not
byte vcc1; // VCC before transmit, 1.0V = 0 .. 6.0V = 250
byte vcc2; // battery voltage (BOOST=1), or VCC after transmit (BOOST=0)
} payload;
And here’s the relevant code snippet from the radioBlip.coffee decoder in HouseMon:
decode: (raw, cb) ->
count = raw.readUInt32LE(1)
result =
tag: 'BATT-0'
ping: count
age: count / (86400 / 64) | 0
if raw.length >= 8
result.tag = "BATT-#{raw[5]&0x7F}"
result.vpre = 50 + raw[6]
if raw[5] & 0x80
# if high bit of id is set, this is a boost node reporting its battery
# this is ratiometric (proportional) w.r.t. the "vpre" just measured
result.vbatt = result.vpre * raw[7] / 255 | 0
else
# in the non-boost case, the second value is vcc after last transmit
# this is always set, except in the first transmission after power-up
result.vpost = 50 + raw[7] if raw[7]
cb result
In case you’re wondering: the battery voltage is encoded as 20 mV steps above 1.0V, allowing a single byte to represent values from 1.0 to 6.1V (drat, it’ll wrap when the boost version drops under 1.0V, oh well…).
Note that this trick works fine for send-only nodes, but it would need some additional logic in nodes which expect an ACK, since the ACK will be addressed to all nodes with the same ID. In many cases, that won’t matter, since presumably all the other nodes will be sound asleep, but for precise single-node ACKs, the reply will also need to include the extra secondary ID, and all the nodes will then have to check and compare it.
So now it’s possible to re-use a node ID for an entire “family” of nodes:
- over 250 different netgroups are available for use
- each netgroup can have a maximum of 30 different node ID’s
- each node ID can be shared with over 250 send-only nodes
That’s over 1.8 million nodes supported by the RF12 driver. More than enough, I’d say :)
This is a JeePlug filled to the rim with tiny components and connectors. It’s based on a PCA8574A I2C 8-bit I/O expander. Each of 8 pins can be used either as inputs or as “mostly” open collector outputs. See the datasheet for details.
