That script is only for frsky stuff, it doesn’t count the passthrough over CRSF packets
I have heard of users having poor results with mode 1 - and of course the RX is not simply passing on the data, it is mediating somehow - so I’m disappointed, but not surprised. Maybe we should petition Remo to get a few more details on what is going on - it sure would help many people.
1 Like
Worked like a charm. Thanks for the info.
1 Like
@yaapu fresh install on a fresh radiomaster and MatekF405-Wing with excellent results, no more telemetry stalling, everything working as expected. now trying to figure what the issue on the taranis setup is…
wow, I was in need of good news, started to fear I was the only one who got it working 
…I’m still not satisfied at all of the mode 1 performance 
@yaapu i think i found the issue i had. i‘m running crsf from UART3 on omnibusnanov6, which happens to be a ABP1 clock divider UART. with the new setup (radiomaster etc) i was testing with crsf from UART1 on matekf405-wing, which runs on the APB2 clock divider.
i tested with crsf from (APB1) UART4 on MatekF405-Wing and could reproduce the exact same stalling of telemetry as soon as i added GPS fix. my current hypothesis is that APB1 UARTs on STM32F4 can‘t cope with the requested rates, while APB2 clock divider UARTs 1 and 6 can.
i‘d be happy if someone could try and reproduce this. matekf405-wing is a convenient target for testing as UART / SERIAL numbers match.
@vierfuffzig did same test on my matekf405-wing, I can’t stall the telemetry, crsf on UART4 and gps on UART3
This version will send a status text message every 5 seconds with rfmode and polling rate
APM: Crossfire rf mode change detected, rf_mode=2
APM: CRSF rf mode: 2, packet rate 30
APM: CRSF rf mode: 2, packet rate 35
APM: CRSF rf mode: 2, packet rate 35
APM: CRSF rf mode: 2, packet rate 30
APM: CRSF rf mode: 2, packet rate 34
APM: CRSF rf mode: 2, packet rate 36
APM: CRSF rf mode: 2, packet rate 36
just curious to see which numbers you get
MatekF405-Wing arduplane.apj (833.3 KB)
thanks alessandro. i’m seeing inconsistent results here. the one thing that consistently strikes me is that i’m getting rates of ~130 when using USART1:
APM: IMU0: fast sampling enabled 8.0kHz/1.0kHz
Received 1111 parameters (ftp)
Saved 1111 parameters to mav.parm
Flight battery 100 percent
APM: CRSF rf mode: 2, packet rate 133
Mode RTL
APM: CRSF rf mode: 2, packet rate 133
APM: CRSF rf mode: 2, packet rate 131
APM: CRSF rf mode: 2, packet rate 129
APM: CRSF rf mode: 2, packet rate 133
APM: CRSF rf mode: 2, packet rate 133
APM: CRSF rf mode: 2, packet rate 135
APM: CRSF rf mode: 2, packet rate 136
APM: CRSF rf mode: 2, packet rate 135
APM: CRSF rf mode: 2, packet rate 136
APM: CRSF rf mode: 2, packet rate 132
APM: CRSF rf mode: 2, packet rate 135
APM: CRSF rf mode: 2, packet rate 134
but rates around 1-40 when using any other UART:
GPS OK
APM: CRSF rf mode: 2, packet rate 25
APM: CRSF rf mode: 2, packet rate 26
APM: CRSF rf mode: 2, packet rate 23
APM: CRSF rf mode: 2, packet rate 22
APM: CRSF rf mode: 2, packet rate 20
APM: CRSF rf mode: 2, packet rate 22
APM: CRSF rf mode: 2, packet rate 26
APM: CRSF rf mode: 2, packet rate 23
Same results here, only UART1 can handle telemetry at full speed! @andyp1per any insights?
Edit: bad mode 1 performance is still there, no matter the UART used
@vierfuffzig if I leave it runnig on UART1 I can eventually freeze the link, what I get is
APM: Crossfire rf mode change detected, rf_mode=2
APM: CRSF rf mode: 2, packet rate 136
APM: Crossfire rf mode change detected, rf_mode=1
APM: Crossfire rf mode change detected, rf_mode=2
APM: CRSF rf mode: 2, packet rate 137
APM: CRSF rf mode: 2, packet rate 140
APM: Crossfire rf mode change detected, rf_mode=1
APM: Crossfire rf mode change detected, rf_mode=2
APM: Crossfire rf mode change detected, rf_mode=1
APM: Crossfire rf mode change detected, rf_mode=2
APM: Crossfire rf mode change detected, rf_mode=1
APM: Crossfire rf mode change detected, rf_mode=2
APM: CRSF rf mode: 2, packet rate 133
APM: Crossfire rf mode change detected, rf_mode=1
APM: Crossfire rf mode change detected, rf_mode=2
APM: Crossfire rf mode change detected, rf_mode=1
APM: Crossfire rf mode change detected, rf_mode=2
APM: CRSF rf mode: 2, packet rate 131
APM: CRSF rf mode: 2, packet rate 140
APM: CRSF rf mode: 2, packet rate 139
after multiple changes between mode 1-2 telemetry freezes, can’t freeze it if I use another UART port. Power cycling the RX restores telemetry
@andyp1per this looks to me either a TBS firmware issue, or an out of sync induced by ardupilot (are we responding out of the allowed time frame?)
quick update:
Did some further testing and changed my post above:
and related or not: my MicroTX here is an old first generation type (hardware V1.03).
You could play with the uart settings in AP_RCProtocol_CRSF::start_uart() to see if there’s anything there that is causing this
1 Like
Hi Guys, just wanted to let you know that we tested this out in a f405-wing, on serial3 (this seems important) on a new micro tx v2.
Everything looks great! I do see a freeze once in a while, after several mode1 mode2 changes on the bench ( I guess due to noisy environment?). We didn’t see the same problem at the field.
I wonder if it would be possible to keep the flight mode info in mode 1. We often fly at the limit of our fpv feed, and when we lose video, we would like to rely on the flight mode change confirmation (to rtl) when this happens. Not sure what other information I would abandon in favor of this though!
A nice addition would be to display the crossfire TX power ( i.e. 25mw, 50mw, 250mw, 500mw, 1W)
1 Like
Thanks, same here, I do get freezes every once in a while on rf mode switch while on the bench but once outside is better!
I wonder if it would be possible to keep the flight mode info in mode 1. We often fly at the limit of our fpv feed, and when we lose video, we would like to rely on the flight mode change confirmation (to rtl) when this happens. Not sure what other information I would abandon in favor of this though!
I really don’y know how to “shape” the packets while in mode 1, right now looks like it’s dropping pretty much every packet I throw at it
A nice addition would be to display the crossfire TX power ( i.e. 25mw, 50mw, 250mw, 500mw, 1W)
There’s room on the Horus, RTP means RQly,TQly,power
not much room left on Taranis radios top bar
Some progress on this, now I’m 100% sure the RX is filtering out custom frames on rf mode 1.
I tried using the CRSF_FRAME_COMMAND id 0x32 instead of the custom one 0x80 I was using and albeit slow telemetry is working even in mode 1, flight mode changes have a 3 sec delay but they work as well as status text, battery, altitude, gps, etc so IMO it’s usable, the artificial horizon is the one thing that feels frozen because of the huge latency.
1 Like
playing with the uart init does not make any difference.
But if I skip the frame timing check
if (tdelay > CRSF_MAX_FRAME_TIME_US && check_constraint) {
// we've been too slow in responding
return false;
}
I get 70 Hz vs the 33Hz I usually get, so I’d say that all UARTs but UART1 cannot do telemetry at 400K baud
So that would argue in favour of using the telemetry frames where you can can using the custom frame when you have the higher rate