NRF24L01 Tx power versus ShockBurst ACK packages

Hi,

do the protocols which use the NRF24L01 module send their packets in ShockBurst mode?

Because if this is the case I suppose that the limiting factor for achievable range are the ACK packages, which get sent back from the quad copter, and not the selected Tx power of the remote control. Is this assumption correct? <speculation>If so, then there is probably not much improvement when using an NRF24L01 module with integrated amplifier chip compared tho the modules without one.</speculation>

Cheers,
Markus

No sane RC protocol would depend on receiving the ack packets. Might be useful in other applications.

To me the AA feature's best trick for RC is the ability to return payload data in the AA packets. Perfect for telemetry, but none of the nRF protocols do it.

I looked through the *_init() functions of the *_nrf24l01.c protocols. Most of them disable Auto Acknowledge, but a few enable it: cflie, ne260, yd717

I'm not yet familiar enough with the codebase, to say if this means that the range of the quads using those protocols is determined by the receiver in the quad who sends the ACK packets back.

FDR wrote: @Hexfet:
Are you aware of this discussion?:
www.deviationtx.com/forum/protocol-devel...an-nrf24l01-protocol
There is a lot of talk about using ACK...

I may jump in when I have more time (hah!). I was intrigued by the word "tiny" in the first sentence, but the thread seems to be on the way to MavLink

When I said don't depend on ack I mean don't stop sending if you don't get acks. Knowing what I know now I would have disabled retransmits in yd717 and just gone on to the next packet. Although you can get a crude connection integrity measurement by monitoring retransmits and lost packets, it wasn't very useful in a quad you can't see more than 25 meters away.

The protocol can optionally take actions when acks disappear: set an alarm, up the tx power, automatically send RTH faster than the operator can react, etc. Probably a good idea to start sending an indicator that acks are not being received so the flight controller has a chance to react if it is still receiving. The flight controller has choices when it receives notice that acks are not being received, and again when it stops receiving packets. Typically the acks will be lost first because the tx has more power.

It's not all wins. If the flight controller stops receiving it won't be sending any acks. Might be good to start swapping between listening and broadcasting position info to help retrieval.

Software doesn't weigh much, so tiny and feature-full are not exclusive.

I would agree that it makes no sense to retransmit old data in the case of a missing ack, rather at any given point in time the most current data should be sent. In that sense, an RC protocol is more along the lines of UDP than TCP - even though we want a reliable link, we want to accomplish that ourselves by doing the most intelligent thing when the connection is spotty, not having a lower layer of the transport trying TCP-like to repeatedly to send the oldest unsent frame which is getting less and less relevant by the millisecond.

I'll have to take another look at the ack implementation in the yd717 stuff - I did try that quickly last week from the Multiprotocol code and found the control extremely intermittent. At the time I attributed it to a slower transmitter MCU clock perhaps not generating packets on time (which may well still be the issue) and that got me thinking about synchronization strategies in general..

In terms of the modules with additional PA potentially being used on a transmitter I believe they also have an LNA so they should "hear" a few dB better than the plain ones flying on the aircraft. That may do a little to offset the power level of replies coming from the aircraft. For the tiny stuff I'm targeting it's not an issue though as radio range should easily exceed visual range - in fact at the moment I'm doing fine with the PCB track style antenna on the transmitter, though I have a wire on the receiver.

I was thinking of this , which I have the hardware for but haven't built yet. Now looking at the map I'm surprised the chip is only half-full so looks like there is room for some steps towards this

The yd717 protocol requires acks to exit the bind phase, but once in the data phase ignores ack timeouts. Which matches the quad behavior since it doesn't try to rebind unless it's powered off. Other options are possible of you control both ends of the link.

If acks are missed it will retransmit for 5ms (10x500us). Since the packet period is normally 8ms, no updates will be missed even if all the retransmits are made. If that condition is met then retransmits may make sense if it's important to get the ack data for each packet.