custom write ack payload.

[ulao]

My end goal for development is something like the following.

Master sends 0x00 slave sends back 13 bytes of data.
Master sends 0x01 slave sends back one byte of data.
Master sends 0x02, 0x03, 0x04 slave calls a function with parm (3,4)

My plan is to send the data with disabling auto ack from the master and then going in to receive mode, and having the slave return the data by going in to  transmit mode. Though I was wondering if any of that can be automated with a custom ack?

EDIT: Ok just read this on the net.

"This acknowledgement message can contain a preloaded payload, meaning a system of bi-directional communications can be established entirely using a master device that transmits data requests to each slave device in succession. The nRF24L01+ does this by storing a preloaded message into its transmit First-In-First-Out (FIFO) buffer, and sending this message on the listening pipe address as soon as a message with ack payload requested is received."

If that sort of thing is possible, is there a small example or write up on that? Can a "preloaded message" be dynamic?

[ulao]

I did end up ordering the spark fun last week, I hope that solves most of the issue.

sorry "Does that mean after I send an ack payload it goes to e3 because it never received an ack back?" was a type o, I meant 0x3e...

Also wanted to ask when using ack payload with dynamic payload, how so I know the size of the data? " Payload is deleted from FIFO after it is read." concerned I'm not reading it all.

[Håkon Alseth]

Hi,

 

0x3X = MAX_RT and TX_DS set. Is this tested with the module that has the fake IC? If yes, then wait till you get a module that has a genuine nRF mounted.

ulao said:

Also wanted to ask when using ack payload with dynamic payload, how so I know the size of the data? " Payload is deleted from FIFO after it is read." concerned I'm not reading it all.

 Use "R_RX_PL_WID" to read the size of the payload at the top of the FIFO.

Yes, when its read out, its automatically pop'ed from the FIFO. If you do not read out the payloads, and get into a scenario where the FIFO is full, the transmission will stop working. Check the FIFO_STATUS register, field RX_EMPTY, when reading out the payload. If this 0, keep reading out payloads.

 

Kind regards,

Håkon

[ulao]

I did receive my new devies but still have the same issues.

I'm going to removed the ardiuno from this set up as its my only unknown but I need to understand the ack payload better.

to send data I use a two step 0xb0,id followed by a 0xa0,data. When sending 0xff I expect to get back a 0x0a, sending a 1 I want back a 4, and then 2 giving me back a 5. For example:

0xB0,0xFF// Should not ack back, just sets my ID for return.
0xA0,0xFF//This is my fetch Ack back. Should get 0x0a

or

0xB0,0x01// Should not ack back, just sets my ID for return.
0xA0,0xFF//This is my fetch Ack back. Should get 0x04

Issue is the first 1 or 2 commands always work but the other never seem to work. Ill get anywhere from status showing 0x2e to a 0x3e or just sending back 0x0a all the time. If I loop it, ill get 1 out of 10 back correctly and the others just time out showing 0x2e to a 0x3e .

So how does this 0xa0 work?

W_TX_PAYLOAD1010 0000   1 to 32LSByte firstWrite TX-payload: 1 – 32 bytes. A write operation always starts at byte 0 used in TX payload

W_TX_PAYLOAD_NOACKa1011 0000   1 to 32LSByte firstUsed in TX mode. Disables AUTOACK on this specific packet

Does the 0x0a tell the receiver not to ack back? If so how does that even work, if it acks immediately after read? What does "Disables AUTOACK on this specific packet" mean? Disable it where? I can not imagine it tells the receiver somehow its disabled? Will the receiver still try to send back the payload ? If the Disables AUTOACK on  is for the TX's information, I do not see how that is helpful. Maybe its just pointless for me to use in my design. I only expect ack when sending 0xff.

The way the arduino is set up, is it waits for data ready in a loop.

Once it sees the data, it reads it, then if 0xff, it does nothing further and the auto ack should be preformed then waits for the next read.

if not 0xff it must be a set. so it loads the payload for ack and then waits for the next read. Guessing it is acking back anyways as there is no way  to tell it not to.

[Håkon Alseth]

Hi,

  

ulao said:

Issue is the first 1 or 2 commands always work but the other never seem to work. Ill get anywhere from status showing 0x2e to a 0x3e or just sending back 0x0a all the time. If I loop it, ill get 1 out of 10 back correctly and the others just time out showing 0x2e to a 0x3e .

So how does this 0xa0 work?

W_TX_PAYLOAD will use auto-acking to reflect what the status of your transfer is. How long of a delay is it between the initial send and the "fetch" command? Is there a delay at all?

W_TX_PAYLOAD_NOACK will tell a device not to use ACKing

 

These settings assume that you have EN_DYN_ACK field in the FEATURE register set on both sides.

 

ulao said:

Does the 0x0a tell the receiver not to ack back?

Do you mean W_TX_PAYLOAD_NOACK? I am a bit uncertain what you're asking?

 

ulao said:

Disable it where? I can not imagine it tells the receiver somehow its disabled? Will the receiver still try to send back the payload ? If the Disables AUTOACK on  is for the TX's information, I do not see how that is helpful. Maybe its just pointless for me to use in my design. I only expect ack when sending 0xff.

The "NO_ACK" bit sets if the packet is to be ACKed or not. Please see the on-air format in the datasheet, chapter 7.3.

Again, this assumes that this feature is enabled in the register "FEATURE".

 

If you are expecting your application to send an ACK payload (PRX piggybacking data with the ACK payload), I would recommend that you just use W_TX_PAYLOAD first, then start optimizing with NOACK/ACK commands when you have it working.

 

Kind regards,

Håkon

[ulao]

Does the 0x0a tell the receiver not to ack back?

Do you mean W_TX_PAYLOAD_NOACK? I am a bit uncertain what you're asking?

Sorry I meant 0x0b, yes. and EN_DYN_ACK is set on both sides. 

  It seems what is going on here the set payload function in this library is buffering, not writing. I can set the payload with this writeAckPayload( 1, buf, len ) command.  for example.

writeAckPayload(1,size)

writeAckPayload(2,size)

writeAckPayload(3,size)

makes it so that ack back will first send a 1, then the next ack back a 2 then 3. I was expecting it to overight and not buffer. So I just flush the tx first and it works.

Looks like I'm good, thx for all the help.