NRF24L01+, details on ACK packet and PTX to PTX....

[tomjennings]

hi -- i'm a big fan of the NRF24L01+ chip, i've written a high-performance driver for it using most of the features, relying heavily on Dynamic Payload and Auto-acknowledgement. the driver code is here, GNU license: github.com/.../WPS_NRF24L01, in C++ for Arduino and TI Launchpad TM4C123. the code is currently working fine for both systems.

i am very comfortable using the NRF24L01+ in all of it's advertised modes without problem. i find no flaw in the chip, nor the documentation. the problem i have may very well be outside the capability of the chip, and i apologize if i am wasting your time because of this. but i feel like there is more performance available if i can solve this interesting addressing problem!

i have two questions, related. i will post question 2 separately, because it is more narrowly defined.

QUESTION 1:

i am attempting to use the chip in a peer-to-peer application (frequency-hopping scheme) that occasionally ends up with a link pair in PTX to PTX mode -- both simultaneously transmitting on the same channel/datarate/etc. this use is outside of the suggested application.

i am further "pushing my luck" by having each side of the link -- i will call them LEFT and RIGHT -- use a shared pair of pipe addresses, A and B. (I use here "A" and "B" to stand in for correct 5-byte addresses as suggested in the datasheet, because it is easier to type here). this system is working great except for the PTX to PTX case. For example:

LEFT NRF24L01+ TX_ADDR A RX_ADDR_P0 A RX_ADDR_P1 B

RIGHT NRF24L01+ TX_ADDR B RX_ADDR_P0 B RX_ADDR_P1 A

this works great, when LEFT is PTX and RIGHT is PRX, or the opposite, LEFT is PRX, and RIGHT is PTX. and of course there is no problem when both LEFT and RIGHT are both PRX -- no packet is received! (but my protocol times out).

the problem is when both LEFT and RIGHT are in PTX mode, and transmitting -- a FALSE POSITIVE AUTO-ACKNOWLEDGE is generated!

i am still analyzing the mechanism, but i believe that when (for example) the transmit packet from LEFT arrives in RIGHT's RX_ADDR_P0, it accepts this as the ACK packet signalling to RIGHT that its packet was acknowledged.

the "failure window" is wider than it would appear, in that any RF, on-air collision corrupting the packet then invokes re-transmission, and widens the "failure window" to (ARD * ARC) in time.

Nordic, do you think my analysis of my problem is correct? i will shortly attempt some solutions to this, but your input and insights would be greatly appreciated. my drivers are available for free at the URL above.

the NRF24L01+ is an amazing chip, of course i am not complaining here!

[tomjennings]

( i neglected to state that given the existence of addresses A and B in both systems, the code sets PTX to TX:A P0:A, P1:B, and to receive TX:B P0:B, P1:A. in other words, addresses A and B are assigned complementarily, PTX and PRX. as i said, the working environment precludes the ability to pre-assign unique-to-each system/chip, pipe 0 and pipe 1 addresses. though my use does in fact violate the documentation (and somewhat, common sense :-) it is surprisingly effective for all but PTX-to-PTX configurations. my solution of last resort will be to use this, and negotiate pipe addresses as part of the higher-level protocol; the "failure rate" window is about 1%, only, and i can ensure 100% reliable negotiation through other means. the worst possible case si that i stop using auto-acknowledge, and do "ack" via exchange of packets, A->B, B->A).

[Asbjørn]

An ACK is basically just a normal packet, so if you have configure both of them with the same pipe0 address and same tx address they will send each other what seems like ACKs. I believe you could work around this by using a different pipe for the shared channel, so that they both communicate towards a RX address that's not configure as address on pipe0. The ACK will always be sent to pipe0, so if you are transmitting towards a different pipe, even though you have two units sending, they should not be interpreted as ACKs, but as received packages.

[tomjennings]

hi, thanks for your helpful reply, and i apologize for taking so long to respond.

i've worked out that what i was attempting to do is not actually possible, directly. the fundamental requirement of the scheme was that the PTX address would remain the same for every chip in the network. when used in a peer-to-peer system each chip alternates PRX/PTX (which seems outside of chip design goals, though that wouldn't stop me :-)

i've simply disabled auto-acknowledge for my two protocols (a self-negotiating one-to-many/many-to-one system and a connection-based channel-adaptive/channel-hopping scheme); as useful as auto-ack is, the channel- and address-negotiation, eliminating the need to a priori assign addresses, or find clean channels is more important to me.