Crsf sensors

[stubugs]

Hi not all sensors show up from flight controller missing gps Sat's alt etc only pitch roll and yaw from fc

[bsongis-frsky]

Please give the list of missing sensors, I think we miss: 1) the GPS sensor (6 values) 2) the Flight Mode

[mgsanna]

do you have already a crsf Lua script?

[Target0815]

Full list of CRSF sensors (Crossfire with Arduplane FC):

1RSS 2RSS RQly RSNR ANT RFMD TPWR TRSS TQly TSNR FM Ptch Roll Yaw GPS GSpd Hdg Alt Sats RxBt Curr Capa Bat_ VSpd

For explanation see Crossfire manual / page 56: https://www.team-blacksheep.com/tbs-crossfire-manual.pdf

[mawzthefinn]

This affects ELRS too.

I'm not seeing Alt, VSPd or Bat_ from my MatekSys ELRS-24-V running ELRS 3.0 (module is Happymodel ES24TX Slim Pro)

[Target0815]

Yes, maintaining telemetry lists is a thankless task ...

It would be easier if the telemetry data are output with internal ID. A stored list or a LUA script (similar to the configuration of the protocols in the multimodule) then allows an assignment internal ID / telemetry value.

This list / LUA script must be public, so that everyone, e.g. the ELRS team, the FC teams, etc. can maintain the list. This would probably save VERY much work for Frsky or Bertrand ... and users would always have up-to-date telemetry data.

[Target0815]

For example, I meant the following in a LUA script ("telemetry.lua") for a external module:

system.registerTelemetrySensor("VSpd", {PhyID = 0x30, unit="m/s", options={ options for this sensor})

Each sensor is defined this way and the list is read in during the sensor search. New entries can be added by anyone. The only effort is to document the function system.registerTelemetrySensor().

[bsongis-frsky]

@Target0815 It makes sense, but details are complex. For security reasons we don't run a Lua script in the Mixer task, and telemetry is received there.

[bsongis-frsky]

For basic sensors (90%) it would work, but for complex ones, a descriptive protocol is not easy to implement. For example how would you implement a GPS sensor?

[Target0815]

Similar to how DIY sensors can now be created and stored internally, a LUA script could be processed during the sensor search (and only there!). In principle, it is now also so that with the sensor search the sensors are entered internally in a table and this table is then used in the mixer etc..

I see therefore no security problem. You have to IMHO get away from firmware updates to enter new sensors. That is a lot of work for the developers and means long waiting times for the users.

I don't know the internals of how a GPS sensor is currently created. But in the end it only provides a few parameters like Lat, Lon, Date, Time, Height etc.. With the sensor search these are then stored and used. There will also be used something similar to my example system.registerTelemetrySensor(). So you could also outsource that.

[bsongis-frsky]

Yes this is exactly what I call a descriptive protocol. But if you look at the details (take the altimeter for example, with a special float precision) and you will see there is more work than you think.

[Target0815]

Of course, I can't estimate the effort without knowing the internals. I just think that you currently have to manually store the telemetry configuration for each external module for each sensor. If this would be changed, you have 1x a more work and then the interested parties maintain the telemetry configuration ... ;-).

[bsongis-frsky]

As an example, here is the code for the barometer sensor conversion beween the data received and the real altitude in centimeters.

int32_t baroAltConversion(int32_t value)
{
  if (value & 0x8000) {
    // Altitude in meters
    value &= ~(0x8000);
    value *= 100; // cm
  }
  else {
    // Altitude in decimeters + 10000dm
    value -= 10000;
    value *= 10;
  }
  return value;
}

It's not just a value to retrieve from the bitstream...

[Target0815]

Is this conversion identical for every barometer?

Normally you have sensors that provide only one value, for example Alt. Then sensors like the barometer, where a conversion is necessary depending on the altitude. Or GPS sensors, which deliver several values.

Here I could imagine, that the function system.registerTelemetrySensor() is to be given the type of the sensor (single value, type barometer, gps, ...), which then internally determines, how to proceed with the data. If now for these sensor types in each case a routine is written around the data internally to prepare.

Precondition is of course that barometer always delivers the same/similar data, no matter if the barometer data comes from FrSky sensor via S.Port or is delivered by a FC via CRSF.

I think I have to play a little bit with a logic analyzer ... ;-).

[r1000ru]

All tests on X20+ HM ES24TX Slim PRO (ELRS 3.0.0). Receivers: HM EP2, Matek RX24D (anthena switch diversity)

0x02 GPS (size 15) Dont work signed latitude:32; // degrees / 10000000 signed longitude:32; // degree / 10000000 unsigned speed:16; // km/h / 10 unsigned heading:16; // degree / 100 unsigned altitude:16; // m - 1000 unsigned satellites:8; // number

0x07 Vario (size 2) (Not tested) signed vspeed:16; m/s / 100

0x08 Battery sensor (size 8) (Dont work) unsigned voltage: 16; // mv 100 unsigned current: 16; // ma 100 unsigned capacity: 24; // mah unsigned remaining: 8; // %

0x08 Baro Altitude (size 2) (Not tested) unsigned altitude:16; // sm = altitude > 0xB000 ? (altitude - 0xB000) 100 : altitude 10;

0x14 Link Statistics (size 10) (Bugs) unsigned rx_rssi_1:8; // dbm -1 DONT WORK unsigned rx_rssi_2:8; // dbm -1 DONT WORK unsigned rx_link_quality:8; // % signed rx_snr:8; // db unsigned active_antenna:8; // enum DONT WORK unsigned rf_mode:8; // enum unsigned tx_power:8; // enum unsigned tx_rssi:8; // dbm * -1 unsigned tx_link_quality:8; // % signed tx_snr:8; // db

0x1E Attitude (size 6) (OK) unsigned pitch:16; // rad / 10000 unsigned roll:16; // rad / 10000 unsigned yaw:16; // rad / 10000

0x21 Flight Mode (Dont work) unsigned ch[N]; //ascii chars (<=16, must see frame size)

[stubugs]

Hi 141 most crsf sensors now present except barometer Alt sensor is this something I could add manually Great work by the way 👏

[Target0815]

Yes, looks good ...

However, I have no values for Rx RSSI1, but probably for Rx RSSI2. Since the receiver HM EP1 has only one antenna, actually Rx RSSI1 should be displayed.

Then it would be much more convenient if the GPS position is displayed as a decimal number instead of in degrees minutes etc..

TxPower always shows only 10 mW, even if the HM ES24TX is configured from 10 mW to 25 mW. I think this is a confusion with Tlm Power from HM EP1, which can only 10 mW and is also displayed so in its configuration.

[stubugs]

Hi just been checking out crsf telemetry but unfortunately I cannot edit units Ie k/mph to mph or meters to feet etc Cheers stu

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[bsongis-frsky]

Everything works correctly now, right?

[Target0815]

Everything works correctly now, right?

I would like to wait for 1.4.4 and then do a comparison CRSF, ELRS and S.Port Passthrough.

[bsongis-frsky]

Please reopen if needed, I think all sensors are there now.

[stubugs]

Hi updated crsf lua and x20 but still no alt only gps alt and after a while gps speed stops everything else keeps working