Go Down

Topic: nrf24 autoack slaves with same address (Read 3668 times) previous topic - next topic

notsolowki

Is it okay to have AutoAck enabled when sending to 2 devices with the same address? I've read that i'm suppose to disable AutoAck. Basically i have 2 slaves with the same address. each device has its own set of "commands" to compare the incoming message to. It seems like it works better with AutoAck enabled. the problem is, if they both have the same address when i send a message to them 1 of the devices with the same address gets the message every time i dont have to send it more than once. BUT the second device "its always the seconds device" i have to send the message a few times in a row for it to receive it successfully. Hopefully i explained this enough to understand what i'm doing. Heres the catch, if i shut of the power to device 1 device 2 will always receive the message properly?

notsolowki

It COULD be my wiring but the only solution I found so far is to have the same message sent a few times in a row. I dont care which devices send the ack back as long as the message shows up a both devices. The only thing i really use the ack for is to confirm that the radio is powered on. I can handle duplicate messages showing up on the receiving end.

Whandall

Is it okay to have AutoAck enabled when sending to 2 devices with the same address?
No.
Ah, this is obviously some strange usage of the word 'safe' that I wasn't previously aware of. (D.Adams)

notsolowki

No.
Can you tell me why and why not please? In a short way if you'd like thanks.

Whandall

No, I will not read the data sheet to you.
Ah, this is obviously some strange usage of the word 'safe' that I wasn't previously aware of. (D.Adams)

notsolowki

No, I will not read the data sheet to you.
your such a nice guy. I guess if you were not busy being a nice guy you'd know the datasheet dont specify why.

Whandall

It does. It specifies the acknowledge communication as a communication between two stations.

Quote
An Enhanced ShockBurst™ packet transaction is a packet exchange
between two transceivers, with one transceiver acting as the Primary Receiver (PRX) and the other transceiver
acting as the Primary Transmitter (PTX). An Enhanced ShockBurst™ packet transaction is always
initiated by a packet transmission from the PTX, the transaction is complete when the PTX has received an
acknowledgment packet (ACK packet) from the PRX.
And it's obvious that the technique can not work with more than one PRX.
Ah, this is obviously some strange usage of the word 'safe' that I wasn't previously aware of. (D.Adams)

notsolowki

#7
Jul 22, 2019, 04:09 pm Last Edit: Jul 22, 2019, 04:13 pm by notsolowki
It does. It specifies the acknowledge communication as a communication between two stations.

And it's obvious that the technique can not work with more than one PRX.
I not sure that applies to me. Forgive me if i'm wrong but i thought that Enhanced ShockBurst is an optional feature not all cards have that's disabled by default. In a messy way its okay "for my use?" if only 1 ACK is received and it don't matter to me which one of the devices sent the ACK. All that matters to me is the both receive the same message at about the same time. For my use the only thing i use the ACK for is to confirm that at least one of the radios out of the 10 that have the same address received it, although its not the best way to do that it works for me right now. I wouldn't mind disabling AutoAck except when i do my packet loss goes up considerably i'll have to send the same message 5 times for a device to receive the message. I thought maybe because if the ACK is not received then the message is resent anyways.


So my current technique for handling autoack on 2 devices with the same address is
           
    for (int x = 0; x < 6;) {
                  x ++;
                  if (!wirelessSPI.write( &Array, sizeof(Array))) {
                   
                  }
                }

Whandall

More than one stations are to receive the same command at the same time? Just don't AutoAck.
Using two clients answering to the same packet will nearly guarantee collisions, leading to resends.
The sender is not prepared to receive acks from different stations, so that could confuse it.

You can send a software ack to the senders pipe if you want to (with the client id, the acked command number, ...)

P.S. If you don't want to listen to answers/advice, why are you asking?

Ah, this is obviously some strange usage of the word 'safe' that I wasn't previously aware of. (D.Adams)

notsolowki

More than one stations are to receive the same command at the same time? Just don't AutoAck.
Using two clients answering to the same packet will nearly guarantee collisions, leading to resends.
The sender is not prepared to receive acks from different stations, so that could confuse it.

You can send a software ack to the senders pipe if you want to (with the client id, the acked command number, ...)

P.S. If you don't want to listen to answers/advice, why are you asking?


I like the idea of turning off AutoAck. The problem arises when i turn off AutoAck i get really bad send/receive success. With autoack off i have to send the message 4 or 5 sometimes for it to be received successfully. Is it possible im not experiencing this with AutoAck on because AutoAck  will automatically resend the message if the ack wasn't received therefore the message is resent automatically? i get pretty good range about 400ft through trees, and a couple of walls so maybe that rules on my power supply.

Whandall

If you want AutoAck and its auto-repeat feature, give each client a different address.

If you need synchronous reception, you can (at least should) not use AutoAck (for that message).
Ah, this is obviously some strange usage of the word 'safe' that I wasn't previously aware of. (D.Adams)

notsolowki

If you want AutoAck and its auto-repeat feature, give each client a different address.

If you need synchronous reception, you can (at least should) not use AutoAck (for that message).
Thank you for you patience and information i really appreciate it. I read you can disable AutoAck for a specific pipe/address but without AutoAck is it normal to have to resend the message to the receiver multiple times in a row for it to be received? Considering the devices are within 10ft of each other right now.

Noting that i do understand that AutoAck is re-transmitting the the message too so either way its being resent  up to 15 times. From your experience is this normal?

Whandall

With two PRXs on the same pipe I would expect a lot of retransmissions because the Acks will often collide.

For correct configured systems it is hard to say how many retransmissions are needed,
it depends on too many parameters.

I don't think the library gives you access to the number of retransmissions, it only communicates a
retransmission failure (via returncode of write).
You could time the duration of write (which is blocking) to estimate/calculate the number of retransmissions.

Give all stations a good 3.3V supply, independent from the 3.3V of the Arduinos.

Use a channel that does not collide with other 2.4GHz traffic.

If the modules are close to each other try lowering the output power.

If you have range problems, first lower the baudrate and if that fails, try high power modules,
but you were talking about 10ft, so this is more for completeness.
Ah, this is obviously some strange usage of the word 'safe' that I wasn't previously aware of. (D.Adams)

notsolowki

With two PRXs on the same pipe I would expect a lot of retransmissions because the Acks will often collide.

For correct configured systems it is hard to say how many retransmissions are needed,
it depends on too many parameters.

You think oh wow these nrf24 cards are cheap, BUT they are a pita at least for me. I've been trying to use them for a few months now and i always end up building another PRXs device and adding more the the network chain.

I have "currently" 8 PRXs, there a 2 of each device except i have 4 of 1 module. So with 8 devices i only have 3 addresses "hopefully i haven't lost you yet. The collision starts getting really bad when all 8 devices start blasting the PTX with messages every 150 - 200ms. All the messages contain variables that the PTX collects and sorts then displays on a tft.

Since we only have 6 pipes to work with i figure id keep the addresses simple and let the PRXs that are duplicates of each other use the same address and pipe so im using 3 pipes for transmitting to the PRXs. So your probably right i have all these incoming packets to the PTX so they are probably crashing into each other all the time forcing me to retransmit all the time. Now im struggling to come up with a solution to all the collision. The easiest so far "only" way around it i found with my limited knowledge in nrf card is to retransmit as many times as needed, But this causes longer blocking times in the code eventually leading to more bugs.

Whandall

#14
Jul 22, 2019, 06:21 pm Last Edit: Jul 22, 2019, 06:34 pm by Whandall
I prefer to use some global pipes without ack for the 'normal' communication like reports/announcements,
that any interested node can listen to, most info will be repeated once a second.
Each node gets a personal address with ack for commands or the like.
I have less than 256 nodes in a group, so I use pipe addresses that only differ in the lowest byte
to allow full use of all pipes.
I always use dynamic payloads, most of the packets I use are smaller than 32 bytes.
I try to maximize the reception time of any node, only switching to PTX when performing a single send.

It all depends on the application. You will loose packets, but most of the time that does not really matter.
Triggered motion alarms could broadcast their alarm much more often until commanded to be silent again.
A single lost temperature measurement of the living room does not hurt anybody.

I did not encounter the need for synchronous guaranteed reception or command execution yet,
but I don't think there is an easy solution.
Ah, this is obviously some strange usage of the word 'safe' that I wasn't previously aware of. (D.Adams)

Go Up