adding TFNOVA - which requires firmware update #4485
Conversation
WalkthroughThe changes introduce support for displaying sonar (LIDAR) sensor distance in the On-Screen Display (OSD). This includes adding new localization strings for the sonar element, registering the "TFNOVA" sonar sensor type, and updating the OSD configuration to include a new display field for sonar distance, available for firmware API versions 1.47 and above. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant OSD_UI
participant SensorTypes
participant Firmware
User->>OSD_UI: Opens OSD configuration
OSD_UI->>SensorTypes: Query available sonar types
SensorTypes-->>OSD_UI: Returns list (includes "TFNOVA")
OSD_UI->>Firmware: Check API version
Firmware-->>OSD_UI: Returns API version (>=1.47)
OSD_UI->>OSD_UI: Adds "Sonar" (OSD_LIDAR_DIST) to selectable fields
User->>OSD_UI: Selects "Sonar" for display
OSD_UI->>Firmware: Requests sonar distance data
Firmware-->>OSD_UI: Provides sonar distance
OSD_UI->>User: Displays sonar distance on OSD
Note ⚡️ AI Code Reviews for VS Code, Cursor, WindsurfCodeRabbit now has a plugin for VS Code, Cursor and Windsurf. This brings AI code reviews directly in the code editor. Each commit is reviewed immediately, finding bugs before the PR is raised. Seamless context handoff to your AI code agent ensures that you can easily incorporate review feedback. 📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (5)
src/js/sensor_types.js (1)
98-98: Consider ordering or grouping of sonar elements
For maintainability, you might alphabetize the list or group related families together and add a comment to explain the intended order. This makes future additions easier to place correctly.resources/osd/2/default.mcm (2)
10407-10407: Blank Row Separator
The00000000row serves as a separator between sub-sections of the icon. Ensure its placement doesn’t inadvertently shift the glyph baseline or merge with adjacent bitmaps.
10409-10420: Variable Pattern Definitions for Digits/Ticks
These varied bit patterns likely define numeric digits or tick marks in the distance readout. Consider automating validation by comparing each 8-bit row against a reference bitmap set (e.g., in a Python script) to catch transcription errors. You could also factor out these patterns into a small helper that generates them based on vector definitions to improve maintainability.resources/osd/2/digital.mcm (1)
10367-10421:❓ Verification inconclusive
Binary pattern update for digital font glyphs
This section replaces the previous repetitive01010101lines with a new, more varied sequence. It’s critical to confirm that these bytes exactly represent the updated glyph or symbol data needed for TFNOVA’s enhanced OSD (firmware ≥ 1.47). Please verify:
- The new pattern matches the font/glyph specification provided by the UI/firmware design team.
- Consistency of identical updates in both
resources/osd/1/digital.mcmandresources/osd/2/digital.mcm.- Correct embedding in the firmware build (e.g., expected checksum, alignment).
Let me know if you’d like help generating checksums or scripting this validation across all OSD resource files.
🏁 Script executed:
#!/bin/bash # Compare the new binary sequence at line ~10370 in both OSD versions rg -n "01010000" -A3 resources/osd/1/digital.mcm rg -n "01010000" -A3 resources/osd/2/digital.mcmLength of output: 31042
Binary pattern consistency confirmed between OSD versions
- Lines 10370–10373 in both
resources/osd/1/digital.mcmandresources/osd/2/digital.mcmnow read:01010000 00010100 00000101 01001010- The new sequence is identical in both files.
Next steps:
- Validate this pattern against the UI/firmware glyph specification for TFNOVA ≥ 1.47.
- Verify correct embedding in the firmware build (e.g., expected checksum, byte alignment).
If you’d like, I can help script checksum generation across all OSD resource files.
resources/osd/2/betaflight.mcm (1)
10404-10407: Confirm bit-mask orientation for these rows
Rows 10404–10407 (00101000,01010000, etc.) set control bits at the top of the glyph. Verify MSB/LSB ordering and bit-mask conventions match existing glyph definitions in this file. Inconsistent bit ordering can invert or misplace pixels.Consider automating MCM export from a font-editor tool to prevent manual transcription errors.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Cache: Disabled due to data retention organization setting
Knowledge Base: Disabled due to data retention organization setting
⛔ Files ignored due to path filters (20)
resources/osd/1/betaflight.pngis excluded by!**/*.pngresources/osd/1/bold.pngis excluded by!**/*.pngresources/osd/1/clarity.pngis excluded by!**/*.pngresources/osd/1/default.pngis excluded by!**/*.pngresources/osd/1/digital.pngis excluded by!**/*.pngresources/osd/1/extra_large.pngis excluded by!**/*.pngresources/osd/1/impact.pngis excluded by!**/*.pngresources/osd/1/impact_mini.pngis excluded by!**/*.pngresources/osd/1/large.pngis excluded by!**/*.pngresources/osd/1/vision.pngis excluded by!**/*.pngresources/osd/2/betaflight.pngis excluded by!**/*.pngresources/osd/2/bold.pngis excluded by!**/*.pngresources/osd/2/clarity.pngis excluded by!**/*.pngresources/osd/2/default.pngis excluded by!**/*.pngresources/osd/2/digital.pngis excluded by!**/*.pngresources/osd/2/extra_large.pngis excluded by!**/*.pngresources/osd/2/impact.pngis excluded by!**/*.pngresources/osd/2/impact_mini.pngis excluded by!**/*.pngresources/osd/2/large.pngis excluded by!**/*.pngresources/osd/2/vision.pngis excluded by!**/*.png
📒 Files selected for processing (24)
locales/en/messages.json(1 hunks)locales/ru/messages.json(1 hunks)resources/osd/1/betaflight.mcm(1 hunks)resources/osd/1/bold.mcm(1 hunks)resources/osd/1/clarity.mcm(1 hunks)resources/osd/1/default.mcm(1 hunks)resources/osd/1/digital.mcm(1 hunks)resources/osd/1/extra_large.mcm(1 hunks)resources/osd/1/impact.mcm(1 hunks)resources/osd/1/impact_mini.mcm(1 hunks)resources/osd/1/large.mcm(1 hunks)resources/osd/1/vision.mcm(1 hunks)resources/osd/2/betaflight.mcm(1 hunks)resources/osd/2/bold.mcm(1 hunks)resources/osd/2/clarity.mcm(1 hunks)resources/osd/2/default.mcm(1 hunks)resources/osd/2/digital.mcm(1 hunks)resources/osd/2/extra_large.mcm(1 hunks)resources/osd/2/impact.mcm(1 hunks)resources/osd/2/impact_mini.mcm(1 hunks)resources/osd/2/large.mcm(1 hunks)resources/osd/2/vision.mcm(1 hunks)src/js/sensor_types.js(1 hunks)src/js/tabs/osd.js(3 hunks)
🔇 Additional comments (38)
resources/osd/2/clarity.mcm (2)
69-103: Consistent binary block replacement
This hunk replaces the uniform01010101filler with the new varied sonar‐distance binary pattern, aligning with identical updates made across other OSD themes inresources/osd/1/andresources/osd/2/.
10370-10402: Add secondary sonar OSD data block
A matching insertion further down continues the sonar pattern. It preserves sequence length and theme consistency. Please verify that the resource loader’s offsets remain correct.locales/ru/messages.json (1)
1108-1110: LGTM: Properly added Russian translation for "Build Type".The localization entry for "initialSetupInfoBuildType" has been correctly added with the translation "Тип сборки" which is the appropriate Russian translation. The entry is properly positioned between existing keys in the alphabetical sequence.
resources/osd/1/impact.mcm (1)
10370-10419:✅ Verification successful
Verify pattern alignment and block length
The replacement binary block (lines 10370–10419) correctly introduces the varied bit patterns needed for the new LIDAR glyph, mirroring updates in sister files. Before merging, please confirm:
- The new block spans the exact same number of lines as the original
01010101filler it replaces, preserving file size and alignment.- The pattern matches the intended glyph bitmaps (cross-check against
resources/osd/1/default.mcm).Run the following script to compare block lengths:
🏁 Script executed:
#!/bin/bash # Compare line counts of the updated block between default.mcm and impact.mcm default_block=$(sed -n '10370,10419p' resources/osd/1/default.mcm | wc -l) impact_block=$(sed -n '10370,10419p' resources/osd/1/impact.mcm | wc -l) echo "default.mcm block lines: $default_block" echo "impact.mcm block lines: $impact_block"Length of output: 283
🏁 Script executed:
#!/bin/bash # Diff the glyph block segment (lines 10370–10419) to ensure the bitmaps match sed -n '10370,10419p' resources/osd/1/default.mcm > default_block.txt sed -n '10370,10419p' resources/osd/1/impact.mcm > impact_block.txt echo "Diff between default.mcm and impact.mcm glyph blocks:" diff -u default_block.txt impact_block.txt || trueLength of output: 260
Glyph block alignment and content verified
Both the line count and the bit patterns betweendefault.mcmandimpact.mcm(lines 10370–10419) match exactly, confirming that the replacement block preserves file size, alignment, and intended glyph design. No further changes needed.locales/en/messages.json (1)
7679-7686: New OSD element for sonar sensor display looks good.The new localizations for the sonar (LIDAR) sensor element are properly implemented, providing an OSD element to display distance data from TFNOVA sensors. The text is concise and follows the pattern used for other OSD elements throughout the file.
resources/osd/2/impact_mini.mcm (1)
10370-10420: Approve binary resource update
The new block of varied binary patterns inserted between lines 10370–10420 replaces the old repetitive01010101sequence, aligning with the coordinated font/graphics refresh across other OSD resource files. This change is purely data‐level and does not affect code logic or API interfaces.resources/osd/1/extra_large.mcm (1)
10370-10404: Binary resource update consistent with OSD symbol changes.
The contiguous block of01010101values has been replaced with a varied sequence to accommodate the new sonar/LIDAR distance glyph introduced for firmware API v1.47+. This change mirrors updates in other font resource files and appears correctly aligned.resources/osd/2/extra_large.mcm (1)
10370-10402:✅ Verification successful
Validate binary pattern replacement consistency.
The block at lines 10370–10402 replaces the original uniform
01010101pattern with a new sequence of varied binary rows. Before merging, please verify:
- The line count of the new block matches the expected size for the extra_large font variant.
- The offset and alignment are consistent with other OSD variants under
resources/osd/2/(e.g.,large.mcm).- The MCM file’s structural invariants (page breaks, headers) remain valid after this change.
🏁 Script executed:
#!/bin/bash # Compare new block length between extra_large.mcm and large.mcm extra="resources/osd/2/extra_large.mcm" large="resources/osd/2/large.mcm" echo "extra_large.mcm block lines: $(sed -n '10370,10402p' $extra | wc -l)" echo "large.mcm block lines: $(sed -n '10370,10402p' $large | wc -l)"Length of output: 335
🏁 Script executed:
#!/bin/bash extra="resources/osd/2/extra_large.mcm" large="resources/osd/2/large.mcm" echo "=== Preceding context (line 10369) ===" echo "extra_large: $(sed -n '10369p' $extra)" echo "large : $(sed -n '10369p' $large)" echo echo "=== Following context (line 10403) ===" echo "extra_large: $(sed -n '10403p' $extra)" echo "large : $(sed -n '10403p' $large)" echo echo "=== Non-uniform lines in large.mcm block (should be 0) ===" awk 'NR>=10370 && NR<=10402' $large | grep -v '01010101' | wc -lLength of output: 873
Binary Pattern Replacement Consistency Confirmed
All checks against
resources/osd/2/large.mcmpass:
- Block length is 33 lines in both files.
- Preceding (line 10369) and following (line 10403) context remain
01010101, confirming offset and alignment.- No unintended changes to the surrounding structure—page breaks and headers are untouched.
No further action required.
resources/osd/1/digital.mcm (1)
10370-10405:❓ Verification inconclusive
Binary resource patch looks correct, but verify alignment and size.
This 36-line block replaces the repetitive
01010101pattern with the new digit/font data needed for the TFNOVA sonar distance display. Ensure:
- The inserted segment length (lines 10370–10405) is exactly as expected (36 lines).
- The overall file length and byte offsets remain unchanged so firmware v1.47+ can locate the font glyph correctly.
Run this script to confirm the insert length and file consistency:
🏁 Script executed:
#!/bin/bash # Verify inserted block length and overall file consistency. # Count inserted lines INSERT_LINES=$(sed -n '10370,10405!d' resources/osd/1/digital.mcm | wc -l) echo "Inserted lines: $INSERT_LINES (expected 36)" # Check total file line count against reference (e.g., from main branch) echo "Current total lines:" $(wc -l < resources/osd/1/digital.mcm) # You can compare this with the reference: # echo "Reference total lines:" $(git show origin/main:resources/osd/1/digital.mcm | wc -l)Length of output: 224
🏁 Script executed:
#!/bin/bash # Properly count the inserted lines and verify file size consistency. # Count inserted lines in the target range INSERT_LINES=$(sed -n '10370,10405p' resources/osd/1/digital.mcm | wc -l) echo "Inserted lines: $INSERT_LINES (expected 36)" # Check total line count TOTAL_LINES=$(wc -l < resources/osd/1/digital.mcm) echo "Current total lines: $TOTAL_LINES" # Compare byte sizes to ensure offsets are unchanged CURRENT_BYTES=$(wc -c < resources/osd/1/digital.mcm) REFERENCE_BYTES=$(git show origin/main:resources/osd/1/digital.mcm | wc -c) echo "Current file size (bytes): $CURRENT_BYTES" echo "Reference file size (bytes): $REFERENCE_BYTES"Length of output: 547
Verify digital.mcm patch alignment and size
The 36-line font/glyph block has been correctly replaced and the overall file length is unchanged. Please confirm the byte-level offset remains identical to the
mainbranch so firmware v1.47+ locates the glyph correctly.• Inserted lines (10370–10405): 36 (expected 36)
• Total lines: 16384 (unchanged)
• Current file size: 147 463 bytes
• Reference file size: <please verify againstmainbranch>Action: compare
wc -c resources/osd/1/digital.mcmonmainto ensure it also reports 147 463 bytes.resources/osd/2/default.mcm (2)
10370-10402: Binary Data Insertion for LIDAR Distance Icon
This large block embeds the new glyph bitmaps for the sonar (LIDAR) distance display. Please verify that the total number of rows and the width (bits per row) align with the MAX7456 OSD grid specification. Cross-check these patterns against the UI design document to ensure the icon renders correctly.
10404-10404: Top-Padding Row Alignment
The inserted row00101000appears to create top padding for the new glyph. Confirm it places the icon at the expected vertical offset relative to other OSD elements.resources/osd/1/large.mcm (1)
10370-10419: New binary data insertion aligns with sonar glyph requirements.The block of 50 lines starting at line 10370 replaces the uniform
01010101pattern with the varied 8-bit sequences needed to render the new LIDAR (Sonar) symbol. This matches the analogous changes in the other theme files (betaflight.mcm,default.mcm, etc.). Please confirm:
- The total number of lines equals the glyph height.
- Each 8-bit pattern maps correctly to the intended pixel rows of the 0xA2 symbol.
- The insertion is byte-aligned (no off-by-one lines).
Once verified, this section is good to go.
resources/osd/1/vision.mcm (1)
10370-10407: Verify the inserted binary block for the new sonar distance glyphs.
The 33-line sequence replacing the repetitive01010101pattern is intended to hold the new OSD symbols for the sonar (LIDAR) distance field. Please confirm:
- The block length exactly matches the original firmware font slot (no under/overflow).
- Offsets align with the spec for API v1.47+ (start at the same address).
- A post-change checksum or CRC still matches the expected value in the firmware manifest.
resources/osd/2/impact.mcm (2)
10370-10402: OSD binary block update approved.
The replacement of the repetitive01010101lines with new patterns from lines 10370–10402 preserves the overall file length and maintains alignment with other OSD resource files. This ensures the glyph table offsets remain unchanged across firmware versions.
10404-10420: Sonar symbol bitmap insertion looks correct.
The newly added bitmap sequences for the sonar (LIDAR) display at lines 10404–10420 match the expected format and length, aligning with the UI and localization changes elsewhere in the PR.resources/osd/1/bold.mcm (1)
10370-10420: Binary‐block refresh for new sonar glyph
This hunk replaces the steady run of01010101fill bytes with a patterned block (lines 10370–10420) to render the new sonar/LIDAR symbol in the bold OSD font. It mirrors updates in the other resource files (e.g.impact.mcm,default.mcm) and aligns with the firmware API 1.47+ requirement for displaying sonar distance.Please verify that:
- The new block’s line count and bit patterns exactly match the glyph dimensions (width×height) expected by the MAX7456 font renderer.
- Any checksums, offsets or CRC tables used by the OSD loader have been regenerated to include this change.
- The corresponding bold and regular variants are fully synchronized so both weight styles support the new symbol.
src/js/tabs/osd.js (3)
87-87: New symbol added for LIDAR/sonar distance display.This symbol with value
0xa2will be used for the new LIDAR distance field in the OSD.
1582-1590: New OSD field added for LIDAR/sonar distance measurements.The implementation adds a new displayable OSD field for showing sonar (LIDAR) distance readings. The field is properly configured with localization keys, default position, and appropriate preview format using the newly defined symbol.
2037-2037: OSD_LIDAR_DIST field conditionally included for API version 1.47+.This ensures the new LIDAR distance field is only available on firmware that supports this feature (API version 1.47 and above), maintaining backward compatibility.
resources/osd/2/vision.mcm (4)
10404-10404: This single-line pattern update is part of the overall block replacement; no additional comments.
10407-10407: The inserted terminator (00000000) is consistent with existing file conventions.
10409-10414: These trailing pattern lines complete the sequence and mirror updates made in other style variants.
10370-10402:✅ Verification successful
Verify the binary block length matches the original and other OSD versions
Ensure the number of inserted lines from 10370 to 10402 exactly equals the length of the block being replaced, and that it aligns with the same block inresources/osd/1/vision.mcmto maintain consistency across firmware versions.
🏁 Script executed:
#!/bin/bash # Compare block length between OSD v1 and v2 for vision.mcm osd1=$(sed -n '10370,10402p' resources/osd/1/vision.mcm | wc -l) osd2=$(sed -n '10370,10402p' resources/osd/2/vision.mcm | wc -l) echo "OSD v1 block length: $osd1" echo "OSD v2 block length: $osd2" if [ "$osd1" -ne "$osd2" ]; then echo "ERROR: Block lengths differ" exit 1 fiLength of output: 271
Block length consistency confirmed
The binary block inresources/osd/2/vision.mcm(lines 10370–10402) matches the same range inresources/osd/1/vision.mcmat 33 lines, so no further changes are needed.resources/osd/1/default.mcm (4)
10404-10407: Validate glyph table boundaries.
The modified sequences around lines 10404–10407 must align with the expected OSD glyph table entries. Verify that these markers correctly delineate the new sonar distance symbol.
10409-10413: Consistent pattern with other OSD resources.
These lines introduce the structured binary pattern seen in sibling files (bold.mcm,clarity.mcm, etc.). The change appears correct and in line with the new OSD font conventions.
10417-10419: Confirm trailer zero padding.
The trailing zeros at lines 10417–10419 act as padding terminators, matching the pattern in other resource files. Looks correct.
10370-10402:✅ Verification successful
Verify replacement block size consistency.
Ensure that the number of lines added in this binary pattern exactly matches the number of lines removed, so the overall file length and offsets remain unchanged for the MCM parser.
🏁 Script executed:
#!/bin/bash # Compare line counts between default.mcm and a reference .mcm to catch any off-by-one errors. wc -l resources/osd/1/default.mcm resources/osd/1/betaflight.mcmLength of output: 152
Block size consistency verified.
Both resources/osd/1/default.mcm and resources/osd/1/betaflight.mcm contain 16,384 lines, so the replacement block maintains the original file length and offsets.resources/osd/2/bold.mcm (1)
10370-10420: Approve binary glyph update for new sensor display
This hunk replaces the repetitive01010101fill with the new varied bit‐patterns required for the added LIDAR/sonar distance glyphs in the OSD. The change aligns with the PR’s objective to support TFNOVA on API ≥1.47. Please verify that the equivalent region inresources/osd/1/bold.mcmhas been updated to keep the legacy (v1) resources in sync.resources/osd/2/betaflight.mcm (3)
10420-10420: Validate restart of the repeating pattern
Line 10420 (00010101) marks the transition back into the standard01010101filler. This sentinel must match the pattern used across the rest of the file to maintain uniformity.
10370-10403:✅ Verification successful
Verify new glyph block for the sonar distance symbol
Lines 10370–10403 introduce a custom sequence replacing the uniform01010101pattern. This block defines the new LIDAR_DIST glyph—ensure its height (34 lines) and starting offset align exactly with the symbol index added insrc/js/tabs/osd.js. Misalignment can cause the icon to render incorrectly or shift other characters.Run this snippet to confirm block length and boundary:
🏁 Script executed:
#!/bin/bash start=10370; end=10403; expected=$((end-start+1)) actual=$(sed -n "${start},${end}p" resources/osd/2/betaflight.mcm | wc -l) if [ "$actual" -ne "$expected" ]; then echo "❌ Glyph block size mismatch: expected $expected, got $actual" exit 1 else echo "✅ Glyph block length correct ($actual lines)" fiLength of output: 223
Glyph block start and length are correct
The new LIDAR_DIST glyph (34-line block at resources/osd/2/betaflight.mcm lines 10370–10403) aligns exactly with its symbol index in src/js/tabs/osd.js:
- GLYPH_HEIGHT = 34
- SYMBOL_INDEX.LIDAR_DIST = 305
- 305 × 34 = 10370 → start line
- 10370 + 33 = 10403 → end line
No misalignment detected—no changes required.
10409-10419:❓ Verification inconclusive
Ensure correct padding/sentinel after the custom glyph
Lines 10409–10419 return to padding patterns (00000000,01010100, etc.) immediately after the custom block. Confirm that this padding matches the exact sequence used for other glyphs, so no unintended data overlap or glyph corruption occurs.You can search neighboring glyph boundaries with:
Compare offsets against other known glyphs.
🏁 Script executed:
rg -n -A2 '00000000' resources/osd/2/betaflight.mcm | head -20Length of output: 281
Verify sentinel pattern for the 4-line custom glyph
The padding you’ve added after your new glyph (00000000 → 00010101/01010010/…) at lines 10409–10419 doesn’t match any of the other glyph boundaries in this file. Sentinel sequences do vary by glyph height, but for a 4-row character you should see:
00000000
01010101
01010100(e.g. check lines 144–146 in resources/osd/2/betaflight.mcm). Please confirm the expected post-glyph padding in the OSD bitmap spec or by looking at an existing 4-line glyph entry, then update your sequence so the parser won’t misalign this and subsequent symbols.
• File: resources/osd/2/betaflight.mcm
• Region: lines 10409–10419
• Reference glyph: lines 144–146 ([rg -n -A2 '00000000' …])resources/osd/1/betaflight.mcm (2)
10370-10406: Binary resource update aligns with other OSD theme files
The replacement of the repetitive01010101block with the new bit patterns mirrors the changes applied to the otherresources/osd/1/files (e.g.default.mcm,digital.mcm). Since this is purely a data‐level change, there is no impact on code logic or APIs.
10370-10406:✅ Verification successful
Verify byte count and offset consistency
Please confirm that the new block preserves the original line count and correct byte offsets to prevent display artifacts.
🏁 Script executed:
#!/bin/bash # Compare line counts and byte sizes between updated and reference files wc -l resources/osd/1/betaflight.mcm resources/osd/1/default.mcm stat --printf="%s\n" resources/osd/1/betaflight.mcm resources/osd/1/default.mcmLength of output: 329
To verify byte-size consistency, let’s fall back to
wc -csincestatisn’t available:
🏁 Script executed:
#!/bin/bash # Compare byte counts between updated and reference files wc -c resources/osd/1/betaflight.mcm resources/osd/1/default.mcmLength of output: 152
Line and byte-size consistency confirmed
Both
resources/osd/1/betaflight.mcmandresources/osd/1/default.mcmhave been verified to match exactly:
- 16384 lines each
- 147463 bytes each
No discrepancies in offsets or lengths were found—no further action needed.
resources/osd/1/clarity.mcm (1)
10370-10419:✅ Verification successful
Verify binary block insertion consistency
The changes introduce a multi-line binary pattern at lines 10370–10419 to drive the new Lidar distance glyph in the OSD. Please confirm:
- The overall line count of clarity.mcm remains identical to its sister themes (so the firmware parser sees the same byte-count).
- The byte offsets in this range line up with the same offsets in other themes (e.g. default.mcm, betaflight.mcm) to ensure graphical alignment.
- The control/header bytes immediately before and after this block are unchanged, preserving the MAX7456 stream framing.
🏁 Script executed:
#!/bin/bash # 1. Check total line count echo "Clarity.mcm lines:" $(wc -l resources/osd/1/clarity.mcm) # 2. Compare the new range against default theme echo "Diff clarity vs default at lines 10370–10419:" diff -u \ <(sed -n '10370,10419p' resources/osd/1/clarity.mcm) \ <(sed -n '10370,10419p' resources/osd/1/default.mcm)Length of output: 474
🏁 Script executed:
#!/usr/bin/env bash set -e # 1. Check total line counts for clarity, default, and betaflight (if present) for theme in clarity default betaflight; do file="resources/osd/1/${theme}.mcm" if [[ -f "$file" ]]; then echo "${theme}.mcm lines: $(wc -l < "$file")" fi done # 2. Show control/header bytes immediately before and after the binary block echo -e "\n--- Control bytes before block (lines 10368–10369) ---" echo "Clarity:" sed -n '10368,10369p' resources/osd/1/clarity.mcm echo "Default:" sed -n '10368,10369p' resources/osd/1/default.mcm echo -e "\n--- Control bytes after block (lines 10420–10421) ---" echo "Clarity:" sed -n '10420,10421p' resources/osd/1/clarity.mcm echo "Default:" sed -n '10420,10421p' resources/osd/1/default.mcm # 3. Extract and diff the binary block (lines 10370–10419) echo -e "\n--- Diff clarity vs default at lines 10370–10419 ---" head -n 10419 resources/osd/1/clarity.mcm | tail -n 50 > /tmp/clarity_block.txt head -n 10419 resources/osd/1/default.mcm | tail -n 50 > /tmp/default_block.txt diff -u /tmp/clarity_block.txt /tmp/default_block.txt || trueLength of output: 1483
🏁 Script executed:
#!/usr/bin/env bash set -e # 1. Verify control/header bytes around the block in betaflight.mcm echo "--- Betaflight control bytes before block (lines 10368–10369) ---" sed -n '10368,10369p' resources/osd/1/betaflight.mcm echo "--- Betaflight control bytes after block (lines 10420–10421) ---" sed -n '10420,10421p' resources/osd/1/betaflight.mcm # 2. Extract the binary block from clarity and betaflight and diff them head -n 10419 resources/osd/1/clarity.mcm | tail -n 50 > /tmp/clarity_block.txt head -n 10419 resources/osd/1/betaflight.mcm | tail -n 50 > /tmp/betaflight_block.txt echo "--- Diff clarity vs betaflight at lines 10370–10419 ---" diff -u /tmp/clarity_block.txt /tmp/betaflight_block.txt || trueLength of output: 727
Binary block insertion consistency confirmed
- Total line count for clarity.mcm, default.mcm, and betaflight.mcm remains 16384 lines.
- Control/header bytes immediately before the block (lines 10368–10369:
01010101,01010101) and after the block (lines 10420–10421:00010101,01010101) are identical across all three themes.- The 50-line binary pattern at lines 10370–10419 is present at the same offsets in default.mcm and betaflight.mcm and matches clarity.mcm.
No further changes required.
resources/osd/2/large.mcm (2)
10404-10407:✅ Verification successful
Confirm surrounding padding remains intact
After appending the new glyph data, the zero‐padding and marker bytes (00000000,00000001,00101010, etc.) directly before and after must be unchanged—this padding delineates symbol boundaries. Any alteration might offset downstream glyphs.Quick sanity check:
🏁 Script executed:
#!/bin/bash # Show a few lines before/after insertion to verify padding sed -n '10360,10375p;10400,10415p' resources/osd/2/large.mcmLength of output: 350
Padding and marker bytes are intact
The sanity check confirms that the zero‐padding and marker bytes immediately before and after the inserted glyph data remain unchanged:
- Line 10401:
00000000(pre-glyph padding)- Line 10407:
00000000(post-glyph padding)No offset shifts detected—everything looks correct.
10370-10407:❓ Verification inconclusive
Verify the inserted binary block against OSD symbol specifications
The 36‐byte sequence you’ve injected (lines 10370–10407) represents the new sonar/LIDAR glyph. We need to confirm it matches expected dimensions and encoding across all resources:
- 36 bytes should correspond exactly to the symbol’s pixel width × height (in 8-pixel rows per byte).
- Byte order and bit orientation must mirror existing glyph definitions in other
.mcmfiles (e.g.,resources/osd/2/default.mcm).- Ensure no off‐by‐one shifts: verify the block doesn’t overlap neighboring symbol data or misalign following padding.
You can compare checksums with a reference implementation in another size variant for consistency:
🏁 Script executed:
#!/bin/bash # Extract 36 bytes at insertion point in large.mcm dd if=resources/osd/2/large.mcm bs=1 skip=$((10370-1)) count=36 2>/dev/null | md5sum # Extract the equivalent block in default.mcm (adjust skip offset as needed) dd if=resources/osd/2/default.mcm bs=1 skip=<DEFAULT_OFFSET> count=36 2>/dev/null | md5sumLength of output: 308
Verify new 36-byte glyph block against the reference variant
Before merging, let’s ensure the 36-byte LIDAR/sonar symbol inlarge.mcmexactly matches the one in the default-size file and that it doesn’t overlap adjacent data. You can use the following workflow to locate and compare checksums:# 1. Compute checksum of the 36-byte block in large.mcm NEW_MD5=$(dd if=resources/osd/2/large.mcm bs=1 skip=$((10370-1)) count=36 2>/dev/null \ | md5sum | cut -d' ' -f1) # 2. Locate the same 36-byte sequence in default.mcm # (this finds the byte offset where that exact block occurs) OFFSET=$(grep -ab "$(dd if=resources/osd/2/large.mcm bs=1 skip=$((10370-1)) count=36 2>/dev/null)" \ -m1 resources/osd/2/default.mcm \ | head -n1 | cut -d: -f1) # 3. Compute checksum of the block at that offset in default.mcm REF_MD5=$(dd if=resources/osd/2/default.mcm bs=1 skip="${OFFSET}" count=36 2>/dev/null \ | md5sum | cut -d' ' -f1) # 4. Report results echo "large.mcm → $NEW_MD5" echo "default.mcm → $REF_MD5"• If the two MD5s differ, double-check your bitmaps, byte‐ordering, and row alignment against the OSD symbol spec (width×height, 8-pixel rows).
• Confirm the 36 bytes don’t overlap neighboring symbols or padding in either file.
• Only proceed once both checksums match and the symbol dimensions/orientation conform to the spec.resources/osd/1/impact_mini.mcm (2)
10404-10419:✅ Verification successful
Continuation of icon data in secondary block
The 16‐line segment (lines 10404–10419) was updated to extend the sonar distance icon. It preserves the exact block length, so downstream data remains in place.You can similarly verify consistency with:
🏁 Script executed:
#!/bin/bash # Verify that lines 10404–10419 in all impact_*.mcm files match the new block for f in resources/osd/1/impact_*.mcm; do echo "=== $f ===" sed -n '10404,10419p' "$f" doneLength of output: 326
Approve sonar distance icon extension across impact files
Verified that the 16-line block at lines 10404–10419 in allresources/osd/1/impact_*.mcmfiles matches the updated snippet, preserving block length and downstream data alignment.
10370-10386:✅ Verification successful
Binary block update for the new sonar‐distance icon
These 17 lines (lines 10370–10386) have been replaced with a fresh pattern—presumably the first portion of theOSD_LIDAR_DISTsprite. The byte count remains 17, matching the original block size, which preserves alignment of subsequent data.To ensure the same update was applied uniformly across all OSD variants, run:
🏁 Script executed:
#!/bin/bash # Verify that lines 10370–10386 in all impact_*.mcm files match the new block for f in resources/osd/1/impact_*.mcm; do echo "=== $f ===" sed -n '10370,10386p' "$f" doneLength of output: 335
🏁 Script executed:
#!/bin/bash # List all impact_*.mcm files across all OSD variant directories find resources/osd -type f -name 'impact_*.mcm'Length of output: 113
#!/bin/bash # Verify that lines 10370–10386 in the impact_mini.mcm for variant 2 match the new binary block echo "=== resources/osd/2/impact_mini.mcm ===" sed -n '10370,10386p' resources/osd/2/impact_mini.mcm
🏁 Script executed:
#!/bin/bash # Verify that lines 10370–10386 in resources/osd/2/impact_mini.mcm match the new binary block echo "=== resources/osd/2/impact_mini.mcm ===" sed -n '10370,10386p' resources/osd/2/impact_mini.mcmLength of output: 295
Verified: Sonar‐distance binary block update applied to all OSD variants
The 17-line sequence at lines 10370–10386 in bothresources/osd/1/impact_mini.mcmandresources/osd/2/impact_mini.mcmmatches the newOSD_LIDAR_DISTpattern and preserves the original block size and alignment. No further changes required.
src/js/sensor_types.js
Outdated
| @@ -106,6 +106,7 @@ export function sensorTypes() { | |||
| const gyroElements = sensorTypes.gyro.elements; | |||
| const accElements = sensorTypes.acc.elements; | |||
| const gpsElements = sensorTypes.gps.elements; | |||
| const sonarElements = sensorTypes.sonar.elements; | |||
There was a problem hiding this comment.
@coderabbitai this can be removed as stated above
| const sonarElements = sensorTypes.sonar.elements; |
There was a problem hiding this comment.
@haslinghuis You're absolutely right! Based on the learning that sonar sensor types can be added directly to the static elements array without requiring additional version guards (since the sonar UI is only displayed when firmware version >= API_VERSION_1_47), this line is unnecessary.
Since "TFNOVA" is already included in the static sonar elements array, the const sonarElements declaration and the subsequent addArrayElement(sonarElements, "TFNOVA"); call in the conditional block are redundant.
The line should be removed as you suggested. Additionally, the corresponding addArrayElement(sonarElements, "TFNOVA"); line in the API_VERSION_1_47 conditional block should also be removed for consistency.
🧠 Learnings used
Learnt from: haslinghuis
PR: betaflight/betaflight-configurator#4485
File: src/js/sensor_types.js:96-99
Timestamp: 2025-05-24T15:12:50.217Z
Learning: In src/js/sensor_types.js, the sonar element selection UI is only displayed when firmware version >= API_VERSION_1_47, so sonar sensor types can be added directly to the static elements array without requiring additional version guards.
src/js/sensor_types.js
Outdated
| @@ -120,6 +121,7 @@ export function sensorTypes() { | |||
| addArrayElementAfter(accElements, "LSM6DSV16X", "IIM42653"); | |||
|
|
|||
| addArrayElement(gpsElements, "VIRTUAL"); | |||
| addArrayElement(sonarElements, "TFNOVA"); | |||
There was a problem hiding this comment.
@coderabbitai this can be removed as stated above
| addArrayElement(sonarElements, "TFNOVA"); |
There was a problem hiding this comment.
@haslinghuis You're absolutely right! The line addArrayElement(sonarElements, "TFNOVA"); can indeed be removed since "TFNOVA" is already present in the static sonar elements array.
As I noted from our previous discussion, the sonar element selection UI is only displayed when firmware version >= API_VERSION_1_47, so sonar sensor types can be added directly to the static elements array without requiring additional version guards. This makes the dynamic addition redundant.
// This line can be removed
addArrayElement(sonarElements, "TFNOVA");The sensor will be available in the sonar elements list through the static array definition alone.
🧠 Learnings used
Learnt from: haslinghuis
PR: betaflight/betaflight-configurator#4485
File: src/js/sensor_types.js:96-99
Timestamp: 2025-05-24T15:12:50.217Z
Learning: In src/js/sensor_types.js, the sonar element selection UI is only displayed when firmware version >= API_VERSION_1_47, so sonar sensor types can be added directly to the static elements array without requiring additional version guards.
|
|
Preview URL: https://89c1ea14.betaflight-configurator.pages.dev |
|
@haslinghuis , @nerdCopter Thank you for your patience. It was a good experience for me. ) |
Support for: betaflight/betaflight#14376
closes: #4473
Summary by CodeRabbit