What distinguishes an ACK packet on-air from a regular packet?

[Ant Skelton]

I would like to implement a simple wireless sensor network, using Enhanced Shockburst with Auto-ACK. The idea is that there will be many sensor nodes (SNs) reporting to one master node (MN). The MN will listen on address P0 (say 0x0011223344) and all SNs will transmit to this address on an intermittent, periodic basis.

Assume I have auto-ack enabled everywhere.

1. Node SN0 transmits a packet with PID=1, it begins listening on P0 for an ACK from MN.
2. Before the ACK can be sent, a second node SN1 transmits a packet with PID=1 also.
3. Since SN0 is listening on P0 while SN1 is transmitting on P0, will SN0 mistakenly identify SN1's data packet as an ack from MN?

As far as I can tell, for the same PID, there is no difference between a regular data packet and an ack-with-payload: I am assuming that ACKs are always sent with the NO_ACK bit of the PCF set to 1, and that a PTX detects a valid ack if ((ack_pid == last_tx_pid) && (ack_nak == 0)) ???

If this is the case, then I can assume that the answer to my question above is "no", but what about this:

1. Node SN0 transmits a packet with PID=1, it begins listening on P0 for an ACK from MN.
2. Before the ACK can be sent, a second node SN1 transmits a packet with PID=1 also, and listens
3. MN sends ACK on P0 with PID=1.
4. Presumably both SN0 and SN1 will interpret this as a valid ACK, even though it was meant for only one of them?

This would seem to make sense; I am happy to burn some payload bytes to identify individual transmitters, I'd just like to verify that my assumptions are correct.

[Håkon Alseth]

Hi,

You will get collisions in this scenario. It is not recommended to have several devices using the same pipe (w/ACKing) communicating with one host. An ACK payload is just a normal payload with no data. This will then include such things as PID/Addr/CRC etc. Note that you cannot read out the PID values from the radio. If a valid packet has been received, you will only get the actual payload.

You will have certain corner cases where Device#1 can get interference from Device#x. If you were to build up a system like this, then you will have to time-slice the transmission from each device to make sure that they do not collide, which is a complicated thing to implement properly.

The easiest way is to open more pipes, and have each device communicate using different RF addresses.

-H

[Ant Skelton]

Hi thanks for the response, it is useful and informative. However, I would still like to know what distinguishes an ACK on-air from a regular data packet.

Imagine a node has just sent a packet:

PKT: { addr=[0xaa,0xbb,0xcc], PCF={len:1, NAK:0}, payload=[0x55], CRC=x}

According to the ESB/PTX flowchart, the PTX is now in "RX mode --> is it an ACK?"

Imagine that the ACK to this packet also has a payload, also one byte, also the value '0x55'.

Does the ACK look like this:

ACK: { addr=[0xaa,0xbb,0xcc], PCF={len:1, **NAK:0**}, payload=[0x55], CRC=x}

Or does it look like this:

ACK: { addr=[0xaa,0xbb,0xcc], PCF={len:1, **NAK:1**}, payload=[0x55], **CRC=y**}

In other words, how is the decision "Is it an ACK?" actually made?

And, depending on the answer to that, can the PTX ACK-check be fooled by an identical PKT sent from a different node?

[I am using a single data-pipe in an attempt to keep the question simple; for my network I plan to use all available pipes as you suggest.]

cheers

ant

[Håkon Alseth]

If you have not enabled dynamic payload length, the payload will be equal to any other payload, except it is '0' in length.

The whole PFC field will remain the same unless EN_DPL is set.

Let's say that two devices send almost at the same time. Host receives payload from Device#1. Both devices goes into RX mode, and receives the host's ACK. In this scenario, both devices will get a TX_DS interrupt, while the host only got one of the payloads.

If you plan to have more devices communicate on the same pipe, with an extended address byte in firmware, then you will have to disable the hardware acking and do this in firmware instead.

-H

[Ant Skelton]

Hi,

Thank you for the further info; it is interesting and illuminating, and answers the second point in my original post, but I am still unclear as to what distinguishes an ACK on-air from a regular data packet. My fault, I am not making the question sufficiently clear.

A sensor sends a packet with a payload length of 1. EN_DPL is enabled, hence PCF[len] is equal to 1. The single payload byte is 0x55:

    
PKT: { 
  addr: [011,0x22,0x33],   // three byte address
  PCF: {
     len:1,    // DPL is 1 byte
     PID: 1,                         
     NAK:0    // NO_ACK is FALSE for ESB
  }, 
  payload: [0x55],    // single payload byte
  CRC: x    // some 16-bit value
}

ie 01010101, 00010001 00100010 00110011, 000001 01 0, 01010101, x

A co-ordinator node receives this packet and sends an ACK. This ACK has a single byte payload. The single byte payload is also the value 0x55, by some strange coincidence. What does this ACK packet look like?

Is it like this? (answer A)

    
PKT: { 
  addr: [0x11,0x22,0x33],   // return to sender
  PCF: {
    len:1,    //  DPL is 1 byte
    PID: 1,    // ACK PID same as REQ PID
    NAK:1    // NO_ACK is true!!
  }, 
  payload: [0x55],    // single payload byte
  CRC: y    // CRC must therefore be different!
}

ie 01010101, 00010001 00100010 00110011, 000001 01 1, 01010101,y

Or is it like this? (answer B)

    
PKT: { 
  addr: [0x11,0x22,0x33],   // return to sender
  PCF: {
    len:1,    // DPL 1 byte
    PID: 1,    // ACK PID same as REQ PID
    NAK:0    // NO_ACK is false here too!
  }, 
  payload: [0x55],     // single payload byte
  CRC: x    // CRC same as orig, therefore!
}

ie 01010101, 00010001 00100010 00110011, 000001 01 0, 01010101, x

This is my first question. What's the format of the ACK? 'A' or 'B' ? Or something else?

My second question: if it is 'B', how does PTX's internal ESB logic know this is an ACK? How can it tell ACK from a duplicate identical packet (same address, same length, same PID, same NAK, same payload, same CRC) sent by a second sensor, for example?

Thanks for your help and patience!

ant

[Håkon Alseth]

The closest is answer B. However, len = 0, so the payload field will not be present. And therefore, the CRC will also be different.

If you setup two PRX with the same RF config (EN_DPL/DYN_ACK enabled), and one PTX that sends whenever it can, you will sooner or later observe a payload of 0 byte on one of the PRX.