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?
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.
notsolowki:
Is it okay to have AutoAck enabled when sending to 2 devices with the same address?
No.
Whandall:
No.
Can you tell me why and why not please? In a short way if you'd like thanks.
No, I will not read the data sheet to you.
Whandall:
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.
It does. It specifies the acknowledge communication as a communication between two stations.
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.
Whandall:
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))) {
}
}
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?
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?
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.
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).
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).
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?
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.
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.
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.
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.
notsolowki:
Since we only have 6 pipes to work with
It is with great reluctance that I enter this discussion but I feel I have to ask why you think you need more than 1 pipe?
Robin2:
It is with great reluctance that I enter this discussion but I feel I have to ask why you think you need more than 1 pipe?
I'ts funny that you mention than iv'e been thinking about the way my code handles the communication for this whole project and its starting to get harder and harder to maintain. I'm running out of knowledge. I use the pipes like that because it was the only way to achieve what i'm doing with my limited knowledge. I have all these PRX's and 1 main "PTX Control panel" all of the PRX devices constant on a timer of "100's of ms" send a list of variables to the PTX. The PTX then updates an "tft-lcd" with this information. My plan was to open reading pipes on the PTX for all the addresses of the PRX's i needed to receive data from that way i didn't have to constantly switch reading pipes, it just seem a lot more stable that way. Right now i'm realizing all of my programs are breaking and i have no idea what to do about this whole pipe/ack situation. I don't think i can read multiple addresses on the same pipe without closing and opening the pipes. Some guidance would be really appreciated right now.
notsolowki:
My plan was to open reading pipes on the PTX for all the addresses of the PRX's i needed to receive data from that way i didn't have to constantly switch reading pipes,
Have you looked at the examples in the link I gave you. It includes an example for a master and 2 slaves that can easily be extended to a larger number of slaves. That example only needs to use 1 pipe.
If you can't use a polling system then get all your "slaves" to send data to the same address on the "master". Even if you use multiple pipes on the master it only has one wireless receiver so it can only receive from one slave at a time. And in order that the master knows which slave sent the data just include a character in the message that represents the ID of the slave sending the data.
I have used the terms "master" and "slave" because I think you have got your usage of PTX and PRX mixed up.
...R
Robin2:
Have you looked at the examples in the link I gave you. It includes an example for a master and 2 slaves that can easily be extended to a larger number of slaves. That example only needs to use 1 pipe.If you can't use a polling system then get all your "slaves" to send data to the same address on the "master". Even if you use multiple pipes on the master it only has one wireless receiver so it can only receive from one slave at a time. And in order that the master knows which slave sent the data just include a character in the message that represents the ID of the slave sending the data.
Please forgive me I'm still a little confused. Which part of the tutorial are you referencing to Master swap roles, or Two-way transmission? I'm trying to understand ard you saying just cycle through the reading pipes constantly? All off my PRX's do send data to the PTX. In my head I thought I should leave the reading pipes open so the PTX was read to get messages all the time. I Really am trying to understand what you mean. Btw all of the PRX's do send to the same address. Am I suppose to open just one reading pipe on the address the PRX'S are sending to or switch between addresses real time?
EDIT: I just found the tutorial you were talking about on the second page. I'm reading it now.
In reply #17, So I dont need to open a separate pipe to read from other addresses as long as the messages are being sent to the PTX address?? I seen if(ack.avaliable) but no mention of the PRX addresses
It looks like I was wrong to get involved here.
The example with multiple slaves is in Reply #17 in my Tutorial. Reply #29 is about checking that an Arduino is correctly communicating with the nRF24 it is attached to - that Reply is not about wireless transmission.
What is your understanding of what PTX stands for?
...R