Project

General

Profile

Over 30 nodes

Added by ichilton about 5 years ago

Hi,

The RF12 driver documentation states that only node ID’s 1-30 can be used, and 31 is reserved.

I’m now at the stage where i’ve used all 30 id’s - is my only way to add more nodes to add another base station node which listens on a different group id, or are there other options?

Thanks,

Ian


Replies (9)

RE: Over 30 nodes - Added by lightbulb about 5 years ago

ichilton,

You ‘could’ use sub-addressing, within specific node id’s by sacrificing a byte in the payload.
Its actually quite easy if you are happy to process the resulting RF12 packet data in a scripting tool, like python/node.js (go!).

You could even deal with basic ‘ack’ functionality so long as you dont need specific ‘ack’ payloads to sub-nodes, else you’ll have to handle the ack yourself, using the sub-address in reverse.

Also take a look at the relaynode script.

—lightbulb

RE: Over 30 nodes - Added by JohnO about 5 years ago

I wonder how many issues we would need to resolve in order to have RF12Demo support a list of group-id’s.
# It would need to operate similarly to having group-id 0.
# It would need to require a group-id when sending data.
# Acknowledgement requests would be directed to the initiators group-id.
# It would need to retain a list of acceptable group-id’s.

RE: Over 30 nodes - Added by JohnO about 5 years ago

ichilton

Having your central node configured with group 0 as expected allow receipt of packets from multiple groups, the printed format is slightly different. That is your existing 29 nodes can still be seen by the Jeelink. If you now add a 31st node with node number 1 and a group different that that used on your existing 29 nodes you will see its its transmissions on your Jeelink. The ack’s for the 31st node won’t be working if you are using them.

Correction, the ACK’s do appear to go back to the correct group. Use of “1q” is recommended.

Further correction - ACK’s don’t get decoded by the ACK requester - the sync header isn’t correct.

RE: Over 30 nodes - Added by JohnO about 5 years ago

The main challenge with ACK’s from a Group=0 node appears connected with this code snip from rf12.cpp

    if (group != 0) {
        rf12_xfer(0xCA83); // FIFO8,2-SYNC,!ff,DR 
        rf12_xfer(0xCE00 | group); // SYNC=2DXX; 
    } else {
        rf12_xfer(0xCA8B); // FIFO8,1-SYNC,!ff,DR 
        rf12_xfer(0xCE2D); // SYNC=2D; 

One would need to transmit an ACK with FIFO8,2-SYNC,ff,DR as a header. Or flip it each time an ACK is required.

I don’t know what “DR” means yet but if it equates to value required in the transmission stream then we can’t fake an ACK sync header..

RE: Over 30 nodes - Added by JohnO about 5 years ago

This post from @jcw’s blog appears relevant to this topic: Group 0 giving less reliable sync triggering for instance.

Perhaps we could ack the various groups using this technique.

RE: Over 30 nodes - Added by JohnO almost 5 years ago

Hello ichilton, its been a while but your post has been in my mind for a while now. Since you have a large JeeNode network I would be interested in your view on a code branch that is now reasonably stable. Although some functionality is available with an RFM12B equipped JeeNode, for truly acceptable results a node equipped with the later RFM69CW or RFM69W is required. The code is in the RF12Demo branch on git https://github.com/jcw/jeelib/tree/RF12Demo and currently provides support for up to 100 nodes when it is configured as group 0 There is capability for more nodes but RAM would be the ultimate limiting factor. The other nodes in the network may use any group numbers 0-255.

I don’t recommend use of an RFM12B configured as group 0 because noise triggers packet capture very easily and the interrupt rate get quite high. The RFM69 models on the other hand use a longer sync matching pattern and the interrupt rate is kept much lower.

Anyhow, if you have the equipment and the time I would welcome your feedback.

RE: Over 30 nodes - Added by ichilton almost 5 years ago

Hi,

This is interesting - thanks for following up.

So to confirm, only group 0 has up to 100 nodes - other groups still have a maximum of 31?

And group 0 should only really be used on RFM69, not RFM12B?

My current nodes are all RFM12B - and a mix of hardware - some ATMega328 based, some ATTiny etc…

I am however in the middle of building a big batch of boards based on the Moteino PCB and have got a batch of RFM69CW to try.

What i’m working towards is a big side-by-test of battery life between different nodes - RFM12B radio vs RFM69 radio, MCP1700 vs MCP1702 vs no regulator, different batteries, the jeelib vs the lowpowerlab one etc, but I might have opportunity to play with that then - it’s just taking a while to get the hardware built and ready, as i’ve not got much spare time and have a few projects on the go.

I’ve not had chance to try it yet, but the lowpowerlab.com RFM12B library seems to be saying: “127 possible nodes on 256 possible networks” (https://github.com/LowPowerLab/RFM12B) - so it must be possible on RFM12B?
(their RFM69 one says: “255 possible nodes on 256 possible networks”)

Thanks,

Ian

RE: Over 30 nodes - Added by JohnO almost 5 years ago

ichilton wrote:
> So to confirm, only group 0 has up to 100 nodes - other groups still have a maximum of 31?
To retain backwards compatibility the addressing protocol is unchanged. The RFM69 hardware facilitates a reliable use of group 0. When configured as group 0 all groups can now be reliably received.
>
> And group 0 should only really be used on RFM69, not RFM12B?
It can be used and depending on the noise of your environment it will still work. The new code counts the CRC failures to give an idea of the interrupt rate. With RFM12B I am seeing around 10 _wasted_interrupts per second.
>
> My current nodes are all RFM12B - and a mix of hardware - some ATMega328 based, some ATTiny etc…
The code can run in skinny mode on the Tiny with the RFM12B but I haven’t tested on Tiny with the RFM69 family.

> I am however in the middle of building a big batch of boards based on the Moteino PCB and have got a batch of RFM69CW to try.
I have a couple on Monteio’s one equipped with RFM69W and the second currently not equipped with a radio. I you pick up a batch of RFM69H variants I will happily buy a couple from you.

> What i’m working towards is a big side-by-test of battery life between different nodes - RFM12B radio vs RFM69 radio, MCP1700 vs MCP1702 vs no regulator, different batteries, the jeelib vs the lowpowerlab one etc, but I might have opportunity to play with that then - it’s just taking a while to get the hardware built and ready, as i’ve not got much spare time and have a few projects on the go.
I wonder if a reduced interrupt rate when in receive will be measurable in battery longevity.

> I’ve not had chance to try it yet, but the lowpowerlab.com RFM12B library seems to be saying: “127 possible nodes on 256 possible networks” (https://github.com/LowPowerLab/RFM12B) - so it must be possible on RFM12B?
> (their RFM69 one says: “255 possible nodes on 256 possible networks”)
They made different design decisions when putting together their protocol. I haven’t run the lowpowerlabs.com protocol myself so I don’t understand the internals.

Just one constant to change to get the node count above 100 on a ATMEGA328, ram limited or code limited at 254 as it stands. Please let me know how you get on.

RE: Over 30 nodes - Added by ichilton almost 5 years ago

Thanks.

I got my RFM69’s from here: http://anarduino.com - great service and good prices.

I got 2x RFM69HW-868 to try/compare, and a some RFM69CW-868’s.

Ian

    (1-9/9)