I have Yaapu telemetry working on my TX16S AND MAVLink to the Mission Planner on the laptop. I’ll share my setup info in case this helps someone else.
Matek F405-Std
Arducopter 4.1.0.dev
OpenTX2.3.11
Crossfire 4.10 beta on Micro TX V2 and RX Nano.
The laptop is connected directly to the Micro TX WiFi access point. I am not using a hotspot or any extra hardware. I’m hoping this will make it practical in the field. Yes, you need to restart the MAVLink UDP on each startup.
I’m using the 2 UART method described by @jimenezlee
Channel 1&2 on the RX are connected to TX/RX 4/Serial2 on the FC using CRSF. (I had started with this on TX/RX3, but the telemetry didn’t work so I moved to 4 and seems to work)
Channel 3&4 on the RX are connected to TX/RX 3/Serial1 on the FC using MAVLink.
I’ve tried both SERIAL1_PROTOCOL = 1 and now I’ve got it 2 (MAVLink 2).
I’ve only noticed one issue: The parameter loading on the GCS takes a long time. On Mavlink 1 it took about 25 minutes to load the parameters. I just tried with Mavlink2 and it was considerably less at about 8 minutes. Once the parameters are loaded things move along quick enough. There is some latency (it’s not an RFD900 link…) but it’s totally useable.
Any suggestions to improve the parameter loading time?
So while 4.1 loaded I would like to try Yaapu pass through CRSF telemetry.
uart2/ serial 3 set to rcin, rx crsf all working basic opentx telemetry and RC control. opentx FM sensor is showing qstab which is mode on discovery and does not change( not armed yet)
messages I think debug
07/02/2021 16:27:22 : CRSF: RF mode 2, rate is 186Hz
07/02/2021 16:27:17 : CRSF: RF mode 1, rate is 179Hz
07/02/2021 16:26:58 : CRSF: RF mode 2, rate is 183Hz
07/02/2021 16:26:53 : CRSF: RF mode 1, rate is 182Hz
07/02/2021 16:26:38 : CRSF: RF mode 2, rate is 182Hz
07/02/2021 16:26:33 : CRSF: RF mode 1, rate is 185Hz
07/02/2021 16:26:25 : CRSF: RF mode 2, rate is 194Hz
07/02/2021 16:26:20 : CRSF: RF mode 1, rate is 193Hz
07/02/2021 16:26:03 : CRSF: RF mode 2, rate is 175Hz
07/02/2021 16:25:58 : CRSF: RF mode 1, rate is 181Hz
07/02/2021 16:25:53 : CRSF: RF mode 2, rate is 189Hz
and more …
I would expect mode 2 to be much lower ??
Does this commit 164da26 include the Yaapu customized code for pass through crsf. ie setiing rc_options. If not is it safe to fly using the latest 4.1 Yappu customization and what commit is customisation based…
Is it possible to stop above messages, they flood OSD while flying FPV.
Is there a list of Uart/serial that have DMA for Matek H743 Wing
I would expect Mode 2 to be 150 and Mode 1 to b2 50 - it does seem wrong.
That commit includes CRSF passthru.
You can’t turn it off, but then you shouldn’t be getting it every 5s - so seems like something is wrong. Turning it off may not be a bad idea though - we probably should display the rate in the OSD instead.
can also put RSSI RSSI/RQ or RQ on a rc channel in tbs rx channel config. Then pic up with rssi type 3 and RSSI_CHannel set to sane channel as RX config. Then RSSI in OSD shows chosen value.
First flight today
open tx 2.3.11
Yaapu 1.9.3 beta 2
arduplane 4.1 commit [164da26]
Matek H743 wing.
Jumper T16.
The telemetry script stops working occasionally with red disabled message.
While active telemetry is working well.
The messages RF mode etc are much less when flying. I think the overload of messages is indoors when tx and rx are close. Mode constantly changing (RFMD 2 or 1 constantly switching) and low RSSI
How about data throughput with both CRFS and MavLink ? I would guess MavLink will take up big portion of bandwidth, sacrificing Yaapu’s CRSF Passthrough messages rate.
Any suggestions to improve the parameter loading time?
Some connection types are able to use MavFTP to load all parameters in a stream without a need to query every single one. However, for some reason, unknown to me, MavFTP is not used for Crossfire MavLink connection. Maybe @andyp1per will have some knowledge about this?
Personally I would set very low rates for mavlink telemetry and quite high rates for parameters, this to allow for smooth CRSF passthrough telemetry, decent mavlink telemetry which would be a sort of backup and log facility and pretty good parameters download. If telemetry stutters while downloading them is not a big deal IMO, I will probably be on the ground anyway
I have uploaded this log , current when yaapu widget stopped with blank screen and red letters — DISABLED.renamed .plog to _plog.lua to upload. Not sure much in there !!!
I have 5 opentx widget screen active, will close all but yaapu widget and do some flying.
can you access the widget yaapu settings page, it should show you some more info. How did you produce that log? Current beta version should not create debug files, if you’re using a debug version it may very well crash the widget
