since I own more planes and multi-copters controlled by FC with ArduPlane/Copter at the field I often forget what flight modes I have set on current vehicle. Thus I decided to create small device with OLED display attached to RC Transmitter that will connect to started FC in vehicle and show flight modes and their order that I can use switches on RC transmitter in correct way.
Because of MAVLink library implementation the device will be at least sort of esp32 interfaced with Bluetooth or WiFi. FC then must be configured with one serial port to emit MAVLink telemetry through BT or WiFi. I guess this telemetry contains even flight mode settings.
I would like to ask here if somebody have done this job already that I’m not going to reinvent the wheel again?
In my cause I’m using frsky modules(xr8) and crossfire with tx16s, so I’m using the same pattern for flight modes - I’m using the 6 position switch, first is stabilize, loiter, cruise, acro, takeoff and RTL. The use of frsky and crossfire, I always use the telemetry to send to the radio the telemetry and flight modes and in the OSD I have all information too. One whing I don’t know if you considered is to use the oled display in the i2c port of the flight controller?
Well that is not what I intended to have. I have I2C display on top of my vehicles but I want to have it attached even to my RC TX and displayed it there when vehicle is in the air.
Your post was not clear. I going to suggest the same oled display that has been around for years. What’s wrong with telemetry on the transmitter providing flight mode? Or does that still not answer the question?
>What’s wrong with telemetry on the transmitter providing flight mode?
Different vehicles have different flight modes and even in different order. Not going to explain why I need it so but I need it so. Therefore I want to have possibility to display all six configured flight modes on display attached to RC TX. Current flight mode have already solved with push buttons each of them having own LED indicating last time pushed button. But this way I can only see position and not what flight mode is behind this position. If I have display with all configured flight modes on TX that is initialized straight from FC via BT/WiFi at the starting of FC I’m happy with it.
Do you want an extra radio link just for this simple and steady information or do you have a telemetrie radio already where you can get the information from?
Did you change your RC TX between drones while they in the air?
I think what the OP wants is simple, but the way he explains it and what he’s doing seems incredibly complicated.
For example, I have 30 existing vehicles, cars, quadcopters, and planes, and I’m using one TX, so? I just need to change the MODEL of the TX (OpenTX) and everything the OP needs is achieved. I don’t understand why what he’s doing seems so complicated.
Seems he wants a display that shows the Flight modes configured for the switch or button positions on the Transmitter. Like a switch/button map. What Transmiter?
>Seems he wants a display that shows the Flight modes configured for the switch or button positions on the Transmitter. Like a switch/button map. What Transmiter?
That’s the point. Sorry for being so obscure. I have Taranis X9D 2019 with OpenTX, but how can I display telemetry (particularly all six Flight modes) on it? RC line is not from FrSky. It is old but reliable EzUhf with not telemetry option.
I usually ignore the Flight Mode Screen (in EdgeTx) but perhaps if you configured that for every model you could call those settings in the Script. But totally guessing here, never tried that.
Like @korakora I have many models; Planes, Multirotors, Rovers and it just has not been an issue knowing what button or switch to flip.
A very simple transmitter based Lua script that detects the model and displays some user-defined text would work. If current mode number is contained in the telemetry stream, such a script could also self-populate upon first selection of any given mode and then retain the text for the duration of runtime.
I’m not sure this is a simple problem to solve in a more automated way, as polling parameters via standard RC telemetry is not likely straightforward (or maybe not even possible, but this is not my area of expertise).
Yes, there is little interest , I did preliminary work on MAVLink over CRSF for ELRS with primitive router (only prevents byte level interleaving) on ELRS side and Lua that parses MAVLink packets. Sadly got too busy at uni and science club to continue.
.
, I did preliminary work on MAVLink over CRSF for ELRS with primitive router (only prevents byte level interleaving) on ELRS side and Lua that parses MAVLink packets. Sadly got too busy at uni and science club to continue.