This is a concrete failure mode described in Betaflight pull request #15828, which includes hardware measurements on a DJI O3 Air Unit and Goggles 2. The findings illuminate a broader integration problem: an OSD can reach a receiver-side complexity limit without any explicit error reaching the flight controller. The proposed patch is still development work. Its hardware-specific thresholds should not be treated as specifications for every pair of goggles.
The OSD takes a different path from the image
Betaflight's digital VTX guide describes character rendering in the goggles rather than burning characters into high-resolution video at the air unit. In that design, the flight controller assembles elements such as voltage, timer, RSSI and warning text, passes DisplayPort commands through its configured UART, and leaves the receiving device to draw them.
The protocol is not simply a continuous stream of pixels. Betaflight's MSP DisplayPort reference specifies commands to clear the screen, write strings at coordinates and draw the resulting screen. The MSP_SET_OSD_CANVAS exchange can tell the flight controller the available character grid. The Configurator OSD documentation gives a typical HD canvas as 53 columns by 20 rows, with the possibility of a different size negotiated by the device.
That separation has a useful operational consequence and an awkward diagnostic one. The goggles may continue decoding video while the OSD renderer rejects a complex frame. No lost-camera-video alarm necessarily follows. And if the renderer retains its last frame, the data can look plausible for several seconds unless the pilot notices that a timer or another visibly changing element has stopped.
A stale OSD is not proof that RC control has failed. The reverse is equally important: a good video picture and apparently legible overlay are not proof that current telemetry is arriving.
What the O3 bench measurements actually show
The PR's test report used an O3 Air Unit running firmware dated July 2024 and Goggles 2 running firmware dated February 2025. The goggles were set to the Betaflight flight-controller display mode with an HD canvas. The contributor replayed DisplayPort traffic and captured the goggles output, comparing frames accepted and frames discarded.
The striking result is that the renderer's apparent limit depends on where cells are written. With solid 53-cell rows starting at column zero, a 637-cell frame was shown and a 638-cell frame was discarded. With single cells separated by two columns, the reported boundary was 361 shown and 362 discarded. For one realistic layout, 520 cells were shown but a 550-cell version was discarded.
A single number called "maximum characters per screen" would conceal the distinction. The contributor constructed an empirical load model using written cells plus a penalty for larger gaps between them in screen order. It explains the measured cases without requiring access to DJI's renderer implementation. The exact internal limit and reason for the gap penalty remain unknown.
The test also found that writing spaces consumes capacity, and overwriting existing cells does not automatically release it. MSP_DP_CLEAR_SCREEN is the effective reset. Once a frame crossed the measured limit, the receiver discarded the whole draw operation and displayed the preceding frame. That is why a dense layout can appear to freeze rather than merely lose the last widget.
These figures are observations from one hardware and firmware combination. They should not be extrapolated to another air unit, a newer goggles build, Walksnail or HDZero without equivalent measurements.
Why the fix trades completeness for freshness
The proposed Betaflight driver tracks occupied cells and calculates a frame-load estimate. It skips spaces that would leave already blank cells unchanged and allows a configurable displayport_msp_cell_budget, with 620 proposed as the default for the 53-by-20 canvas.
When a frame exceeds that budget, the driver drops subsequent writes so the receiver can draw a partial current screen. The PR says battery, RSSI, timers and warnings are drawn earlier, while GPS and waypoint elements tend to appear later. That ordering gives some important values a better chance of surviving overload, but it is an implementation detail, not a certified priority mechanism. A differently arranged layout or future rendering change could alter what goes missing.
A conservative budget is an engineering compromise. A lower value leaves more headroom for the receiver but may omit legitimate information. A larger value can preserve detail until the point where the device refuses the entire frame. The proposed driver exposes debug data about estimated load and dropped writes, making that trade-off observable during testing rather than invisible in flight.
For the reported benchmark layouts, the author says a formerly rejected OSD could be drawn with omissions or with smaller segmented writes after the initial screen. The feature also increases flash and RAM use: the report lists about 1.4 KB extra flash and 184 to 196 bytes of extra RAM on two test targets. On small flight controllers, those costs still matter. None of these changes should be assumed to be present in a stable Betaflight firmware build until the release history confirms it.
Serial bandwidth and renderer capacity are separate limits
Even an OSD whose spatial load is acceptable can arrive too slowly. The PR's device tests reported roughly 30 to 40 DRAW_SCREEN operations per second, with fast submission rates accumulating seconds of delay. A dense full-page draw at 115200 baud was reported as limited to around eight updates per second by the serial link.
The causal paths differ:
- UART or protocol congestion: the receiving device gets a late or incomplete sequence of DisplayPort commands. Check actual UART assignment, baud rate, write volume and competing MSP traffic.
- Renderer load rejection: the device receives the draw request but retains the older screen when the frame is too complex. Simplifying spatial layout can help even when serial throughput is unchanged.
- Missing or mismatched rendering configuration: a wrong display mode or font page may hide warnings even though the data arrives. This is a separate visual problem, not proof of a frozen frame.
Betaflight's setup guide identifies the VTX (MSP + DisplayPort) port configuration. Its SoftSerial documentation explicitly warns against using SoftSerial for HD MSP OSD on the versions it discusses. A physical UART is the relevant baseline for diagnosing high-rate character output.
If someone tests only a sparse OSD layout, none of these bottlenecks may appear. Adding map coordinates, multiple warnings or densely spaced labels can change the outcome without changing the receiver, flight controller or radio power.
A second trap: the goggles' display mode
The same bench report found different limits when the Goggles 2 menu was set to INAV rather than Betaflight. Solid 53-cell rows reportedly reached 537 cells shown in INAV mode, versus 637 in the Betaflight mode. The author also observed that the default Betaflight multi-font-page mapping could make warning text absent or nonsensical in INAV mode because some requested pages were blank.
The PR proposes an approximately 520-cell budget for that particular INAV-mode test setup and describes using page zero for all four font slots. These are contributor-specific workarounds, not generally safe instructions for other goggles. The underlying lesson is simpler: the FC cannot assume that a menu option on the goggles has the rendering behavior or font map it expects. Betaflight's HD OSD release notes already caution that digital VTX and goggle combinations differ in supported features.
A warning that is transmitted but drawn with an empty glyph is operationally similar to a warning that was never transmitted. This deserves separate bench testing.
How to test the display without confusing it with the control link
A sensible bench investigation begins with propellers removed and a saved record of the original configuration. Use a visibly changing timer or value, then compare the goggles to the Configurator or another independently updated instrument. A frozen value is more diagnostic than a static home arrow.
Record the flight-controller version, air-unit and goggles firmware, the goggles' flight-controller display mode, selected OSD profile, UART settings and canvas. Reproduce the same layout before changing anything. If the OSD freezes only when elements are added, reduce the layout in steps; compare compact groups of text with widely separated elements. A change in outcome can identify a display-complexity threshold, but it does not alone identify a specific renderer bug.
Next, distinguish stale values from absent ones. A stopped timer accompanied by moving video is consistent with a rejected screen or delayed OSD channel. Missing icons in an otherwise updating screen point more toward font selection, unsupported glyphs or positional overlap with the goggles' own widgets. On the tested O3/Goggles 2 setup, the PR maps areas where the goggles draw their own information on top of FC-originated text. That map may shift on other releases.
Finally, validate warnings as warnings. Simulating a battery threshold or deliberately provoking a benign configuration warning on a grounded aircraft is more useful than assuming a decorative voltage readout proves warning visibility. Restore all test changes before flight and keep primary flight-safety decisions grounded in the actual aircraft state, not a possibly stale overlay.
What remains unproven
The proposed 620-cell rule is an empirical fit to one equipment combination, not a documented DJI renderer contract. No systematic cross-device test is presented for Walksnail or WTFOS; the author says HDZero advertises a different canvas and was not tested for the same failure. The report does not quantify in-flight prevalence or establish that a particular version caused a real-world loss.
Still, the result is a useful systems lesson. A flight controller can generate correct warnings, a serial link can transmit valid commands, and a video receiver can display flawless moving images while the human-facing numbers remain old. The only convincing display check is end-to-end: verify that the particular goggles actually render current, readable safety information under the most demanding layout the pilot intends to use.