An Open Source Frsky Telemetry Script for the Horus X10,X12 and Taranis X9D,X9E and QX7 radios

yaapu · April 27, 2019, 1:29pm

Hi all,
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

Notes

Widget does not require the blue theme anymore
To setup the widget please follow the documentation on github

Layout changes

There are 2 user selectable layouts, the new one (default)

screenshot_x10_19-04-27_15-16-08

and the legacy one,

screenshot_x10_19-04-27_15-08-03

selection is made with the config menu

Message history is now colored

screenshot_x10_19-04-27_15-10-59

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

screenshot_x10_19-04-27_15-08-24

screenshot_x10_19-04-27_15-06-06

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

Support for @Eric_Stockenstrom “Plus” firmware,

By using Eric’s Plus version the teensy adds some extra info to the passthrough protocol:

waypoints
airspeed
throttle

In order to display this additional info a custom left panel has to be enabled in the script conf menu

screenshot_x10_19-04-27_15-23-47

screenshot_x10_19-04-27_15-24-15

Support for new battery configurations: serial and independent

independent dual batteries with cellcount override for 1st and 2nd battery (select “other” in batt config menu)
batteries with voltage higer than 51.1V (requires to select 12s override in config menu)
chained FLVSS as serial battery config (select “ser” in batt config menu)

…and

voice playback of selected mavlink messages
fix to skip flight mode vocal announcement for very quick flight mode changes, like flipping a switch from pos 1 to pos 3
haptic feedback, has to be enabled from the menu
more options to silence the incoming message beep
support for PX4 flight modes when used with Eric’s mavlinkToPassthru firmware (has to enabled from the config menu)

as always feedback is very welcome,

cheers,

Alex

Cipta · April 27, 2019, 3:30pm

Hello Alex,
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

yaapu · April 28, 2019, 9:15am

Thanks Roland, really glad it worked all right!

Alex

Anthony_Short · May 1, 2019, 9:09pm

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.

yaapu · May 1, 2019, 9:52pm

Hi Anthony,
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.

github.com

ArduPilot/ardupilot/blob/master/libraries/AP_Frsky_Telem/AP_Frsky_Telem.cpp#L504


      
          /*
          
             Inspired by work done here
             https://github.com/PX4/Firmware/tree/master/src/drivers/frsky_telemetry from Stefan Rado <px4@sradonia.net>
             https://github.com/opentx/opentx/tree/2.3/radio/src/telemetry from the OpenTX team
          
             This program is free software: you can redistribute it and/or modify
             it under the terms of the GNU General Public License as published by
             the Free Software Foundation, either version 3 of the License, or
             (at your option) any later version.
          
             This program is distributed in the hope that it will be useful,
             but WITHOUT ANY WARRANTY; without even the implied warranty of
             MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
             GNU General Public License for more details.
          
             You should have received a copy of the GNU General Public License
             along with this program.  If not, see <http://www.gnu.org/licenses/>.
          */
          
          /* 
             FRSKY Telemetry library
          */
          
          #include "AP_Frsky_config.h"
          
          #if AP_FRSKY_TELEM_ENABLED
          
          #include "AP_Frsky_Telem.h"
          #include "AP_Frsky_Parameters.h"
          
          #include <AP_SerialManager/AP_SerialManager.h>
          
          #include <AP_Vehicle/AP_Vehicle.h>
          
          #include "AP_Frsky_D.h"
          #include "AP_Frsky_SPort.h"
          #include "AP_Frsky_SPort_Passthrough.h"
          
          extern const AP_HAL::HAL& hal;
          
          AP_Frsky_Telem *AP_Frsky_Telem::singleton;
          
          AP_Frsky_Telem::AP_Frsky_Telem()
          {
              singleton = this;
          #if HAL_WITH_FRSKY_TELEM_BIDIRECTIONAL
              _frsky_parameters = &AP::vehicle()->frsky_parameters;
          #endif //HAL_WITH_FRSKY_TELEM_BIDIRECTIONAL
          }
          
          
          AP_Frsky_Telem::~AP_Frsky_Telem(void)
          {
              singleton = nullptr;
          }
          
          /*
           * init - perform required initialisation
           */
          bool AP_Frsky_Telem::init(bool use_external_data)
          {
              const AP_SerialManager &serial_manager = AP::serialmanager();
          
              // check for protocol configured for a serial port - only the first serial port with one of these protocols will then run (cannot have FrSky on multiple serial ports)
              AP_HAL::UARTDriver *port;
              if ((port = serial_manager.find_serial(AP_SerialManager::SerialProtocol_FrSky_D, 0))) {
          #if AP_FRSKY_D_TELEM_ENABLED
                  _backend = new AP_Frsky_D(port);
          #endif
              } else if ((port = serial_manager.find_serial(AP_SerialManager::SerialProtocol_FrSky_SPort, 0))) {
          #if AP_FRSKY_SPORT_TELEM_ENABLED
                  _backend = new AP_Frsky_SPort(port);
          #endif
              } else if (use_external_data || (port = serial_manager.find_serial(AP_SerialManager::SerialProtocol_FrSky_SPort_Passthrough, 0))) {
          #if AP_FRSKY_SPORT_PASSTHROUGH_ENABLED
                  _backend = new AP_Frsky_SPort_Passthrough(port, use_external_data, _frsky_parameters);
          #endif
              }
          
              if (_backend == nullptr) {
                  return false;
              }
          
              if (!_backend->init()) {
                  delete _backend;
                  _backend = nullptr;
                  return false;
              }
          
              return true;
          }
          
          bool AP_Frsky_Telem::_get_telem_data(AP_Frsky_Backend::sport_packet_t* packet_array, uint8_t &packet_count, const uint8_t max_size)
          {
              if (_backend == nullptr) {
                  return false;
              }
              if (packet_array == nullptr) {
                  return false;
              }
              return _backend->get_telem_data(packet_array, packet_count, max_size);
          }
          
          #if HAL_WITH_FRSKY_TELEM_BIDIRECTIONAL
          bool AP_Frsky_Telem::_set_telem_data(uint8_t frame, uint16_t appid, uint32_t data)
          {
              if (_backend == nullptr) {
                  return false;
              }
              return _backend->set_telem_data(frame, appid, data);
          }
          #endif
          
          void AP_Frsky_Telem::try_create_singleton_for_external_data()
          {
              // try to allocate an AP_Frsky_Telem object only if we are disarmed
              if (!singleton && !hal.util->get_soft_armed()) {
                  new AP_Frsky_Telem();
                  // initialize the passthrough scheduler
                  if (singleton) {
                      singleton->init(true);
                  }
              }
          }
          
          /*
            fetch Sport data for an external transport, such as FPort
           */
          bool AP_Frsky_Telem::get_telem_data(AP_Frsky_Backend::sport_packet_t* packet_array, uint8_t &packet_count, const uint8_t max_size)
          {
              try_create_singleton_for_external_data();
              if (singleton == nullptr) {
                  return false;
              }
              return singleton->_get_telem_data(packet_array, packet_count, max_size);
          }
          
          #if HAL_WITH_FRSKY_TELEM_BIDIRECTIONAL
          /*
            allow external transports (e.g. FPort), to supply telemetry data
           */
          bool AP_Frsky_Telem::set_telem_data(const uint8_t frame, const uint16_t appid, const uint32_t data)
          {
              try_create_singleton_for_external_data();
              if (singleton == nullptr) {
                  return false;
              }
              return singleton->_set_telem_data(frame, appid, data);
          }
          #endif
          
          namespace AP
          {
          AP_Frsky_Telem *frsky_telem()
          {
              return AP_Frsky_Telem::get_singleton();
          }
          };
          
          #endif  // AP_FRSKY_TELEM_ENABLED

This file has been truncated. show original

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?

github.com/ArduPilot/ardupilot

Arducopter 3.6 Issue: Prearm failure GPS

opened 04:09PM - 28 Oct 18 UTC

closed 11:53PM - 29 Oct 18 UTC

mtbsteve

### Bug report **Issue details** As soon as the number of sats locked increa…ses beyond somewhere 20-22 sats with my UBLOX m8n, I get a "Prearm GPS not healthy" message in my GCS and can't arm. It continues to flicker on and off within seconds. When the error disappears for a split second and I then press the arming switch fast enough, I can fly w/o problems. As long as the sat count is lower, the prearm check is passed. _Please describe the problem_ It must be a problem with AC 3.6, since it was working fine all the time in 3.5 and earlier. With my m8n GPS, I usually receive between 22 and 28 sats at HDOP down to 0.47 and never had any issues with Arducopter 3.3, 3.4, 3.5 in the same setup and parameter settings. My other copter with an UBLOX m8p RTK chip runs fine with AC3.6 (however the m8p never exceeds 18 sats) **Version** _What version was the issue encountered with_ Arducopter 3.6.0 **Platform** [ ] All [ ] AntennaTracker [X] Copter [ ] Plane [ ] Rover [ ] Submarine **Airframe type** _What type of airframe (flying wing, glider, hex, Y6, octa etc)_ Quad **Hardware type** _What autopilot hardware was used? (Pixhawk, Cube, Pixracer, Navio2, etc)_ Pixhawk 2, Drotek m8n GPS **Logs** _Please provide a link to any relevant logs that show the issue_ https://1drv.ms/u/s!AnKeW8KMoCcymAWipx8Cj3CaFZO6

Anthony_Short · May 2, 2019, 2:19am

Thank you - that’s exactly what’s happening. And I thought more satellites was always better. Obviously not in this case.

JoeBreznai · May 5, 2019, 10:00am

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).

Thanks,
Joe

yaapu · May 6, 2019, 8:05am

Hi Joe,
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:

X series on 2.4Ghz by binding in D16 mode (no extra module, range figure 1.5Km)
R9 series on the 900/868Mhz, you get different s.port telemetry options based on the firmware type and selected power output (up to 1000mW) (requires extra module, range figure 10Km)

The s.port on the receiver is wired to the flight controller, in many ways:

with a dedicated inverter/level converter cable such as this, most boards need this cable
with a direct connection on Pixracers, the cable has tx and rx on the pixracer side shortened
with a direct connection on selected F4/F7 boards like Kakute AIO (latest ardupilot dev versions adds support for boards with hardware inversion and/or single wire serial)

hope this helps to put you on the right track

Note: I found this comparison table that might help

Alex

JoeBreznai · May 6, 2019, 12:59pm

Alex,
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.
Joe

yaapu · May 6, 2019, 4:01pm

You’re welcome Joe, and thanks for the kind words, hard work without sharing is only half fun

hurzburg · May 16, 2019, 12:35pm

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?

yaapu · May 16, 2019, 1:14pm

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.

yaapu · May 16, 2019, 1:52pm

Henry, I sent you a very light script that just counts the incoming packets

hurzburg · May 16, 2019, 3:15pm

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

yaapu · May 16, 2019, 3:39pm

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

hurzburg · May 16, 2019, 3:41pm

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

yaapu · May 16, 2019, 3:47pm

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

hurzburg · May 16, 2019, 3:53pm

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

yaapu · May 16, 2019, 4:01pm

Can you test it on a new model created from scratch?

hurzburg · May 16, 2019, 4:10pm

worked on a new model…guess, something in some of the models got corrupted? not sure how that happened,since the ones not working haven’t had anything changed in them in months (except that I did upgrade to 2.2 from 2.1, moved to 1.7.2 LUA)

Guess I will check all my planes and just recreate new models for the ones with an issue (two out of 5 at this point)