- Posts: 21
New protocol for iNav flight control software
- mjbudden
- Topic Author
- Offline
This adds a new protocol I've been developing for use with the iNav flight control software github.com/iNavFlight/inav . The plan is also to include this in the betaflight 3.1 release (that is the one after the forthcoming 3.0 release).
The aim to have a robust NRF24L01 protocol so that NRF24L01 receivers can be used by mainstream flight control software. The protocol is described in the nrf24_inav.c file (see end of post).
The aim is to add telemetry by returning telemetry data in the ACK packet, but this is not implemented yet.
This is my first attempt at writing a NRF24 protocol so comments are most welcome.
/*
* iNav Protocol
* Data rate is 250Kbps - lower data rate for better reliability and range
*
* Uses auto acknowledgment and dynamic payload size
* ACK payload is used for handshaking in bind phase and telemetry in data phase
*
* Bind payload size is 16 bytes
* Data payload size is 8, 16 or 18 bytes dependent on variant of protocol, (small payload is read more quickly (marginal benefit))
*
* Bind Phase
* uses address {0x4b,0x5c,0x6d,0x7e,0x8f}
* uses channel 0x4c (76)
*
* Data Phase
* 1) Uses the address received in bind packet
*
* 2) Hops between RF channels generated from the address received in bind packet.
* The number of RF hopping channels is set during bind handshaking:
* the transmitter requests a number of hopping channels in payload[7]
* the receiver sets ackPayload[7] with the number of hopping channels actually allocated - the transmitter must
* use this value.
* All receiver variants must support the 16 byte payload. Support for the 8 and 18 byte payload is optional.
*
* 3) Uses the payload size negotiated in the bind phase, payload size may be 8, 16 or 18 bytes
* a) For 8 byte payload there are 6 channels: AETR with resolution of 1 (10-bits are used for the channel data), and AUX1
* and AUX2 with resolution of 4 (8-bits are used for the channel data)
* b) For 16 byte payload there are 16 channels: eight 10-bit analog channels, two 8-bit analog channels, and six digital channels as follows:
* Channels 0 to 3, are the AETR channels, values 1000 to 2000 with resolution of 1 (10-bit channels)
* Channel AUX1 by deviation convention is used for rate, values 1000, 1500, 2000
* Channels AUX2 to AUX6 are binary channels, values 1000 or 2000,
* by deviation convention these channels are used for: flip, picture, video, headless, and return to home
* Channels AUX7 to AUX10 are analog channels, values 1000 to 2000 with resolution of 1 (10-bit channels)
* Channels AUX11 and AUX12 are analog channels, values 1000 to 2000 with resolution of 4 (8-bit channels)
* c) For 18 byte payload there are 18 channels, the first 16 channelsar are as for 16 byte payload, and then there are two
* additional channels: AUX13 and AUX14 both with resolution of 4 (8-bit channels)
*/
Please Log in or Create an account to join the conversation.
- Cereal_Killer
- Offline
I cant be of any help but if you can post exactly which modules you're testing with I'll get a set of them ordered so I can be testing stuff as you release it. I have an NRF installed but it's non-PA and I'm not about to fly any real models with a low power NRF module plus I dont have the knowledge to debug different HW so I'd just prefer to use exactly what you're using lol.
Taranis X9E | DEVO 10 | Devo U7E | Taranis Q7
What I do in real life: rivergoequestrian.com/
Please Log in or Create an account to join the conversation.
- mjbudden
- Topic Author
- Offline
- Posts: 21
up until now I've been busy with the iNav and betaflight releases and so have not been able to spend much time on this.
I've been bench testing with just the basic NRF24L01 modules with no PA. I'm now starting to test with an E01-ML01DP5 module, which is the one recommended by iforce2d in his range test comparison video:
Any testing you can do would be very helpful. It would certainly be useful to test the Deviation multi module and the Taranis module (I don't have a Taranis).
If you could do some range testing that would also be great. If you could post the results with the transmitter and receiver used, that would be very helpful.
On the software side, any help with getting the telemetry working would be most welcome.
Please Log in or Create an account to join the conversation.
- Cereal_Killer
- Offline
Taranis X9E | DEVO 10 | Devo U7E | Taranis Q7
What I do in real life: rivergoequestrian.com/
Please Log in or Create an account to join the conversation.
- mjbudden
- Topic Author
- Offline
- Posts: 21
What flight controller do you have, and I'll start by writing the documentation for that.
Please Log in or Create an account to join the conversation.
- goebish
- Offline
- I Void Warranties
- Posts: 2631
I think many people are interested about naze32 + nrf24l01, I got quite a few PMs for that
Please Log in or Create an account to join the conversation.
- anthony7288
- Offline
- Posts: 51
Can you support protocol ASSAN or HISKY ( nrf24l01 ) ? i saw atm support protocol V202, SYMA ,H8. ...
Please Log in or Create an account to join the conversation.
- Cereal_Killer
- Offline
mjbudden wrote: Well, there is no documentation yet. I haven't had time to write it yet.
What flight controller do you have, and I'll start by writing the documentation for that.
Does it run on an F1 target?
If it'll run on F1's I'll test on a currently assembled model (one which I don't mind crashing) and can start testing right away on a Naze32 setup. If it's f3 only I'll use my F3 clone board (see link, idk what to call it) but note, in that case I'll only be able to ground test as the model I got that FC for isn't built yet (I don't mind ground testing, just be advised any testing of this setup won't be actual flying tests...)
m.banggood.com/Upgrade-NAZE32-F3-Flight-...acing-p-1010232.html
Taranis X9E | DEVO 10 | Devo U7E | Taranis Q7
What I do in real life: rivergoequestrian.com/
Please Log in or Create an account to join the conversation.
- mjbudden
- Topic Author
- Offline
- Posts: 21
Any testing you can do, including ground testing, is much appreciated.
@anthongy7288, neither ASSAN nor HISKY are supported. Since HISKY is supported by deviation, it should be possible to port that. I'll put it on my todo list - but it will be a while before I can do anything for that protocol.
Please Log in or Create an account to join the conversation.
- goebish
- Offline
- I Void Warranties
- Posts: 2631
Please Log in or Create an account to join the conversation.
- mjbudden
- Topic Author
- Offline
- Posts: 21
I wonder if I can ask for your help. The iNav protocol is all working on a NRF24L01 attached to a flight controller and also on the deviationTx. However I cannot seem to get the AUTO ACK working (and therefore don't yet have full binding or telemetry). I'm pretty sure it is the receiver side that it not working - I've probably not set a bit for a register properly, but I can't find it in the code.
Can you have a look at the code? It's at: github.com/iNavFlight/inav/blob/master/src/main/rx/nrf24_inav.c (and the driver is at github.com/iNavFlight/inav/blob/master/s...rivers/rx_nrf24l01.c )
I've probably made some silly mistake, but just can't find it.
Please Log in or Create an account to join the conversation.
- goebish
- Offline
- I Void Warranties
- Posts: 2631
Some clones have the ack bit reversed and are not compatible with genuines when using auto-ack / retransmit ...
Please Log in or Create an account to join the conversation.
- mjbudden
- Topic Author
- Offline
- Posts: 21
I
Please Log in or Create an account to join the conversation.
- goebish
- Offline
- I Void Warranties
- Posts: 2631
Here's a comment from a Nordic employee:
hackaday.com/2015/02/23/nordic-nrf24l01-...ake/#comment-2474764
Please Log in or Create an account to join the conversation.
- mjbudden
- Topic Author
- Offline
- Posts: 21
So which bits are reversed? Do you mean the bits in the NRF24L01_01_EN_AA register? Or is it something else?
Please Log in or Create an account to join the conversation.
- goebish
- Offline
- I Void Warranties
- Posts: 2631
The best you can do is to use the same boards on the rx and tx to test your code so you're sure there's no hardware compatibility issues.
Please Log in or Create an account to join the conversation.
- mjbudden
- Topic Author
- Offline
- Posts: 21
Please Log in or Create an account to join the conversation.
- goebish
- Offline
- I Void Warranties
- Posts: 2631
www.nordicsemi.com/kor/layout/set/print/...roduct-Specification
see implementation of NRF24L01_Activate in deviation then
NRF24L01_Activate(0x73); // Activate feature register
NRF24L01_WriteReg(NRF24L01_1D_FEATURE, BV(NRF24L01_1D_FEATURE_EN_ACK_PAY) | BV(NRF24L01_1D_FEATURE_EN_DPL));
NRF24L01_WriteReg(NRF24L01_1C_DYNPD, BV(NRF24L01_1C_DYNPD_DPL_P0)); // enable dynamic payload length on P0
NRF24L01_Activate(0x73);
Please Log in or Create an account to join the conversation.
- mjbudden
- Topic Author
- Offline
- Posts: 21
Please Log in or Create an account to join the conversation.
- victzh
- Offline
- Posts: 1386
1. Can you remove initialization of Beken registers 0x06-0x0b? They originally crept in the code because I had a sloppily programmed TX to reverse - I copied code verbatim and these registers are just meaningless.
2. Do you really need a distinction between 6 channel and 12 channel options of the protocol? Why not always 12? Do you really save anything using 6? It would simplify coding and deployment (in a sense you should not care about correct options).
Please Log in or Create an account to join the conversation.
- Home
- Forum
- Development
- Protocol Development
- New protocol for iNav flight control software