Native Frsky Telemetry discussion

Hi,
In 3.2 we now have frsky telemetry support through the SERIAL2 Port.
copter.ardupilot.com/wiki/common … telemetry/
Current metrics :
github.com/diydrones/ardupilot/pull/1266

I would like to gather some feedback about what people want to see as metrics (SATS, HDOP, GPS ,…)
So … feel free to comment on this thread, the result of your testing and requests for more functionality.

Support for X-Receiver (S-PORT) is in the work but won’t make it for 3.2 official.
We are in discussion with opentx people to have more metrics in opentx adapted to our needs as currently we are hacking Temperature telemetry and other metrics to meet our needs.
M

NB: This is native support using an inverter, it is different to the teensy solution below which is more advance in term of functionality : diydrones.com/forum/topics/amp-t … -converter

GPS coordinates are showing strangely on FrSky FLD-01 display and within ER9X telemetry screens on the Turnigy 9X.

For instance, at -37.717520, 144.931725
Frsky telemetry reports E 14455.9042, S 3743.0512

This would appear to be a slightly awkward representation of degrees and decimal minutes. These devices expect the format to be coded in decimal degrees. What format does it display on a Taranis?

Here is a snippet of the code used to get FrSky GPS telemetry on these devices using a similar Native Frsky Telemetry system on my now retired MPNG controller.

  uint16_t Datas_Longitude_bp;
  uint16_t Datas_Longitude_ap;
  uint16_t Datas_E_W;
  uint16_t Datas_Latitude_bp;
  uint16_t Datas_Latitude_ap;
  uint16_t Datas_N_S;
  float lat = g_gps->latitude / 10000000.0f;
  float lon = g_gps->longitude / 10000000.0f;
  Datas_E_W = lon < 0 ? 'W' : 'E';
  Datas_N_S = lat < 0 ? 'S' : 'N';
  lon = fabs(lon);
  lat = fabs(lat);
  Datas_Longitude_bp = lon;
  Datas_Longitude_ap = (lon-int(lon))*10000;
  Datas_Latitude_bp = lat;
  Datas_Latitude_ap = (lat-int(lat))*10000;

  sendDataHead(ID_Longitude_bp);
  write_FrSky16(Datas_Longitude_bp);
  sendDataHead(ID_Longitude_ap);
  write_FrSky16(Datas_Longitude_ap);
  sendDataHead(ID_E_W);
  write_FrSky16(Datas_E_W);
  sendDataHead(ID_Latitude_bp);
  write_FrSky16(Datas_Latitude_bp);
  sendDataHead(ID_Latitude_ap);
  write_FrSky16(Datas_Latitude_ap);
  sendDataHead(ID_N_S);
  write_FrSky16(Datas_N_S);

Hope this is of some help.

The other metrics work great, I really like the flight mode and GPS status, best reuse of the Temp fields. Looking forward to new metrics being added :slight_smile:

Cheers,
Nick

Check what is currently being received at this project github.com/lvale/MavLink_FrSkySPort as a starting point on data received via telemetry.

When OpenTX releases the refactored telemetry data github.com/opentx/opentx/tree/b … efactoring

things will change, but nothing substantial, i.e. there will be no need to hack data to “fit” in the current telemetry structure.

Although it might not be clear from the github project, all the current messages that are relayed to the GCS are being parsed and sent on the Taranis telemetry stream.

example:

PreArm, RC not calibrated
PreArm, barometer not healthy
PreArm, Alt disparity
PreArm, Compass not healthy
PreArm, Compass not calibrated

etc

to the last one added this week

DCM bad heading

Thanks. You are reffering to the teensy solution. None of these messages are sent by the native APM solution yet.

I can’t see much more “useful” telemetry data being sent down, perhaps some more details on autonomous navigation, which are a “challenge” to decode by parsing the Mavlink output.

Whoops, my display is actually an FLD-02.

Additional metrics I would like to see:

Armed Timer:

  • The timer resets and starts upon arming using ID_Hour_Minute. Stops and holds value when disarmed. Purpose is twofold: shows and holds last flight time, and arming check (is timer reset and rolling?). This will complete the FLD-02’s Screen 1.

RPM:

  • Waypoint number in ID_RPM. Doubled perhaps to allow users to keep Num_Blades on default 2. This completes screen 2.

Volt:

  • Perhaps synthesize an ID_Volt message by dividing the battery voltage by the number of cells. The FLD-02 does not show VFAS so this is the only way to display total battery voltage without extra hardware on A1 or A2. This will give me screen 3.

Acc:

  • The accelerometers might be nice if there’s bandwidth left. This will complete Screen 4.

Wit the addition of the above all fields on the FLD-02 will then be implemented, and all messages except ID_DateMonth and ID_Year. This should be everything d-port users need.

Cheers,
Nick

Hi, bringing this over from our conversation on diyd: currently I send hdop as fuel (modified Rolf’s original script) , it is simple and in any case taranis itself is able to calculate total mah used. T2 is my flight mode, T1 is number of GPS sats. For everything else I have a tablet + OSD. I think we can lighten pixhaw as possible so Rx Vcc, Batt Vcc, Current consumption, GPS hdop, # of sats, coordinates, flight mode, Baro Alt, and RSSI from mavlink to be used with nonfrsky Rx-es such as openlrsNG in hub telemetry mode (it doesn’t send RSSI). That’s all we really need.

Could the accelerometer fields be used to show a running average or peak function of the accelerometer? If displayed in APM units this could allow vibration levels to be checked directly and easily.

Something like this could be handy to notify of loose screws, rattles, crash damage and propeller/motor problems in-field.

[quote=“prickle”]GPS coordinates are showing strangely on FrSky FLD-01 display and within ER9X telemetry screens on the Turnigy 9X.

For instance, at -37.717520, 144.931725
Frsky telemetry reports E 14455.9042, S 3743.0512

This would appear to be a slightly awkward representation of degrees and decimal minutes. These devices expect the format to be coded in decimal degrees. What format does it display on a Taranis?

Here is a snippet of the code used to get FrSky GPS telemetry on these devices using a similar Native Frsky Telemetry system on my now retired MPNG controller.

  uint16_t Datas_Longitude_bp;
  uint16_t Datas_Longitude_ap;
  uint16_t Datas_E_W;
  uint16_t Datas_Latitude_bp;
  uint16_t Datas_Latitude_ap;
  uint16_t Datas_N_S;
  float lat = g_gps->latitude / 10000000.0f;
  float lon = g_gps->longitude / 10000000.0f;
  Datas_E_W = lon < 0 ? 'W' : 'E';
  Datas_N_S = lat < 0 ? 'S' : 'N';
  lon = fabs(lon);
  lat = fabs(lat);
  Datas_Longitude_bp = lon;
  Datas_Longitude_ap = (lon-int(lon))*10000;
  Datas_Latitude_bp = lat;
  Datas_Latitude_ap = (lat-int(lat))*10000;

  sendDataHead(ID_Longitude_bp);
  write_FrSky16(Datas_Longitude_bp);
  sendDataHead(ID_Longitude_ap);
  write_FrSky16(Datas_Longitude_ap);
  sendDataHead(ID_E_W);
  write_FrSky16(Datas_E_W);
  sendDataHead(ID_Latitude_bp);
  write_FrSky16(Datas_Latitude_bp);
  sendDataHead(ID_Latitude_ap);
  write_FrSky16(Datas_Latitude_ap);
  sendDataHead(ID_N_S);
  write_FrSky16(Datas_N_S);

Hope this is of some help.

The other metrics work great, I really like the flight mode and GPS status, best reuse of the Temp fields. Looking forward to new metrics being added :slight_smile:

Cheers,
Nick[/quote]

Hi Prickle,
It looks strange that gps does not work.
Anybody having the same issue with a taranis ? It might be specific to the FLD-02 and ER9X. The protocol might be different.
I can try to have a parameter for this type of FRSKY Telemetry client to avoid breaking the opentx Taranis.
M

[quote=“prickle”]Whoops, my display is actually an FLD-02.

Additional metrics I would like to see:

Armed Timer:

  • The timer resets and starts upon arming using ID_Hour_Minute. Stops and holds value when disarmed. Purpose is twofold: shows and holds last flight time, and arming check (is timer reset and rolling?). This will complete the FLD-02’s Screen 1.
    [/quote]
    Huh … how do timer works on the FLD-02 ? can’t you program them based on a metric ?

Ok, I will look into this.

OK

I am not a big fan of accel data as it is a lot of noise and filtering is not something I would like to implement on the pixhawk.
Moreover, the more data we put, the less refresh time we will get for the other metrics. The bandwidth is limited and there are trade off to be made.

[quote]
Wit the addition of the above all fields on the FLD-02 will then be implemented, and all messages except ID_DateMonth and ID_Year. This should be everything d-port users need.

Cheers,
Nick[/quote]

Can you send some current screenshot of the FLD screen for me to have an idea of the final results .
Thx

Hi badzz.

This is the main screen, screen 1. The timer in the top left corner just mirrors what is sent in the ID_Hour_Minute and ID_Second messages. I think Frsky hub uses it for TOD, MPNG starts counting from zero to give time since plugging in.

The FLD-02 has limited alarms based on the A1 and A2 voltages. No internal timers are available. More info.

I happily accept what you are saying about the accelerometers and I see them gone without the slightest regret. I personally found them of dubious value anyway.

However, I do think the FLD-02 is expecting the regular GPS format and opentx has either chosen to use a different format or has lost sync with the “official” format along the way. The FLD-02 is a genuine Frsky decoder and seems unlikely to be wildly incorrect. Never mind, if it is too late to change or if it was for valid reasons then a format selection system would be perfectly fine.

Here are examples of what is currently shown:
Screen 1:

Timer stays on 00:00:00, everything else (fuel, A1, A2, Temp1, Temp2, RXRSSI, TXRSSI) all working correctly.
I am plugged in through USB to a wall wart at the moment, you can see my 5v rail is slumping quite badly. Cheap DC adapters…

Screen 2:

RPM stays on 0, everything else (alt, speed, amps, Ah) working.

Screen three not yet available :slight_smile:

Screen 4:

Accelerometers zero, GPS as shown.

And on ER9X:

Is there a concern about the overhead of processing all these metrics on the Pixhawk? Perhaps a set of feature selection flags would help.

I reckon this is a wonderful feature and I’m chuffed it’s working so well as it is. I love that you’re pushing to make the most of what I’ve got. You guys are awesome.

Cheers,
Nick

HDOP is something i would like to see, number of sats is good but hdop is more important imo

I have a Taranis X9D with Pixhawk 3.2 rc14 and am really missing GPS telemetry - all I get is
Latitude —
Longitude —
Other parameters transfer OK.

Taranis firmware is opentx-x9d-v1.1.02 dated 2013-10-18

Would be really nice to get this to work, using decimal coordinates, or even any at all, but I don’t know what to tweak yet.

Anyone managed to do this yet?