New protocol for iNav flight control software

1. I'll fix the Beken registers - that was just a bit of cargo cult programming on my part.

2. As for the 6 channel protocol, I'll get rid of it. At the back of my mind I had the idea that the smaller payload could be used on race quads - a smaller payload means faster reading and interrupt processing on the receiver. I was thinking of then having very low packet periods (say 1000us) so that the receiver would be updated at a high frequency. Then you could get rid of RC smoothing on the flight controller. But it's all a bit pie in the sky at the moment, and I haven't done any calculations as to its feasibility. So I'll leave it out for now and perhaps revisit the idea later.

Hey guys this is interesting stuff, f.i. the revo F4 flight controller now has a UHF module connected via SPI, should we than just hook up the NRF module instead? Would it be faster latency wise? Could we send first 4 channels faster?

Would there be some future possibilities for having this direct open telemetry link between TX and Flight controller, to be able to enter a flight control settings menu for changing some basic stuff from your Tx, such as change pids, set failsaves, change the rates and spr expo etc etc.

@Fernandez, I hadn't considered the possibility of replacing the REVO UHF module with a NRF, but that sounds an interesting possibility. One of the problems of attaching an NRF24 to a flight controller is that the SPI pins are often not easily accessible. Replacing the REVO UHF module is not too hard a soldering job. Same applies to the Sparky2.

As for latency, hardware wise I'm not sure. But software wise, I think we could get good latency. I haven't yet implemented interrupt processing in the iNav code - the NRF receiver is currently polled, but changing this should be fairly straightforward.

I've also been thinking of experimenting with much higher transmitter rates, eg 1KHz. Transmitter protocols seem to currently update at 200Hz or 250Hz (but I haven't really spent much time looking into this yet).

I'd certainly be interested in extending the telemetry to include more information, including PIDs and rates etc. Currently betaflight et al has facilities for changing these using the transmitter, so it would be just a question of extending the telemetry to be able to display them on the transmitter.

I'm very keen for people to experiment with this, and I'm very happy to make changes based on feedback from testing and suggestions for improvements.

mjbudden

we wait this project come in soon , Nrf24l01 very cheap .
I try connect nrf24l01 to hardware Naze F1 ,, choose Nrf24l01 and protocol syma. But seem it not yet work ,
In Tab RECEIVER , i do not any signal display

@goebish

Your NRF24L01_Activate(0x73) tip fixed the problem.

It's funny, I knew about the ACTIVATE command, but the NRF24L01P documentation said it was not required, it's only required for the NRF24L01 (no P). I guess the cheap clones are non-P variants.

@mj budden this flight controller:
www.banggood.com/OpenPilot-Mini-CC3D-Rev...er-5g-p-1018903.html

Is basically an REVOF4, it has same wiring to the F4 runs same firmware, but it has no UHF RF module, but the spi pins are wired to a connector, so you can hook up over SPI direct an RF module.
If you really go down that way and close couple RX into Flight control, than basically 4 fast control channels are needed all other setting switches etc, can be just a digital one bit no need for full channel save a lot of bandwith !
If you are going forward with this F4 and Betaflight, I'll definitively will follow this with great interest, I could test possibly as own this controller. If you spend all that time programming make sure you select the RF chip with best capabilities, possibly cc2500 used by Frsky, Futaba, Multiplex etc might be best choice?

For configuration from TX basically the CLI commands must be transferred from TX to Flight control, sound really great!

I didn't realise that the Revo mini brought all the SPI pins out onto a connector. I'll certainly get hold of one and get the code working on it.

Certainly one of the motivations for my work is to be able to increase the RX refresh rate.

In betaflight the current RX refresh rate means that the RX input can be "bumpy", so people often seem to use RX smoothing. A faster RX refresh rate might make this unnecessary. I think it might be interesting in experimenting with RX rates of, say 1KHz. (RX rates currently seem to be 200Hz or 250Hz).

It's already possible to use the TX to change the PIDs using the in-flight adjustments feature. This is available on Cleanflight/betaflight/iNav. See this post for how to do it: www.propwashed.com/in-flight-adjustments/

What is missing is the ability to display the PIDs on the transmitter - I intend to update the telemetry to do that.

Yes but I believe it is not user friendly. all is just brainstorming here.......

For racing we need 4 high speed low latency control channels, then all switches possibly some variables etc do not need to take full channel of bandwith, just some bits and may have some latency too.? For pids and settings, it would even be fine if this can only be adjusted when quad is disarmed, so controls are off and system could go into kind of telemetry mode, basically the CLI commands can be send from Tx, ?

If a new menu's in deviation could be added in the future for configuring external devices as flight controller, esc setup, the whole benefit of this that you do not any longer need setup assign any channels etc,to setup pid etc and control wise it would create best link highest speed lowest latency.

@goebish,

now that I've got the telemetry going, I'd like to add the PID values to the telemetry, so they can be displayed on the transmitter to facilitate tuning. However the telemetry pages don't seem to have an appropriate slot to display this data. Is it possible to extend these pages to show more values?

Unfortunately, Deviation does not have so convenient abstraction for telemetry as it has for control - Channels and mixer.

So telemetry is a bit ad hoc, not you're lazy, goebish.

Currently I am using the DSM telemetry type and abusing some of the fields.

Creating a new type should not be too difficult, but I am concerned about ROM size. Won't doing this use quite a bit of ROM?

Pick up this new protocol on git pull today. Where can we get iNav? Is that a flight controller like Naze 32 with RF builtin?

The protocol uses auto ack, I wonder if 3 or 4 in 1 can handle that.

Newer 4-in-1 should. Have not tested yet - real life interferes.

iNav is flight control software, see github.com/iNavFlight/inav/releases

I'm also working on getting the iNav protocol into betaflight, it should be in betaflight 3.1 when that comes out.

That's what I found on the web too. Then why do we have inav_nrf24l01.c? How is iNav tied to NRF24l01? Is the iNav shipped with a certain flight controller? Which one is that?

If I can load the iNav FW onto my Nase32 10 DOF, I probably use it with a lemon DSM2 sat. How would I be able to use the iNav protocol which is nRF24L01 based?

Downloaded the source. Looks like it is NRF24L01 on CC3D only. Is that correct?

iNav is a fork of Cleanflight targeted for "navigational" rather than racing use. So it supports waypointing, GPS based position hold etc. It runs on a variety of flight controllers and supports a variety of receivers. I've recently added the ability to support a NRF24L01 receiver. There are currently builds for the NAZE, CC3D and CJMCU flight controllers, but I intend to add more builds in future.

If you are using a lemon DSM receiver, then you won't be able to use the iNav protocol - since it is NRF24L01-based.

Thanks for the clarification.

I have to get another nrf24l01 RF module to try it out. It is bidirectional, hence we need the one with PA too.