OSD Link Quality Alarm showing when switching between RFMD1(50Hz) and RFMD2(150Hz)

[PansRocks]

Describe the bug
Link quality alarm displaying excessively in the OSD when flying at relatively close range with Crossfire. Coming from BF4.1 the LQ in the OSD was very consistent normally never dropping below 90 on <1km flights, using the same drones (3 x different builds) upgraded to BF 4.2 RC1 the LQ is very twitchy jumping from RFMD 1 to RFMD 2 and displaying the alarm. The Taranis has the correct logic switches with alarms and I get no call outs from it at the same time.

To Reproduce
I have 3 x separate drones displaying this behaviour, all hardware (CF Tx, CF Rx, Antenna orientation, power output etc) proven on the same builds on BF 4.1. CF typically ran at 250Mw with Dynamic Off on 868Mhz.

Expected behaviour
No alarm should display when simply switching modes, the logical switches on the Taranis have a 0.5 sec delay to allow for switching, this is possibly the reason for the alarm showing.

Flight controller configuration

# diff

# version
# Betaflight / STM32F405 (S405) 4.2.0 Apr 22 2020 / 12:49:33 (bf9cc615c) MSP API: 1.43

# config: YES

# start the command batch
batch start

board_name DYSF4PRO
manufacturer_id DYST

# feature
feature -RX_PARALLEL_PWM
feature RX_SERIAL
feature TELEMETRY

# beeper
beeper -ARMING_GPS_FIX
beeper -BAT_CRIT_LOW
beeper -BAT_LOW
beeper -GPS_STATUS
beeper -ON_USB

# serial
serial 0 64 115200 57600 0 115200
serial 5 8192 115200 57600 0 115200

# aux
aux 0 0 0 1400 1600 0 0
aux 1 13 0 1900 2100 0 0

# vtxtable
vtxtable bands 6
vtxtable channels 8
vtxtable band 1 BOSCAM_A A CUSTOM  5865 5845 5825 5805 5785 5765 5745 5725
vtxtable band 2 BOSCAM_B B CUSTOM  5733 5752 5771 5790 5809 5828 5847 5866
vtxtable band 3 BOSCAM_E E CUSTOM  5705 5685 5665    0 5885 5905    0    0
vtxtable band 4 FATSHARK F CUSTOM  5740 5760 5780 5800 5820 5840 5860 5880
vtxtable band 5 RACEBAND R CUSTOM  5658 5695 5732 5769 5806 5843 5880 5917
vtxtable band 6 IMD6     I CUSTOM  5732 5765 5828 5840 5866 5740    0    0
vtxtable powerlevels 5
vtxtable powervalues 25 100 200 400 600
vtxtable powerlabels 25 100 200 400 600

# master
set gyro_lowpass2_hz = 325
set dyn_notch_width_percent = 0
set dyn_notch_q = 250
set dyn_notch_min_hz = 90
set dyn_notch_max_hz = 350
set dyn_lpf_gyro_min_hz = 260
set dyn_lpf_gyro_max_hz = 650
set acc_calibration = -97,-1,-77,1
set mag_hardware = NONE
set baro_hardware = NONE
set rc_smoothing_auto_smoothness = 20
set serialrx_provider = CRSF
set blackbox_device = NONE
set dshot_idle_value = 250
set dshot_bidir = ON
set motor_pwm_protocol = DSHOT300
set vbat_scale = 111
set small_angle = 180
set deadband = 5
set yaw_deadband = 5
set pid_process_denom = 2
set osd_warn_link_quality = ON
set osd_vbat_pos = 2085
set osd_rssi_pos = 45
set osd_link_quality_pos = 2092
set osd_tim_2_pos = 2099
set osd_stat_max_curr = OFF
set osd_stat_used_mah = OFF
set osd_stat_bbox = OFF
set osd_stat_bb_no = OFF
set vtx_band = 4
set vtx_channel = 8
set vtx_power = 4
set vtx_low_power_disarm = ON
set vtx_freq = 5880
set gyro_1_align_yaw = 1800
set gyro_rpm_notch_harmonics = 1
set gyro_rpm_notch_q = 800

profile 0

# profile 0
set dyn_lpf_dterm_min_hz = 91
set dyn_lpf_dterm_max_hz = 221
set dyn_lpf_dterm_curve_expo = 7
set dterm_lowpass2_hz = 195
set iterm_relax_cutoff = 10
set yaw_lowpass_hz = 60
set throttle_boost = 0
set throttle_boost_cutoff = 10
set ff_interpolate_sp = AVERAGED_3
set ff_spike_limit = 55
set ff_smooth_factor = 40

rateprofile 0

# rateprofile 0
set roll_expo = 20
set pitch_expo = 20
set yaw_expo = 20

# end the command batch
batch end

Setup / Versions

• Flight controller [DYSF4PRO, Matek F722 Mini, Aikon F4 Mini
• Other components [Crossfire Micro Tx, Taranis X9D, Tango 2, Nano Rx];
• 3 x quads and different Tx Rx setps - all display the same behaviour with BF4.2, the same hardware with BF4.1 had no issue.

Additional context
I'm not sure how relevant it is to know that it has switched RFMD modes, it seems it switches from 150Hz to 50Hz after a relatively short distance, <100 meters in some flying spots. An option to display just basic LQ should be considered like BF4.1 - RFMD modes are not something I personally consider.

[dischinator]

Yes this is something that also annoys me a bit since BF4.2. Imho LQ warning should be configurable when using crossfire by RFMD and LQ or set fixed to RFMD 1 and < 80% like in BF4.1.

[dischinator]

Hello @ianrmurphy I saw you have been implementing the LQ alerts initially, if you are still around, could you please take a look at this issue?

[ianrmurphy]

I didn't implement the LQ monitor / alarm, I simply added it to the list of warnings that show up in the 'Warnings' OSD element. Previously the behaviour was that the smaller LQ OSD element would flash but this is not always easy to see.

You might want to adjust the CLI parameter 'osd_link_quality_alarm' (default = 80) to a lower value.

At what LQ value does the Crossfire switch modes?

[dischinator]

Thanks for the quick reply and sorry if I picked the wrong person.
Crossfire seems to switch mode at 50. I also noticed on BF4.2 LQ is shown as Mode:Quality i.e. 2:100 on BF4.1 it was showing a combined integer i.e. 299 instead of now 2:99 maybe this change confused the alter logic?

[ianrmurphy]

If you go back to my original issue (#8001) you can see that 80 for the LQ alarm was really just a first pass guess.

One issue is that LQ might behave differently for all the different control links. E.g. CRSF works well down to 50 while FrSky might be unusable at that value.

I guess it would be feasible to set a different default for each link, the data collection would need to be co-ordinated.

How LQ is displayed has nothing to do with the alarm threshold.

[dischinator]

Ah I see. Strange thing is in BF4.1 the alarm only went off at 80 in mode 1. Now it triggers at mode 2 and quality <= 80 then it stops after mode is changed to 1 until quality <= 80.
So for some reason rf mode is no longer checked. I'll try to compare alert conditions in 4.1 to 4.2 and see if something changed.

[dischinator]

Interesting, the check done for OSD is

rxGetLinkQualityPercent() < osdConfig()->link_quality_alarm

I noticed @mikeller did some refactoring on the LQ calculation, maybe this is a side effect.

[ianrmurphy]

Yes there is an inconsistency here, the OSD display element uses rxGetLinkQuality followed by its own scaling depending on if CRSF is used:

uint16_t rxGetLinkQuality(void)
{
    return linkQuality;
}
.
.
static void osdElementLinkQuality(osdElementParms_t *element)
{
    uint16_t osdLinkQuality = 0;
    if (linkQualitySource == LQ_SOURCE_RX_PROTOCOL_CRSF) { // 0-99
        osdLinkQuality = rxGetLinkQuality();
        const uint8_t osdRfMode = rxGetRfMode();
        tfp_sprintf(element->buff, "%c%1d:%2d", SYM_LINK_QUALITY, osdRfMode, osdLinkQuality);
    } else { // 0-9
        osdLinkQuality = rxGetLinkQuality() * 10 / LINK_QUALITY_MAX_VALUE;
        if (osdLinkQuality >= 10) {
            osdLinkQuality = 9;
        }
        tfp_sprintf(element->buff, "%c%1d", SYM_LINK_QUALITY, osdLinkQuality);
    }
}

While the alarm element uses rxGetLinkQualityPercent which assumes CRSF is in percent and passes it through:

uint16_t rxGetLinkQualityPercent(void)
{
    return (linkQualitySource == LQ_SOURCE_RX_PROTOCOL_CRSF) ?  linkQuality : scaleRange(linkQuality, 0, LINK_QUALITY_MAX_VALUE, 0, 100);
}
.
.
    if (rxGetLinkQualityPercent() < osdConfig()->link_quality_alarm) {
        SET_BLINK(OSD_LINK_QUALITY);
    } else {
        CLR_BLINK(OSD_LINK_QUALITY);
    }

At first glance these seem to work out the same for the LQ alarm (always comparing in percent) while displaying very different OSD LQ elements (CRSF shows 'Mode:0->99' while non-CRSF shows 0->9).

I'm still thinking that if you need to stop the LQ alarm false triggering with CRSF, then lower the alarm setting to e.g. set osd_link_quality_alarm = 50.

Not having Crossfire myself I can't really test this.

[PansRocks]

Link to the TBS info below. As I read it LQ in 150Hz does not matter, an LQ of 70 or below in 50Hz is considered turn around and go home. If set at 50 it currently can't differentiate between RFMD1 and RFMD2 so you'll potentially be in a fail safe scenario.

http://team-blacksheep.freshdesk.com/support/solutions/articles/4000112664-rssi-link-quality-lq-warning-for-opentx

[dischinator]

@ianrmurphy yes CRSF is a bit different there. LQ 50 at mode 1 will probably be almost unflyable since it degrades very fast at that point. So setting the alarm at 50 is too late. We somehow need to bring the rf mode back into the alarm calculation.

[JimB40]

There are 3 scenarios - RF profiles in crossfire settings

a. RF profile = 150Hz It means constant RFMD 2. No down switching to 50Hz (RFMD 1). This is for racing where you have clear view and usually don’t fly more 100-150m away. If LQ in this profile drops below 70% you’ll failsafe. Btw I’ve heard failsafe occurs in this mode below lower LQ values like 40 or 50% but this has to be confirmed.

b. RF profile = 50Hz. Constant RFMD 1. No upswitchig to 150Hz. Here as PansRocks stated LQ=80% is warning level and LQ=70% is critical

c. RF profile = Dynamic. Starts in 150Hz (RFMD 2) and when LQ drops below some mystic value between 50% 70% it switches down to 50Hz (RFMD 1) and the very same moment LQ goes to 99% because 50Hz mode is more efficient. Then in another mystic moment when CRSF decides LQ is good enough switches up to 150Hz setting LQ to actual value which is not always 99%. May be for example 80% if quad is 100m then LQ increases as you approach transmitter.

So as I understand in BF4.2 LQ variable used for OSD warning is the same regardless RFMD. That’s okay for scenario a & b. But for Dynamic RF profile - when LQ drops below warning level in RFMD 2 it should be ignored because after short moment CRSF will switch down go 50Hz RFMD 1 and no failsafe is possible.
That’s how it was implemented in BF 4.1. In RFMD 2 150Hz LQ was always set to 99% (even real value fluctuated) so OSD warning was thrown only if it switched down to RFMD 1 50Hz and LQ went below warning level. Downside of this implementation is that if you pick scenario a (constant RFMD 2 150Hz) there will be no warning at all.
To implement this properly information about RF profile should be available to BF. Don’t know if it is.

Btw my work around for the time being is to set CRSF RF profile to 50Hz (I’m not racing) so it is not switching back and forth between RFMD 1 and 2 and therefore false OSD warning is not showing.

[mikeller]

@JimB40:

To implement this properly information about RF profile should be available to BF. Don’t know if it is.

I don't think this can be accessed by Betaflight, as this is a TX setting. Maybe @tbs-trappy can shed some light?

[0crap]

Related to #9986

[N4V1G4T0R]

@JimB40:

To implement this properly information about RF profile should be available to BF. Don’t know if it is.

I don't think this can be accessed by Betaflight, as this is a TX setting. Maybe @tbs-trappy can shed some light?

Any comment from TBS?

[sirPerna]

@JimB40:

To implement this properly information about RF profile should be available to BF. Don’t know if it is.

I don't think this can be accessed by Betaflight, as this is a TX setting. Maybe @tbs-trappy can shed some light?

Crossfire basically just provides raw data and let the UI of the consumer decide where to set the limits. We also get many reports about RSSI being low where in fact it's not. Maybe we can address both the same time. There are multiple approaches we could do.

1: Crossfire will report LQ differently depending of the RF profile setting inside Crossfire everything else remains the same
2: We make a new CRSF frame which shares LQ and RSSI as percent and all the estimations are done inside crossfire. In this case the RSSI and LQ percentage would match the one Crossfire outputs when theses values are mapped to a channel.
3: we append those values from 2: into the existing link statistics frame.

[tbs-trappy]

I can shed some light into how we do it in our OSD: we interpret LQ as a percentage of 50 frames per second. (frames received in last second / 50 ). This covers all 3 modes, as the value range of LQ goes from 0 to 300. This is also how we have output LQ parameter in the past via AUX inputs, but it was cut off at 100 since this was the maximum range provided due to the PWM nature of the signal.

As a pilot it's important that my warning levels are the same across all TX and RX settings, profiles, etc. that may be switching without my knowledge. LQ also tells me how responsive my drone is, and we felt that "100% responsive" would be what people are typically used to from other control links. Therefore, the 0-300% LQ implementation is what we would recommend. Together with RSSI values and SNR (only shows up if <= 6), this will give the pilot all vitals at a single glance, and also allows for a standardized < 70% LQ warning & SNR < 0 warning.

Modifications to CRSF protocol are encouraged, so if you'd like us to make changes to meet suggestion #1 or #2 from @sirPerna please let us know. In my opinion, it could be a cause for confusion.

[stale]

This issue / pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within a week.

[mikeller]

@sirPerna, @tbs-trappy: Thanks for the explanations - not sure where we got this from, but the way that the crossfire link quality was calculated in Betaflight (stats.rf_Mode * 100 + stats.uplink_Link_quality) seems to be completely at odds with what you say it should be. I think the preferable way to do this is 3., or potentially 2. - since you are already displaying the values on the TX, having the RX supply the exact same values to the flight controller will ensure that the user gets consistent values in all places, across irrespective of crossfire firmware changes and different settings.

[sirPerna]

@mikeller okay we will work out a solution based on this and get back to you.

[CraigFPV42]

So does this mean that the failsafe with xfire is broken?

[mikeller]

@CraigFPV42: Failsafe is different - for CRSF it requires a complete loss of connection to kick in.

[stale]

This issue / pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within a week.

[stale]

Automatically closing as inactive.

[Frix-x]

Is there any news regarding this functionnality ? I'm currently running in the constant 150Hz RF profile on my radio as a workaround.

However I would love to get back to dynamic mode if possible. This would allow me to avoid stupids failsafe (like the one I got today) by coming back in a better coverage area while using the 50Hz RF profile.