Many nRF24l01 talking to one base - project experineces

Projects General Guidance
1

Hello,
I would like to implement a big network of nRF24l01 talking to one base and I'm interrested in your experiences, feasibility of such project and possible critical limitations to take care of from the beginning.

The use case is to monitor general mood of up to 100 people audinece of a lecture/concert/whatever. I'd like to distribute 100 cheap modules with nRF24l01, some microcontroller (arduino pro mini or bare ATmegaxxxx) and a simple switch labeled "Agree - Disagree". Whenever any participant swithes eitherway, her module sends message to the base. The base tracks realtime mood statistics.

I have chosen the nRF24l01 for the price, the relative big community and because I don't know anything with better price/feature ratio :blush:

I've done some research on this forum and elswhere:

Anyway even with the sources above, there is vary little information about successfull projects getting even close to 100 nodes talking to one base. What are the limitations and problems I will probably face?

My idea is to have one nRF24l01 at each node and one nRF24l01 at the base. This means that the nRF24l01 native mechanism of pipes being unique between one transmitter and one receiver cannot be used (6 pipes maximum for the receiver, having 100/6=17 nRF24l01s at the base is ugly and would probably cause problems if put on one SPI together). Instead I plan a layout with one pipe address shared by all nodes to send information to the base. And 100 unique pipe addresses for each node to get "application level" ack from the base (instead of using the nRF24l01 auto ack features).

Overall the bandwith is not such an issue - each node only needs to transmit its id (to calculate the ack pipe address) and 1 bit of "mood information". But there will be collisions which have to be handled by the application level ack and retransmission. I imagine this as the base sending an ack message to the node on unique pipe address calculated form the node's id. If the node does not receive an ack within a few millis, it will try to retransmit the original message after small random delay.

Has anybody tried many nRF24l01s on one pipe? Can 100 nodes share one pipe address if I expect single units of change broadcasts per second, but sometimes massive peaks of tens of broadcasts in the same second, which would lead to many collissions and lost acks?

I am aware this is very open ended set of questions. I'm not seeking a definite answers, but I would appreciate any brainstorming level feedback.

I have no electronics education and I'm quite new to arduino. I'm aware that this is a big project and I should go slowly step by step. So far I have managed to have a bit faulty proof-of-concept with 2 nodes (Arduino Uno R3 and Arduino Nano) talking to one base (Raspberry Pi). Now I'm tweaking the ack-retransmit logic. But I'm always wondeing if a haven't missed something big, if I'm not gonig in a completly wrong direction or reinventing the wheel.

Any feedback will be appreciated. Thanks.

2

Each server can only listen to six addresses at a time. It seemed to me that it only successfully received transmissions on one pipe at a time (i.e. concurrent incoming transmissions on different pipes trampled over each other) although that could just have been an indication that I was running out of range and there was too much cross-talk between frequencies.

I've had multiple senders talking to the same receiving address and multiple receivers receiving at the same address. Although this works in the sense that the transmission can succeed, it messes up the message/response protocol and could mean that failures are undetected.

To support that many nodes you really do need either a tree/mesh network so that each node has a much smaller number of peers, or implement a robust collision detection mechanism.

3

I've had multiple senders talking to the same receiving address and multiple receivers receiving at the same address. Although this works in the sense that the transmission can succeed, it messes up the message/response protocol and could mean that failures are undetected.

Yes, this messes up the auto ack features (I also found out the hard way :slight_smile: ). I have turned those off ( with the RF24 library I'm using and the setAutoAck method) and I'm not relying on them for collision detection.

To support that many nodes you really do need either a tree/mesh network so that each node has a much smaller number of peers, or implement a robust collision detection mechanism.

I'm not sure the tree/mesh would help without frequency/channel hopping. The tree network in a big house works fine, when the nodes are not in the range with all other nodes. But when they are all in one room, they will interfere anyway. Not in the sense, that more nodes would get confused with several messages, but simultaneous transmissions would anyway make too much noise on the channel, I fear. Putting more intermediate branch or relay nodes in the same physical space would IMHO just add more interference.

I'm trying to go with the "robust collision detection" alternative. But simple ack from base to node can hardly be called robust :blush:

Thank you for sharing.
How many nodes did manage to get talking to each other in the end, before swithing to different layouts?

4

I didn't scale it up very far, and most of my experiences came from experiments while I was just trying to figure out how it behaved. The end goal was a self-organising mesh of about a dozen nodes that let a controller communicate with a pool of slaves where some of them were too far away for direct communication. I suspect this is similar to the library that ManiacBug wrote on top of his basic RF24 lib.

While you thinking about scalability it might help to bear in mind that each receiver can only listen to six addresses at a given time but the total number of addresses available is very large. (My approach was to have each node find a preferred 'parent' node based on the number of hops to a root node, and have that parent allocate an address for it. The allocation was done using the ack payloads for the discovery 'pings'. The hardest part was to make the mesh cope with changing connectivity and at the same time stopping it from repairing itself too aggressively, because that made it hard to stabilise the routing.

5

Thank you. That's an approach I was not aware of - to reuse available reading pipes form other nodes than the base. I'm still not sure it is a good idea whan all nodes also see the base, but worth exploring.

6

Any updates on this project?

7

This is a very old Thread. Have a look at this Simple nRF24L01+ Tutorial
.

Then if you have any questions start a new Thread of your own.

...R