yes, frsky has quite some lua legacy, the good news is that ethos’ main developer is also the lead developer of opentx.
1 Like
fingers crossed i hope it gets opentx just makes so easy
any way i did some flying to 1.9.3 beta4 look good works like a charm
but i did fined a bug in opentx 2.3.11
the TX went in emergency mode setting up some top menu bar 3 times it did
huh! If you can reliably get it to emergency mode you should really open an issue on opentx github!
yes i can reliably get it to do just did 3 times then
mhmm, you scroll thru all the widgets and probbaly when you should see the yaapu widget telling that it requires full screen it crashes…coulb very well be a bug in my widget!
ok, one easy way to trigger emergency mode is draw text off screen, I bet another widget is trying to draw off screen using the top bar “rectangle” coordinates as origin…
its only on the top bar they all work in a full screen my be right
yes its a widget called Ghost that was included on the last sd card for 2.3.11
1 Like
Hi, I just wanted to say that the new map import from Mission Planner is the bomb! A lot easier procedure than Gmapcatcher. I personally limit max zoom while exporting from MissionPlanner to 18, it is enough for me and download to PC/upload to SD takes reasonably less time. I recommend to clear your MissionPlanner cache before converting with Yaapu’s tool to convert just the areas you really want.
Thank you Alex!
1 Like
Alex, I was wondering if you have seen this issue where the text is being overwritten on a line instead of a newline or carriage return then new line of data. I’m using a Radiomaster TX16, OpenTX 2.3.10, Mav2PT 2.62.7, Arduplane 4.09 and your Horus Widget version 1.9.3 beta3. You can see on line 8 Barometer 1 calibration “compAirsletepeed” then a new correctly formatted line.
mhmm the status text message queue got filled and overflowed, this can also happen on regular frsky telemetry when too many messages arrive exceeding the link capacity
Is there some setting to modify to prevent this? I have my Arduplane SR1 stream rate settings very low already. Or is this a MavlinkToPassthru issue?
Double check your rates, not much I can suggest, perhaps ask the MavToPT author?
Yes - you were right and it was something ATX-Heli also said today to somebody else that had me check QGroundControl. After QGC initialized it reset the stream rates. By telling QGC to not alter my stream rates this fixed the problem. Thanks,
1 Like
Unfortunately I don’t have a Pixhawk or ArduPilot. Wanted to ask if yaapu script, adapter will also work with DJI Naza V2? I bought FrSky X12S and wanted to have the telemetry data from DJI Naza V2. I saw an adapter like this on Aliexpress (enter FRSKY Yaapu on Aliexpress). Has anyone tried FRSKY Yaapu Converter with DJI Naza V2?
Hi Everyone, wonderful work @yaapu!
I am currently facing problems recieving passthrough telemetry via F.Port (1) while RC-commands from the transmitter are beeing processed smoothly.
I tested two recievers (Archer RS, ACCESS, different firmware-versions) on three boards (Plane 4.1.0). Both recievers behaved the same:
- Pix32 v5: all good, telemetry&yapuu perform flawlessly
- CUAV v5+: RC ok, telemetry not working
- Cube Orange: RC ok, telemetry not working
Afterwards, telemetry was tested with S.Port and S.Port “inverted” (PROTOCOL 10, both RC_OPTIONS 0/8 tested, SERIALx_OPTIONS adequate), but was not working on the CUAV and the Cube Orange. The pulldown-hack on normal S.Port as suggested by @iampete/@yak-54 didn’t help.
Might the problem come from the txs0108e (it seems as this chip is not used in the Pix32 v5)?
I am quite frustrated since I don’t have any clue of how to proceed debugging - what would you suggest?
Hi Konrad,
not sure what your issue is but it does not look to be ArduPilot related, just tested ArduPlane V4.1.0dev (22c93614) on my CubeOrange and following setups all worked fine:
- ACCST v1.x X4R on SPort, 4kOhm pulldown on TELEM2 TX pin, SERIAL2_PROTOCOL=10, SERIAL2_OPTIONS=7
- ACCST v1.x R-XSR on FPort, 4kOhm pulldown TELEM2 TX pin, SERIAL2_PROTOCOL=23, SERIAL2_OPTIONS=7
- ACCESS Archer M+ on FPort and FPort2, 4kOhm pulldown TELEM2 TX pin, SERIAL2_PROTOCOL=23, SERIAL2_OPTIONS=7
Note: RC_OPTIONS = 0 for all setups
Alex
Hi Alex,
thank you for testing! I finally got it working - pulling down with 5k instead of 10k.
Summary, tested on CubeOrange and Archer RS (ACCESS 2.1.2), RC_OPTIONS = 0:
- Inverter Cable (incl. duplexing) serial4 to S.Port, RC SBUS, Protocol 10, Options 160 -> all good.
- Inverter Cable (incl. duplexing) serial4 to F.Port&F.Port2 (both activated in RX-options), Protocol 23, Options 160 -> all good.
- serial4_tx to inverted S.Port, Protocol 10, Options 4 -> no telemetry (obviously no RC).
- serial4_tx to F.Port&F.Port2, Protocol 23, Options 7 -> no telemetry, RC present.
- serial4_tx to F.Port&F.Port2, Protocol 23, Options 7, pulldown 20k on tx -> no telemetry, RC present.
- serial4_tx to F.Port&F.Port2, Protocol 23, Options 7, pulldown 10k on tx -> no telemetry, RC present.
- serial4_tx to F.Port&F.Port2, Protocol 23, Options 7, pulldown 5k on tx -> finally all good… what a journey.
Edit:
Using ACCESS 2.1.8 on the Archer RS, telemetry and RC only works with F.Port selected in RX-options. Adding F.Port2 breaks communication.
Maybe the solution might be added to the ArduPilot documentation?
BR, Konrad
1 Like
Can please someone point me in the right direction?
I have the Matek F405-WSE fc, taranis and a Jumper R8 receiver. Currently running ardurover.
I have SBUS working but can’t get any telemtry with the Yaapu Frsky Telemetry Script currently running on my taranis with OpenTx 2.3.11…
Jumper R8 connected to TX2.
SERIAL2_BAUD 57
SERIAL2_OPTIONS 7
SERIAL2_PROTOCOL 10