NRF24 Bidirectional Communication

I have a project where two nrf24s need to communicate with each other bidirectionaly. After some searching about this topic I settled with using ackpayload. I don't like this solution as one of the radios becomes the main, and I can't have more than two radios. The requirement is to have as high a bitrate as possible (although I think 10 or so messages per second is more than enough for my application) while also being able to acknowledge messages (could use ackpayload for that). I am thinking about having the radios synchronized using a real time clock module on each unit, and I could sent data based on a timing interval.

ningaman151:
I don't like this solution as one of the radios becomes the main,

Not having to switch between transmitting and receiving is a big advantage,
so one sender and one receiver is somhow necessary.

ningaman151:
and I can't have more than two radios.

My main could communicate with six other nodes at the same time,
and with an unlimited number of nodes one after another.

Whandall:
Not having to switch between transmitting and receiving is a big advantage,
so one sender and one receiver is somhow necessary.

If I'm understanding correctly, uni directional communication is advantageous? Yeah I'm under that assumption, since there would be no protocol such as time division multiplexing. Also, you mean as in the case of ackpayload? Since in that case there would only be one transmitter and the rest are receivers?

My main could communicate with six other nodes at the same time,
and with an unlimited number of nodes one after another.

So do you have one node as the transmitter, and the rest are listening? And I assume you are using ackpayload? Did you implement an ad-hoc network? That's something I'm looking into implementing for this project too. I've looked at tmrh20's RF24 network library, but it states the nodes are structured in a tree hierarchy, with a root node. I want the nodes to be interconnected (any node can send to any other node). I can understand the limitation of the nrf24 though.

ningaman151:
If I'm understanding correctly, uni directional communication is advantageous?

There is a significant delay involved in switching between tx and rx.

A rx node can support at most three connections with ackpayload data,
Switching between tx and rx clears the tx buffer which would have to be reloaded on each switch.

ningaman151:
So do you have one node as the transmitter, and the rest are listening? And I assume you are using ackpayload? Did you implement an ad-hoc network? That's something I'm looking into implementing for this project too. I've looked at tmrh20's RF24 network library, but it states the nodes are structured in a tree hierarchy, with a root node. I want the nodes to be interconnected (any node can send to any other node). I can understand the limitation of the nrf24 though.

There is no ackpayload support in network or mesh topologies IIRC.
Many problems start with "I want". :wink:
Do you really need communication outside the point to point distance?
If so, you will have to drop bidirectional communication via ackpayload.

Whandall:
There is a significant delay involved in switching between tx and rx.

One would assume. As long as the message frequency is around 10 messages a second (I even think that might be more than necessary).

A rx node can support at most three connections with ackpayload data,

Not useful in my application as all nodes must transmit and receive to and from each other. I think the nrf24 might not be the module for this application.

Switching between tx and rx clears the tx buffer which would have to be reloaded on each switch.
There is no ackpayload support in network or mesh topologies IIRC.
Many problems start with "I want". :wink:
Do you really need communication outside the point to point distance?
If so, you will have to drop bidirectional communication via ackpayload.

The problem is I need each radio to be independent. I cannot place them in a tree hierarchy because the radios are moving (the application is communication between bicycle computers, where the relative position of the cyclists changes. What if the root node is the furthest behind?). I am new to this networking lingo, I assume mesh/network is analogous to ad hoc?

I don't like the ackpayload as it is a botch. It works but not as intended. It's fine for 2 radios

ningaman151:
One would assume. As long as the message frequency is around 10 messages a second (I even think that might be more than necessary).

Did you look up the switching times? If not, you should.
Same for the capabilities/restrictions of the Mesh and Network libraries.

ningaman151:
I don't like the ackpayload as it is a botch. It works but not as intended.

I strongly disagree. Maybe your intentions are different to the intentions of Nordic?

You should describe what you want to achieve,
the data flow (what, from, to, when, how often, ...) and
the spatial distribution of your nodes and their change over time.

I see no off the shelf need for a bidirectional data stream between two bicycles.

ningaman151:
I don't like the ackpayload as it is a botch. It works but not as intended. It's fine for 2 radios

That is nonsense.

You could use ackPayload with 100 other nRF24s. How many do YOU need?

...R
Simple nRF24L01+ Tutorial

Whandall:
You should describe what you want to achieve,
the data flow (what, from, to, when, how often, ...) and
the spatial distribution of your nodes and their change over time.

I see no off the shelf need for a bidirectional data stream between two bicycles.

I want to have bicycle computers that communicate with each other. As of now I have two, but ideally I would want the implementation to support at least a small group (say 4 or 5). The messages would be broadcast to all users, and if a user is out of range an ad-hoc method of relaying the message would be used. There is no master user. All users are identical (addresses are the only difference). The users should be able to send messages with acknowledgement (a notification appears for the sender confirming that the message was received by the other user). The messages are sent when a certain flag is triggered (such as a button press), but messages are also sent to ping the connection to notify the user if the radio disconnected. Based on this, the user would be sending messages every second at most, and the ping messages could be sent a couple of times a second (would have to test what is a good amount, but I assume around 2-10 pings a second would suffice).

As implied, the users are moving, as they are cycling. They would be usually within a few meters of each other, but would start to spread out if a user falls behind (upwards of 100 meters, or if the range is too long to receive).

Robin2:
That is nonsense.

You could use ackPayload with 100 other nRF24s. How many do YOU need?

...R
Simple nRF24L01+ Tutorial

Around 5 nrf24s. All should be able to transmit and receive to each other directly and indirectly (ad hoc).

ningaman151:
The messages would be broadcast to all users, and if a user is out of range an ad-hoc method of relaying the message would be used. There is no master user. All users are identical (addresses are the only difference). The users should be able to send messages with acknowledgement (a notification appears for the sender confirming that the message was received by the other user).

If these are the same messages, you are out of luck.
Broadcasting and acknowledgements are mutually exclusive.

Operating "radios" while bicycling is probably illegal in many countries.

To be honest, I can not see any real use in such messages between bicycles.

ningaman151:
The messages would be broadcast to all users, and if a user is out of range an ad-hoc method of relaying the message would be used. There is no master user. All users are identical (addresses are the only difference). The users should be able to send messages with acknowledgement (a notification appears for the sender confirming that the message was received by the other user).

I get the impression you are trying to achieve something that the nRF24 is not capable of, or at least not in the way you are currently thinking.

I have no experience of the RF24 Mesh system but it may be what you need. However as you add the Network features and then the Mesh features the throughput declines very significantly.

Or maybe you could set up some sort of WiFi system with a bunch of ESP8266 modules - you don't need an Arduino with them.

Robin2:
Or maybe you could set up some sort of WiFi system with a bunch of ESP8266 modules - you don't need an Arduino with them.

I've ordered some ESP32 boards not too long ago, still waiting for them to arrive (bought off aliexpress). Do you mean use wifi direct? As having an access point wouldn't be sufficient as there is no main/root node.