Repository navigation
Hide the RX downlink power element when the link does not report it - #11914
sensei-hacker merged 4 commits into
Conversation
The receiver transmit power is only written by the MSP and MAVLink RC paths. The CRSF link statistics frame 0x14 has no such field and no other CRSF frame is parsed for it, so with an ExpressLRS receiver the element showed a permanent 0 mW. ExpressLRS never sends the optional link statistics RX frame 0x1C that would carry a power value, so parsing it would not populate the element either. A power of 0 already means "not reported" on the other paths, so skip drawing the element in that case. Fixes iNavFlight#11136
|
ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing |
Code Review by Qodo
1.
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
PR Summary by QodoHide unavailable receiver downlink power from the OSD
AI Description
Diagram
High-Level Assessment
Files changed (2)
|
Like the other OSD elements that hide themselves at runtime, the element now takes its slot in the per-cycle draw budget after blanking its field. No visible change. The receiver transmit power is carried by CRSF frame 0x1D, not 0x1C. INAV parses neither and ExpressLRS sends neither, so the docs no longer claim that CRSF cannot carry the value, and name mLRS only as MAVLink receiver.
|
RAM / Flash usage vs. base commit
See RAM/flash optimization guide for techniques to reduce usage. |
|
Test firmware build ready — commit Download firmware for PR #11914 251 targets built. Find your board's
|
Only MSP receivers that send MSP2_COMMON_SET_MSP_RC_INFO report the receiver transmit power, and mLRS reports 0 dBm or less as 0 mW, so the element is also hidden for mLRS at 1 mW and below. Say so in the OSD element table.
|
Thanks! |
Problem
On an ExpressLRS receiver (BetaFPV SuperD 2.4, INAV 8.0.1, Matek H743 V3) the OSD element
OSD_RX_POWER_DOWNLINKshows0 mWalthough the receiver transmits telemetry at 100 mW. Fixes #11136.Cause
osdDrawSingleElement()printsrxLinkStatistics.downlinkTXPowerunconditionally. Only two paths write the field:MSP2_COMMON_SET_MSP_RC_INFO(fc_msp.c) and the mLRS radio link information when MAVLink is the serial receiver (fc_mavlink.c). Of the CRSF link statistics frames the parser handles only 0x14 (crsf.c), which carries the transmitter's uplink power but no receiver power, so on CRSF the field keeps its initial 0.CRSF carries the receiver power in frame 0x1D (LINK_STATISTICS_TX, the source of the EdgeTX sensor RPWR). ExpressLRS sends neither 0x1C nor 0x1D (its
crsf_protocol.hin 3.5.6 and 4.1.0 defines no such frame type), and INAV parses neither, so with ExpressLRS there is no value the element could show. Commit cd44927 names 0x1C; the correct frame is 0x1D.Change
In the
OSD_RX_POWER_DOWNLINKcase, whendownlinkTXPoweris 0, the element blanks its six characters and returnstrue, like the other elements inosd.cthat hide themselves at runtime (e.g.OSD_COURSE_HOLD_ERROR). The blank write (fe5ea81) removes a previously drawn value when an MSP or mLRS link reports 0. A value that stops arriving is not cleared, sincerxLinkStatisticsis never reset; that behaviour is unchanged.On MSP, 0 means "not reported". On mLRS,
mavlinkDbmToMilliwatts()maps both "not reported" (INT8_MAX) and 0 dBm or less to 0, so the element is also hidden at 0 dBm (1 mW) and below.Test
Linux SITL, current
maintenance-10.x(3931fcd) against the same tree with this PR merged. OSD over MSP DisplayPort (HDZERO) on UART2, element 160 enabled; the six element cells were read back from the DisplayPort stream.CRSF receiver on UART3 (RC frames at 50 Hz, link statistics 0x14 at 10 Hz with uplink power index 3 and the downlink fields 0, as ExpressLRS sends them):
0mW↓mW↓OSD_TX_POWER_UPLINKshowed100mWin both builds.Receiver
MSP, RC viaMSP_SET_RAW_RCat 50 Hz, receiver power set withMSP2_COMMON_SET_MSP_RC_INFO:0mW↓100mW↓100mW↓0mW↓100overwrittenmW↓mW↓100mW↓100mW↓mW↓With
osd_msp_displayport_fullframe_interval = -1the PR build gives the same results, so the blank write does not depend on the periodic full-frame refresh. Not tested on hardware or with mLRS.Built locally with
-DWARNINGS_AS_ERRORS=ONfor MATEKF722, MATEKF405 and SITL, no warnings.Flash / RAM
Against current
maintenance-10.x(3931fcd),arm-none-eabi-size: MATEKF722 text +0 B (osdDrawSingleElementgrows by 4 B, absorbed by alignment), MATEKF405 text +48 B, data and bss unchanged on both. MATEKF722 FLASH1 is at 97.54 %.The size bot comment compares the CI merge build against the older base commit 76ee415, so its deltas show the
maintenance-10.xchanges since then, not this PR.Docs
docs/OSD.md, rowOSD_RX_POWER_DOWNLINK: "The element is hidden while the receiver transmit power is 0 mW, which is also the value when the RC link does not report it. MSP receivers that sendMSP2_COMMON_SET_MSP_RC_INFOand mLRS as MAVLink receiver report it (mLRS at 0 dBm or less reads as 0 mW). INAV does not read it from CRSF links such as ExpressLRS."Reference
EdgeTX v2.12.4 reads the receiver power (sensor RPWR) from frame 0x1D:
radio/src/telemetry/crossfire.h:47(LINK_TX_ID 0x1D),radio/src/telemetry/crossfire.cpp:359-363(byte 7 →RX_RF_POWER_INDEX, sensor table entry at line 55 =STR_SENSOR_RX_RF_POWER, "RPWR").