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?

[Håkon Alseth]

Hi,

  

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?

 As you mention, you can do this with using auto ACK, and ACK payload.

To ensure that you receive the data, it is recommended that you send a "prepare ACK payload" command first to allow the host to upload it to the FIFO, then a dummy payload to fetch the actual ACK payload.

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

 What do you mean by "dynamic"? You can upload a ACK payload on a specific pipe, and on the next received payload on that specific pipe, the ACK will then be sent with your ACK payload.

 

Kind regards,

Håkon

[ulao]

Sounds straight forward. But as soon as I enable ackpayload or dynamicpayload I can no longer receive. Also noticed since I have been working with this my master needs to have tx and rx both set to the same address. (0x30 and 0x2a) IF not it will not send. I never understood that.

master short code

0x20,0x0A
0x25,2
0x26.0x0E
0x23,3
0x3D,6
0x22,0x3f
0x30,1,1,1,1,1
0x2a,1,1,1,1,1
pulse

0xa0, 0xff send payload ready flag
0xa0, 3 test code
pulse

receiver
This is an Arduino so I do not know what it is really doing but here is the output.

STATUS         = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1     = 0x0101010101 0c2c2c2c2c2
RX_ADDR_P2-5     = 0xc3 0xc4 0xc5 0xc6
TX_ADDR         = 0x0101010101
RX_PW_P0-6     = 0x01 0x01 0x00 0x00 0x00 0x00
EN_AA         = 0x3f
EN_RXADDR     = 0x03
RF_CH         = 0x02
RF_SETUP     = 0x0f
CONFIG         = 0x0b
DYNPD/FEATURE     = 0x03 0x06 <--- with this set I never receive data. with 0,0 I do.
Data Rate     = 2MBPS
Model         = nRF24L01+
CRC Length     = 8 bits
PA Power     = PA_MAX

[Håkon Alseth]

Hi,

 

ulao said:

Also noticed since I have been working with this my master needs to have tx and rx both set to the same address. (0x30 and 0x2a)

This is to get the hardware feature of auto-acking working. The transmitter will send on the TX_ADDR, then switch over to RX mode and wait for an incoming ACK on RX_ADDR_P0.

On the PTX (primary transmitter), you need to set the TX_ADDR equal to RX_ADDR_P0 to get auto-acking working.

On the PRX (primary receiver), this is not required.

ulao said:

But as soon as I enable ackpayload or dynamicpayload I can no longer receive.

Do you have the exact same configuration on both the PRX and PTX device?

If you only enable it on one side, it will stop working.

  

ulao said:

RX_ADDR_P0-1     = 0x0101010101

 Its very little change in bit pattern here. Its better if you test with the default "0xe7e7e7e7" address instead.

The rule of thumb is to avoid starting with 0x00, 0xFF, 0x55, 0xAA, as these bit patterns have longer bit-wise '0' or '1' sequences, and 0x55/0xAA looks like a continuation of a preamble-sequence.

 

Kind regards,

Håkon

[ulao]

Håkon Alseth said:

Do you have the exact same configuration on both the PRX and PTX device?

It turned out to by the dynpd, I didnt know that was required. it was set to 3 on the slave and default on the master. Setting both to 3 fixed it.

TNX!

[ulao]

Are there any other tips for speed here? my address is e7e7e7e7e7, my speed is 2MBPS and my rf at 18db.  I'm getting about 300us for the reply. I'm only 1 inch a way from the receiver. I set my SPI to max for my device and my nrf crc is 8 bit and I played with the pulse, where 3us does work, its not always working... So 10us it is then. Every us is going to count here so I want to make sure I think of everything before I move to the next step.

[Håkon Alseth]

Hi,

 

ulao said:

Are there any other tips for speed here?

 What speed are you currently seeing?

 

ulao said:

my rf at 18db.  I'm getting about 300us for the reply. I'm only 1 inch a way from the receiver.

You can saturate the receiver by using a PA and a range of 1 inch. Place them a meter apart.

 

ulao said:

I played with the pulse, where 3us does work, its not always working... So 10us it is then

 Don't optimize on the CE pin toggling. Keep this within spec.

 

Kind regards,

Håkon

[ulao]

I guess I was more so interest in if setting will affect speed in practices. Just trying to make sure  my data is sent fast as possible.

Also , few more questions.

1)
For some reason my receiver does not always ack back my payload.  I use 0x0b to set my data and then 0x0f to retrieve it.

0x0b 0xff - tells me receiver  to start.  Sets payload to 0xa0
0c0a 0xff - retrieve  - I Get back 0xa0

0x0b 0xa1 - tells me receiver  to prepare a 0xa1 packet . 
0c0a 0xff - retrieve  - I Get back 0xa0 <--- strange?

0x0b 0xa2 - tells me receiver  to prepare a 0xa2 packet . 
0c0a 0xff - retrieve  - I Get back 0xa0 <--- strange?

Do I need to clear bits or flush because I write the new payload?  This is an arduino so I'm not sure what it is doing behind the scenes.

2)

[EDIT - further investigation suggest its my chip]
when I send the same data this happens, so I think the counter int is not resetting on same data sends. This is a know issue on this chip (china clone) ill buy elsewhere. -a suspicion only-
[EDIT ]

What woudl it mean when my status registers goes from 2e to 3e?
to get my payload I just send NOP commands and read the status register. Normally it goes to a 0x60 around 300 us. But there are times it goes to 0x3e and my data is not ready. I'm not sure what is doing this. I make sure to first clear my ints before sending with

Enable();          
sendCommand(0x27);sendCommand(0x7F);
Disable();    
pulse();

[Håkon Alseth]

Hi,

 

ulao said:

Do I need to clear bits or flush because I write the new payload? 

 It sounds like your firmware isn't clearing the events (TX_DS, RX_DR, MAX_RT). I do not know details about the library you're using or how it works in the deep, unfortunately. Its quite normal that libraries, even arduino, clears these when needed.

 

ulao said:

when I send the same data this happens, so I think the counter int is not resetting on same data sends. This is a know issue on this chip (china clone) ill buy elsewhere. -a suspicion only-

 Could you share the chip markings of your device (take a picture of it for instance) so I can check it with known clone?

 

ulao said:

What woudl it mean when my status registers goes from 2e to 3e?
to get my payload I just send NOP commands and read the status register. Normally it goes to a 0x60 around 300 us. But there are times it goes to 0x3e and my data is not ready. I'm not sure what is doing this. I make sure to first clear my ints before sending with

If it goes from 0x2x to 0x3x,  It means that it the 4th bit is set, which is MAX_RT, ie: your receiver isn't responding.

 

Kind regards,

Håkon

[ulao]

...

[ulao]

[Håkon Alseth]

Hi,

 

1808AH is unfortunately a known fake revision, which can explain the strange behavior you're seeing.

Kind regards,

Håkon