Here’s the code with the latest changes
1 Like
Thanks for the feedback and information Alex. And thanks for the links. I had a very busy family weekend, so lots to catch up with.
Alex, ok …
S.Port (and Passthrough) Telemetry via FrSky RX still works fine with ArduPlane firmware 3.94. Starting with firmware 3.95 incl. the “Latest” firmware GPS positions are only transmitted irregularly. There are pauses of more than 10 seconds.
The failures can be seen on the FrSky transmitter on the telemetry screen (the asterisk does not appear regularly at the GPS position).
https://workupload.com/file/cQV4zZkM (look at 0:47 seconds)
Hardware constellation is Matek F405-Wing. UART via inverter on FrSky-RX (several tested).
Who can say anything about this?
The generated S.Port signal on the UART is conspicuous:
FW 3.94: https://workupload.com/file/BDRMyf5u
FW 3.98: https://workupload.com/file/sYUqQQR5
I’ll assume your GPS is working fine and under MP you get regular position updates and no “Bad GPS Health” warnings, if this is the case you might have a problem on the s.port bus.
Does this happen even when motors are “disarmed”?
I’ve seen this happen when the s.port bus experiences delays in the polling, the current ardupilot scheduler gives a rather low priority to GPS packets and can drop them.
If instead of the S.Port output of the F405-Wing an OpenXSensor or the original GPS of FrSky is connected, then there is no problem.
Mission Planner is not used in this case, but only the FrSky telemetry or your script.
With the motor “disarmed” is a good question. Most of the tests were probably with it. Does this affect the S.Port?
yes there’s an issue related to poor SD card performance. The frsky telemetry thread might suffer delays under some circumstances, like this one as well
It doesn’t matter if the status is armed or disarmed.
No SD card is inserted in the F405 wing (if this is important due to interrupt handling of UART ports and SD card).
The problems were reported to me by another user. But I can confirm this. There is probably a problem, which did not occur with older firmware 3.94 yet.
The problems in your links are mostly older. Probably they don’t match the current problem.
In this context, do you know Alex why the VSpd value is not transmitted via S.Port? This is always 0 and it would be nice if we had this value for Gliders.
VSpd is not transmitted by Ardupilot but it’s exposed to OpenTX by my script.
You need to discover new sensors while my script is running and while you have incoming telemetry data.
To use the vario in OpenTX you have to use altitude instead ov vspd.
Thanks, Alex, I passed that on.
More important would be the problem with the irregular update of the GPS position. You can’t adjust it or you don’t have the hardware (F405-Wing)?
I’ll try to do this later with a MiniPix. Let’s see if it’s there too.
I’m using 3.9.8 on omnibusf4v2, pixracer, pixhawkv1 and minipix all but pixracer have the max3232 external adapter and gps is working fine. I do have a matek-wing but havent used it yet.
Hi Alex,
Does Option 4 or 10 (Passthrough) have to be selected for this?
The user has set option 4, started your script and searched for new sensors. But VSpd is always 0 …
Option 10 for passthrough
Is there a plan to merge this into master?
Hi Randy,
haven’t created a PR yet but my intention is to do so.
Did you try the code yourself?
Yes I did, on two multi rotors. Seems to work well. Don’t know where I would be without your telemetry script, thanks for the work and dedication.
Cheers,
Randy Bachtell
Thanks for the kind words Randy!
There’s one last change I made to the code, I added rate limiters so now packets can’t go faster than a predetermined rate.
init() code now is
// initialize packet weights for the WFQ scheduler
// weight[i] = 1/_passthrough.packet_period[i]
// rate[i] = LinkRate * ( weight[i] / (sum(weight[1-n])) )
_passthrough.packet_weight[0] = 35; // 0x5000 status text (dynamic)
_passthrough.packet_weight[1] = 50; // 0x5006 Attitude and range (dynamic)
_passthrough.packet_weight[2] = 550; // 0x800 GPS lat (600 with 1 sensor)
_passthrough.packet_weight[3] = 550; // 0x800 GPS lon (600 with 1 sensor)
_passthrough.packet_weight[4] = 400; // 0x5005 Vel and Yaw
_passthrough.packet_weight[5] = 700; // 0x5001 AP status
_passthrough.packet_weight[6] = 700; // 0x5002 GPS Status
_passthrough.packet_weight[7] = 400; // 0x5004 Home
_passthrough.packet_weight[8] = 1300; // 0x5008 Battery 2 status
_passthrough.packet_weight[9] = 1300; // 0x5003 Battery 1 status
_passthrough.packet_weight[10] = 1700; // 0x5007 parameters
_passthrough.packet_weight[11] = 35; // mavlite (dynamic)
_passthrough.packet_min_period[0] = 0; // no rate limiter
_passthrough.packet_min_period[1] = 38; // 22Hz
_passthrough.packet_min_period[2] = 200; // 5Hz
_passthrough.packet_min_period[3] = 200; // 5Hz
_passthrough.packet_min_period[4] = 250; // 4Hz
_passthrough.packet_min_period[5] = 500; // 2Hz
_passthrough.packet_min_period[6] = 500; // 2Hz
_passthrough.packet_min_period[7] = 500; // 2Hz
_passthrough.packet_min_period[8] = 500; // 2Hz
_passthrough.packet_min_period[9] = 500; // 2Hz
_passthrough.packet_min_period[10] = 1000; // 1Hz
_passthrough.packet_min_period[11] = 0; // no rate limiter
This prevents the scheduler to saturate bandwidth with unwanted packets leaving slots to packets that need them the most like message chunks
@yak-54 Colin,
this is the latest plane 3.9.11 with the patched scheduler, let me know if it fixes the GPS issue
The new scheduler code has been merged into master and I’m happy to report it will backported to next minor ardupilot release i.e copter 4.0.x, plane 4.0.x and rover 4.0.x 