Yaapu passthrough telemetry... on elrs/zorro setup, currently not working

I was having this problem on OpenTX. On a RadioMaster 16S with EdgeTX the sensors appear correctly - especially “ARM” which is what I needed.

I am going to delete all the sensors and do the rediscover. On the telemetry screen, I am missing TRSP, RPWR, and TFPS.

So I deleted all the sensors and did a rediscover. That didn’t work.
I changed Telemetry Ratio to 1:2 (2921bps), and its working now.

@yaapu @Allister, packet rate is at 150Hz (-112dBm), and Baudrate is at 400k, should these two values be higher?

telemetry rate should be >= 25Hz, ideally >=50Hz
It depends on your link rate and link to telemetry ratio, check the docs here

1 Like

I’d suggest you also increase the baud rate on the Radio. I set mine to the max it will do. This seems to be a best practice with ELRS.

I got it all working - so here is my video about using Yaapu telemetry to get ExpressLRS arming to work “properly”.

I am replacing an old UAV rx with an ELRS. That UAV is equipped with a KAKUTE F7 AIO (Ardurover V4.3.0), but it is not communicating properly with the YAAPU telemetry. The telemetry indicates “no telemetry”.Control from the radio is working fine.

I suspected the radio and YAAPU settings, but it worked fine when I installed the same ELRS rx on another FC.

I suspected the KAKUTE settings and the RX worked fine when connected to another FC (Matek F405wing or F765 wing) with the same UART settings.

I think the cause is in the KAKUTE, but the cause is not clear to me.
My ELRS system is Jumper T18 with BetaFPV’s TX and Jumper AION-RX-MINI. I need your help.
I’ve attached my FC’s param file.

Thanks,

https://1drv.ms/u/s!AptQrGcuGTl9h4hdoD3_C8tRMMEPPA?e=BE6zih

I think I’ve noticed something with Yaapu suddenly/randomly not working. I think what I’m seeing is that if you modify one of the settings on the “Model” tab in Edge TX, it resets the “Use CRSF” option in Yaapu, so you think “oh I’m sure I set that” and you have to go set it again.
I noticed that this happened when I edited the model settings using Companion, but then I also noticed it happened if I modified one of the timers on the radio without using Companion. What made this stand out was that it was on a model that I had flown several times with Yaapu working fine and then it just stopped working when I fired it up after editing the timer.

Have you seen this @yaapu ?

1 Like

probably the model name changes somehow and therefore you actually get a full reset of the widget configuration

I have noticed something additional about this issue.

I have the same model same settings for the radios and different FCs connected for the RX side. the UART settings for the FCs are the same for all FCs.
My KAKUTE is not able to communicate with the radio and telemetry, while the Matek765/405 wing is able to communicate. Of course YAAPU also works.
In KAKUTE’s case, the radio settings [telemetry] recognized data from rx such as RSSI, but did not receive data from Arudupilot. Therefore, when I check the yapuCRSFdebug in TOOL, there is no communication.
In addition to this, I have connected my Omnibus F4 Pro V3 to the same rx as well and it too is not communicating with Yaapu. But on the other hand, the radio setting [telemetry] is receiving data from Ardupilot, but still the yaapuCRSFdebug in TOOL is not getting any data.

Could this be a clue to what is going on?

Wow - it’s keyed on the NAME? There is no internal id/GUID? Not your fault I guess, but that’s a real gotcha.

yes, it keyed by model name there’s no such thing as model guid, later api versions introduced the concept of model filename but to keep it backward compatible I compute my own filename based on model name

Thank you for highlighting this quote.

Anyone here, how managed to enable CRSF support in the Yaapu telemetry settings on a Radiomaster Pocket?
On the Boxer and the Zorro, the sequence TELE → RTN → TELE brings you into that configuration menu, but on the Pocket, this does’nt work.