testing some minor cosmetic changes:
- extended status bar with last 4 messages
- roll and pitch on the cockpit
- colored message history on black background with telemetry bar on the right
testing some minor cosmetic changes:
this is the first public test version 1.8.0-beta3 for Horus radios
Note 1: OpenTX 2.2.3 is recommended
Note 2: This version requires the luac option checked in OpenTX settings
There are 2 user selectable layouts, the new one (default)
and the legacy one,
selection is made with the config menu
Message history is now colored
Frsky custom sensors support
Just like the Taranis version is possible to display up to 6 “frsky sensors” from those discovered in the radio telemetry screen.
In the example I’m showing individual cell voltages from my FLVSS sensor
Sensors can be defined by editing the per model lua configuration (example included in the /SCRIPTS/YAAPU/CFG folder)
This was designed with gas suite users in mind, it’s possible to define multipliers, labels, warning and critical levels in the conf file.
There’s also the option to define lookup tables, when a sensor value is found in the lookup table the script shows that value instead of the sensor one.
When the script is in “show min/max” mode by short pressing [MENU] the custom sensor panel will show min or max values depending on the “min or max tracking” option defined in the lua configuration file.
@ChrisOlson briefly explains this new feature in his video
By using Eric’s Plus version the teensy adds some extra info to the passthrough protocol:
In order to display this additional info a custom left panel has to be enabled in the script conf menu
Support for new battery configurations: serial and independent
as always feedback is very welcome,
take a big compliment for that work.
Looks great and just have done two flights with different Cube black 3.6.8, CUAV-V3 and the default config - everything works for me.
best wishes and have a nice day
Thanks Roland, really glad it worked all right!
Hi Alex, I’m having a problem with one of my quads where I get occasional “Bad GPS Health” messages on the yappu screen, but there is no message displayed on the OSD (Kakute F7), and nothing in the dataflash log. At the time it occurred the GPS log showed NSats = 21, HDOP = 0.56, and status = 4. Any idea what is happening here? Thank you.
that particular messagge is sent only by the telemetry library, take a look here, it is forged and sent as a text message after checking the healthy bit of your gps.
You’re not seeing it on your OSD because mavlink sends it as a status bit mask not as a text message and OSDs usually ignore it.
Maybe a duplicate of these?
Thank you - that’s exactly what’s happening. And I thought more satellites was always better. Obviously not in this case.
Question about Receivers
Long time Futaba user for some 40+ years- and most of my gear is Futaba FASST with a T8FG Tx. I am looking at all this Open TX stuff and considering buying a new Tx. I an currently flying mostly LOS multi copters with ArduPilot.
Seriously looking at Horus TX but I want some advice on some small Rx(s) that will be suitable for smaller quads with the mavlink ArduPilot telemetry available using this script on that Tx screen. I do want Rx’s with a reasonable range, as I don’t want problems with range if something goes wrong during flight in my back yard( That never happens-right!) I will admit- I am a bit confused on all the FrskyTx/Rx protocol stuff; and think I know some answers from Wiki, but before I pull the trigger and waste money these questions;
What 2.4Ghz Frsky Rx(s) -and compatible -including some really small ones for “micro” quads, work REALLY WELL with no hassles with ArduPilot and this Script.
What Tx protocol do I look for in a Rx, assuming a Horus Tx is used?
Do I need some kind of converter/cable for that Rx to get data from my FC to the Rx? (I have 2.4.8 Pixhawks, Mr0 Pixhawks, Mr0 Pixracers, and a few of the newer Ominibus FC’s running ArduPilot machines).
nice question and a complete answer is quite challenging
I suggest you open a new thread such is the challenge
IMO the features you want are: sbus and s.port telemetry
There are 3 firmware types, FCC, LBT (EU) and Flex.
All FrSky radios have built in support for X series on 2.4Ghz and need an extra module on the back for 868/900Mhz and 2.4Ghz DJT (V8 binding)
You get s.port telemetry on:
The s.port on the receiver is wired to the flight controller, in many ways:
hope this helps to put you on the right track
Note: I found this comparison table that might help
Thank you for the response. You completely answered my questions and the link to the Rx table filled in my understanding of the various Rx protocols and options and limits. ( Note: the link to the eflight Wiki listed in that table appears to be hijacked). Can’t wait until I get a new Open Tx and use your script. I have been following your thread since day one. This script is really the only reason I wanted to get a new Tx.and really appreciate your sharing of all your hard work.
You’re welcome Joe, and thanks for the kind words, hard work without sharing is only half fun
Alex, any idea how to proceed with my issues with some systems using Teensy Mavlink converter working with Taranis and this script, and other not doing so? perhaps a minimally invasive debug version that just checks, yes/no, at a few points in the stream acquisition process?
mhmmm the “lightest” tool I can think off would just count the incoming packets per type and display them on screen, if you see the counters getting higher you’d know passthrough telemetry is working, unfortunately I don’t have such a script ready for you but I’m sure I can make one pretty fast.
But since it’s OpenTX code that decodes the packets from the serial port and pushes them on the lua telemetry queue I doubt that you’d get any insight on what’s going on.
Henry, I sent you a very light script that just counts the incoming packets
Thanks, I ran it…its not your script…its something in Opentx…
on working models, I see the stats increase (albeit slowly…its certainly not every packet…more like every 10th or more…but it does increment), on non-working it never gets off zero…
then I would take a nonworking model and just use a working models, and it worked…so its something to do with model setup in Opentx
you have to run it alone, 2 scripts cannot share the sport lua queue.
btw, we already know the flow starts and stops from your previous dump, if you see it flowing with this minimal version than we’ll try to dump it with another minimal script in the hope that a minimal version is not affected by whatever is sent by your setup
probably the slow increment on working models is the two scripts sharing the queue…they do seem to work in parallel, apparently r
obbing packets from one another
I’m not sure I understood but you can have as many models as you like, all with the same script assigned to one of the telemetry screens, what you cannot have is 2 or more scripts sharing sport queue access on the SAME model
Note: the sport queue can be shared but each packet can be processed by only 1 script so the scripts would steal packets from each other
I added the stats script on screen two of the models…it works, both sharing the queue, one gets some packets, the other gets some…
but I have several model on the TX with the same Yaapu script… all have the same DL RX/TX setup…all get good telem thru DL TX via the BT I have wired in parallel with Teensy (which is one unidirectional)…
on the same FC on the bench, I can switch between models using the DL module on the Taranis…some have the script working and the stats upcounting…some do not…it seems linked to the model configured on the Taranis, not actual plane…I tired enabling the internal RF, thinking that it may be that transfer on Sport pin is somehow linked…no difference
if a copy a model, whether it works or not, follows with the copy
Can you test it on a new model created from scratch?