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

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

tomjennings — Sat, 11 Apr 2015 17:14:45 GMT

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.

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

Asbjørn — Thu, 12 Mar 2015 16:57:23 GMT

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.

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

tomjennings — Fri, 06 Mar 2015 05:51:36 GMT

( 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).