how to disable Ack payloads

copied from the .h file:

/**

  • Start listening on the pipes opened for reading.
    1. Be sure to call openReadingPipe() first.
    1. Do not call write() while in this mode, without first calling stopListening().
    1. Call available() to check for incoming traffic, and read() to get it.

fnb111: I have done all that.

But you use the crappy template(s) to test further? Hard to believe. Show the three or even five sketches using strucs with a counter.

fnb111: /** * Start listening on the pipes opened for reading. * * 1. Be sure to call openReadingPipe() first. * 2. Do not call write() while in this mode, without first calling stopListening(). * 3. Call available() to check for incoming traffic, and read() to get it.

Shure, if you use startListening before, which you don't.

The wrong duplicate detection gives an ack at the sender side, but the reception is not signaled by the chip on the receiver side.

gfvalvo:
So ignore it.

i’ll try to explain:

The data send when in AckPaylode mode is not recognized by the on/off modules as valid data- ie ‘01 = on’ ‘00 = off’

When the on/off unit is programmed with AckEnabled it receives a package - the led on the board blinks. But the LED’s does not switch

Whandall: But you use the crappy template(s) to test further? Hard to believe. Show the three or even five sketches using strucs with a counter. Shure, if you use startListening before, which you don't.

The wrong duplicate detection gives an ack at the sender side, but the reception is not signaled by the chip on the receiver side.

void setup() {

  Serial.begin(9600);
  radio.begin();
  radio.enableAckPayload();
  //radio.startListening();
  radio.setRetries(10, 8); // delay, count
  tft.reset();
  uint16_t identifier = tft.readID();
  tft.begin(identifier);

Just tried calling radio.startListening() in setup. When I press the 'data' button the unit freeze up. Not sure why this is happening?

fnb111: The data send when in AckPaylode mode is not recognized by the on/off modules as valid data- ie '10 = on'

If there is a problem it is not connected to ackpayload mode, that works flawlessly side by side with non ackpayload communication.

What is received?

Is an error reported at the sending station, or does it believe everything went well? Oh, you don't bother to print that info.

fnb111: Just tried calling radio.startListening() in setup.

Why?

If you never call startListening you can (and should IMHO) remove any stopListenings.

If you are listening and want to send, you have to call stopListening. If you want to receive after a send or after reset, you have to call startListening.

Whandall: If you use exactly four clients, the second and all the following packets with the same content will be regarded as duplicate, which is determined by a 2 bit counter, the pipe and the packet crc.

Use a struct for sending packets and include a counter that will guarantee different packet crc on the next polling round.

I think you problem is caused indirectly by the polling loop.

Im not sure what you mean by this.

Page 32 of the datasheet.

DupPacket.png

So the pipe does not matter (as I claimed in the quoted post), the PID/CRC is for the whole node.
If you are polling 4 (or a multiple of 4) stations they will get the same PID each time,
so to make them receive more than one packet their CRC (from packet content) has to be different.

Whandall:
Page 32 of the datasheet.

DupPacket.png

So the pipe does not matter (as I claimed in the quoted post), the PID/CRC is for the whole node.
If you are polling 4 (or a multiple of 4) stations they will get the same PID each time,
so to make them receive more than one packet their CRC (from packet content) has to be different.

I might be very slow on this one- what you are saying is flying over my head. I apologizes for this.

What I get from this (correct me if I’m wrong) is that I should send a structured package to the on/off unit containing the switched data?

The data is send via AckPayloads and recognized as valid data to switch a LED?

I did try radio.stopListening() and it made no difference

// ............ 1st unit ...................
    //radio.stopListening();
    radio.openWritingPipe (slaveAddress[2]);
    if (on_btn.justPressed()) {       // unit E
      msg[0] = 01;                   // LED LED 1 on

Packet Identity (PID) and CRC used by Enhanced ShockBurstTM Each packet contains a two bit wide PID field to detect if the received packet is new or resent. The PID will prevent that the PRX device presents the same payload more than once to the microcontroller. This PID field is incremented at the TX side for each new packet received via the SPI interface. The PID and CRC field is used by the PRX device to determine whether a packet is resent or new. When several data is lost on the link, the PID fields may in some cases become equal to last received PID. If a packet has the same PID as the previous packet, nRF24L01 will compare the CRC sums from both packets. If they also are equal, the last received packet is considered as a copy of the previous and is discarded.

So I have read this and a bit more- I fail to see where I went wrong. Could you please clarify my error?

If you are polling 4 (or a multiple of 4) stations they will get the same PID each time, so to make them receive more than one packet their CRC (from packet content) has to be different.

Whandall: If you are polling 4 (or a multiple of 4) stations they will get the same PID each time, so to make them receive more than one packet their CRC (from packet content) has to be different.

Do you perhaps have an example please?

I still don't understand how this is going to send a valid on/off request to the Uno to switch a LED on or off while AckPayloads are active.

IMHO your our problem is not connected to ackpayloads,
but to the constant paket content and the number of polled nodes.

You could just for fun add a fifth node to the polling list and see whether the problem persists,
this would give each node a different PID on each round.

You have no feedback/printout about a failing send, I would add some.

I don't have another board that is ready. I'll have to set one up tomorrow morning and do the test. Just to clarify:

The on/off units need AckPayloads enabled as well?

fnb111: I don't have another board that is ready. I'll have to set one up tomorrow morning and do the test. Just to clarify:

The on/off units need AckPayloads enabled as well?

Just add a dummy address to the list to change its length from 4 to 5, you don't need any new nodes for that.

If you don't use ackpayload (tx or rx side) you don't have to enable it, but it probably wont hurt (but it will enable dynamic payloads as a side effect).

experiment 1

I added

const byte slaveAddress[numSlaves][5] = {
  {'R', 'x', 'A', 'A', 'A'},      //Data
  {'R', 'x', 'A', 'A', 'B'},      //Data
  {'R', 'x', 'A', 'A', 'C'},      //Data Dummy
  {'R', 'x', 'A', 'A', 'E'},      //on/off
  {'R', 'x', 'A', 'A', 'F'},      //on/off
};

This is the max units I can add = 5

I received the data from ‘A’ ‘B’ ‘C’ with AckPayloads enabled
On/Off for ‘E’ and ‘F’ does not work

experiment 2

const byte slaveAddress[numSlaves][5] = {
  {'R', 'x', 'A', 'A', 'A'},      //Data
  {'R', 'x', 'A', 'A', 'B'},      //Data
  {'R', 'x', 'A', 'A', 'C'},      //Data Dummy
  {'R', 'x', 'A', 'A', 'E'},      //Data Dummy
  {'R', 'x', 'A', 'A', 'F'},      //on/off
};

I received data from’A’ ‘B’ ‘C’ ‘E’ with AckPayloads enabled
On/Off for ‘F’ does not work

fnb111:
On/Off for ‘F’ does not work

What was received?
What was the result of the send operation?

Does not work is not useful as failure description.

I can only comment on what I saw on the tft screen:

experiment 1

When the menu is in data mode the data was received from ‘A’ and ‘B’.
‘C’ is a dummy but <> was displayed

The on/off menu:
I pushed the on screen buttons to switch the LED’s ON on ‘E’ ‘F’.
No LED’s was switched

experiment 2

When the menu is in data mode the data was received from ‘A’ and ‘B’.
‘C’ ‘E’ is a dummy but <> was displayed

The on/off menu: I pushed the on screen buttons to switch the LED’s ON on ‘F’.
No LED’s was switched

Not sure if this clarify the findings.

If you don't answer my questions, I see no way to communicate.

BTW as far as I see your on/off nodes can not work. starting to see ghosts. ;)

You read the first byte of the 32 byte packet into the lower part of an integer and then you compare the whole integer to 0 1 10 or 11.

int msg[2];
   radio.read(msg, 1);
    if (msg[0] == 01) {
      delay(10); digitalWrite(LED0, HIGH);
    }
    if (msg[0] == 00) {
      delay(10); digitalWrite(LED0, LOW);
    }
    if (msg[0] == 11) {
      delay(10); digitalWrite(LED1, HIGH);
    }
    if (msg[0] == 10) {
      delay(10); digitalWrite(LED1, LOW);
    }

Too bad that the received packet will contain "Unit ", the number of the node and a lot of zeros.

char dataToSend[32] = "Unit ";
    dataToSend[5] = n + '1';       //start 'unit no' at 1
    rslt = radio.write( &dataToSend, sizeof(dataToSend) );

So 'U' will never equal 0 1 10 or 11, so how do you expect that to work?

Whandall: So 'U' will never equal 0 1 10 or 11, so how do you expect that to work?

Looks like OP does update msg[0] with a proper byte in when TX code is sending to an on/off node.

IMO, problem is OP's debugging technique. He doesn't have one. Just depends on looking at lights and TFT screen. The code needs to be littered with debug prints to find out where the packets are getting "lost".

Also, I agree that all packets should be a struct that includes a slave-specific sequence number. I'd include a sequence number in the Ack reply payloads also.