NRF24L01+ multicast receiver requirements

Hi, just want to ask is it necessary to disableACK at receiver end in multicast mode while using nrf24l01+....or the ACK issue is simply handled by transmitter node?...

Please clarify which library you are using.
AFAIK, ACK can be disabled- it is just a packet sent back to the TX node to make sure the first went through and prevent retries. The TX just needs to not expect an ACK in return.

If you want several slaves to receive a message from a master you should disable the auto acknowledgement process on all the devices. If you don't the slaves will all send their ACKs at the same time causing garbage which will leave the master thinking that the message was not received. And if the auto ACK is disabled on the slaves it must also be disabled on the master so that it knows not to expect an ACK.

If you disable auto ACK it may be useful to include a serial number in every message so that each slave can separately determine if it has missed any message.

You might consider it worthwhile to leave auto ACK enabled on the master and a single slave. Then you would at least know that the master and that single slave are both working properly. However you would need to disable auto-retries so that extra repeats from the master would not confuse the other slaves. And without auto-retry it is not obvious what advantage there is to use auto ACK.

Or you might consider giving each slave a different address and arranging for the master to send the same message to each, one after the other. That would be the most reliable system.

...R
Simple nRF24L01+ Tutorial

Robin2:
If you want several slaves to receive a message from a master you should disable the auto acknowledgement process on all the devices.

I strongly disagree.

Only disable the acks for multicast pipes on all the receiving sides

void setAutoAck (uint8_t pipe, bool enable)

and send without ack from the senders

bool write (const void *buf, uint8_t len, const bool multicast)

There is no reason that the senders could not also listen to multicasts,
but obviously they won't see their own packets.

I'm using RF24 Library, would the multicast mode still works if I just disable ACK at transmitter end?

Does it work if you use only one leg while walking? Kind of.

I told you how to do it properly, why not follow that route?

Whandall:
I strongly disagree.

Have I misunderstood what the OP is trying to do?

I thought he wants several slaves to receive the same message from the master?

...R

He wants to use multicast.

There are no masters or slaves in that context, just senders and receivers (and nodes can be both).

There is no reason to disable all acks in all these nodes, only the multicast pipes and sends need that.

Whandall:
He wants to use multicast.

I misunderstood, then.

...R

Robin2:
I thought he wants several slaves to receive the same message from the master?

That is multicast, isn't it?

Whandall:
That is multicast, isn't it?

I was thinking of a message being sent in the simplest way (as in the first example in my tutorial) and several slaves listening on the same address, I presume (now) that when you say "multicast" you are talking about some extra feature of the nRF24 that I have not used.

...R

Multicast

In computer networking, multicast is group communication[1] where data transmission is addressed to a group of destination computers simultaneously. Multicast can be one-to-many or many-to-many distribution.[2] Multicast should not be confused with physical layer point-to-multipoint communication.

On a NRF24l01+ system one can use its point-to-multipoint communication to achieve multicast behaviour.

Basically your proposal to disable acks in all node works, but is kind of overkill.

You only have to adjust the acks in the involved pipes and sends, not globally.

So you can have both, acked point to point and non-acked multicast style communication.

[OT]
I use pipes with disabled acks to eavesdrop communication between other modules,
without interfering to the communication.
[/OT]

Whandall:
Basically your proposal to disable acks in all node works, but is kind of overkill.

I think I understand now. I thought you had been trying to say that what I suggested would not work.

And perhaps it would only be necessary to disable the auto ACK feature in the master. If it was not expecting an ACK it would probably not matter if the slaves sent their ACKs

...R

You could be are right and the no-ack-bit (which is part of the packet header) supresses the ack on
the receiving pipes - even if configured for acks - automatically.

7.3.3.3 No Acknowledgment flag(NO_ACK)
The Selective Auto Acknowledgement feature controls the NO_ACK flag.
This flag is only used when the auto acknowledgement feature is used. Setting the flag high, tells the
receiver that the packet is not to be auto acknowledged.

I can not remember whether I have checked that.

I can see the value of suppressing auto ACK for eaves-dropping but for general use it seems to leave the system very vulnerable to un-intentional cock-ups when neither side knows whether the other side has been talking or hearing.

By the way the concept of eaves-dropping is the first time I have seen any value in multiple pipes - they would allow you to eaves-drop on transmissions in both directions.

...R

I would use no-ack sends and no-ack pipes in combination (even if not necessary in the pipes)
to make it clear that there will be no acks on this pipe.

If eavesdropping is problematic, one should encrypt the traffic and/or use a frequency hopping scheme.

And the encryption should be better than in MS wireless keyboards. :wink:
KeySweeper - covert Microsoft wireless keyboard sniffer using Arduino and nRF24L01+

Whandall:
If eavesdropping is problematic,

I was just thinking of it for debugging purposes.

And I think we have strayed far enough from the OP's question :slight_smile:

...R