Frsky passthrough telemetry WFQ packet scheduler proposal

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 :slight_smile:

well i see it has made it in

plane 4.0.2beta1
changed to WFQ FrSky telemetry scheduler

Yes, it’s in, did you have a chance to test it on your setup?

Please do let me know how it goes in the beta!

@tridge @yak-54 has the right test bed for this change.

As for myself I bench tested it on a Matef F405-Wing and will hopefully fly it soon if the weather collaborates

1 Like

what am i testing always ready to do my bit for all the great work you lot do :+1:

ok i will up date the plane to 4.0.2beta1

Looks good and working so here are some logic scans and data logs :clap:

1 Like

I am running telemetry on a pixhawk and an F405-Wing, and I have run both with the new scheduler with lots of debugging statements added when I could not get passthru telemetry to work. The max3232 or 232 converters simply don’t work with r-xsr receivers and the F405 Wing, and neither does the uninverted s,port signal. I thought maybe there was a code problem, so I added prints to see what was happening. I did not study the result extensively, but I can if it will help. I did not see any glaring errors like one parameter ID always getting sent. I’ll try to get some data with timestamps.

Hi @voi9viper2 David
I really doubt it’s a software issue, also the hal->printf introduce delays that eventually break the frsky polling timing.

Can you do a trace with a logic analyzer?

Hi, I see many framing errors in your captures, maybe some interference on the wiring, any RF sources nearby?

not that i know of
i will do a trace with out RDF900x power up see how that goes

ok did 2 test one with rdf900x one without rdf900x

Hello!
When I use the passthrough protocoll there is no need to discover sensors on the taranis. But when I need one of these sonsors for example in logical switches, I have to discover. After discovering the sensors are saved in the compagnion and, after saving again to the taranis, there are 2 equal sensors. How can I solve this problem?

this looks like the same as An Open Source Frsky Telemetry Script for the Horus X10,X12 and Taranis X9D,X9E and QX7 radios