Check that crsf is enabled in the yaapu config, check that you have serial prot on 23, rc options including 256 rssi type 3 and if all else fails create a new model from default settings and just set up the telemetry page and enable crsf in yaapu config again (its per model)
And wiring from rx to fc has to be a normal serial tx and rx on crsf (23-rcin) nothing sbus or anything else
Hi Alex@Yaapu
I installed the latest version of the yaapu telemetry plugin today. This telemetry script is really great. The previous version of the telemetry plugin worked very well on EDGE TX, but the latest version seems to have some issues. The height display on the HUB has shifted, and the information return time on the second page does not work, there is no change. I am not sure if there is a problem with my settings.Does anybody know a solution? Thanks in advance!
The radio is JUMPER T16 plus TBS Crossfire TX lite.
Edge TX versions are EdgeTX “Flying Dutchman” v2.8.2 and v2.8.3.
Yaapu Telemetry Script is FrskyTelemetryScript-OTX-ETX_Color-LCD_ver_2.0.0_beta3.
Horuse 2.0.0beta3 scripts run in Edge TX 2.8.2 and 2.8.3 environments with digital drift and no change in time.
However, Yaapu Horuse 2.0.0-baat2 does not have a number drift, but the time of the second page is still unchanged.
Can the now red colored error messages possibly be displayed in yellow? Outdoor red is often very difficult to read (Tandem X18S).
Your script is so to speak standard, if one uses a ArduPlane FC in connection with FrSky, ELRS or Crossfire. In my case I would like to use ELRS or also Crossfire as Relay-TX. Of course your script should also run. Do you see a possibility how to implement this?
@yaapu hello! Did Ethos developers contact you?
The script does not work on TWIN X LITE and others ethos TX’s from external modules (R9M Lite pro for example). The internal module works fine with the script (both TW and X modes). Coordinates from FC are coming. But all other sensors are not visible.
is there any way to get it working with external module? seems like there is some data coming over sbus, when i try to “create diy sensor” and run autodetection i get same sensor adresses as described here Frsky Passthrough Protocol - Google Sheets.
switching SERIAL1_PROTOCOL to 4 i get almost all possible sensors.
The shifted height I’ll have to look into it, I don’t recall receiving any reports, the time column in the messages tab refers to the flight time, not to the actual clock time