Raise the limit to display CRSF SNR values on OSD

[rmaia3d]

This simply raises the limit for the osd_snr_alarm setting, which controls when the SNR field (for CRSF based radio systems) is displayed on the OSD. The raised limit allows configuring the field to be constantly visible, if so desired, instead of only being visible when the SNR gets near a critical level.

Defaults are the same, so no behavior change is expected, unless the user explicitly sets the alarm threshold to a value higher than the previous limit.

[OptimusTi]

I'd change it to 30. Ratio is 1,000!

There's a reason why I used those default numbers in the code. 😉

Also, the filtering should be removed.

[OptimusTi]

Please change the max to 30.

[rmaia3d]

Please change the max to 30.

Done!!

[rmaia3d]

There's a reason why I used those default numbers in the code. 😉

I don't doubt it! That's why I left the defaults as they are. The whole idea was making it possible to have the SNR field permanently displayed with minimal changes to the code.

Also, the filtering should be removed.

Ok, I will do this as well.

[rmaia3d]

Also, the filtering should be removed.

Also done. :-)

[DzikuVx]

@rmaia3d This PR has the code that is not related to the change. No idea from where it got here but please resolve issues so only feature related code is included. Thanks

[rmaia3d]

@rmaia3d This PR has the code that is not related to the change. No idea from where it got here but please resolve issues so only feature related code is included. Thanks

No problem! That extra code probably sneaked itself in when the base branch was changed. I rebased my PR branch on master and it seems to have resolved. Please let me know if anything else is needed on my part.

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
⚪	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: No auditing: The new logic displaying SNR values does not add or modify any audit logging for critical actions, but this UI change may not require auditing; verify if display state changes require audit trails in this project. Referred Code int8_t snrVal = rxLinkStatistics.uplinkSNR; const char* showsnr = "-20"; const char* hidesnr = " "; if (snrVal > osdConfig()->snr_alarm) { if (cmsInMenu) { buff[0] = SYM_SNR; tfp_sprintf(buff + 1, "%s%c", showsnr, SYM_DB); } else { buff[0] = SYM_BLANK; tfp_sprintf(buff + 1, "%s%c", hidesnr, SYM_BLANK); } } else if (snrVal <= osdConfig()->snr_alarm) { buff[0] = SYM_SNR; if (snrVal <= -10) { tfp_sprintf(buff + 1, "%3d%c", snrVal, SYM_DB); } else { tfp_sprintf(buff + 1, "%2d%c%c", snrVal, SYM_DB, ' '); } } Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Boundary handling: New SNR rendering branches handle formatting around -10 but do not explicitly guard upper bounds or null stats; likely safe in this context but merits verification against possible out-of-range SNR values after raising max to 30. Referred Code } } else if (snrVal <= osdConfig()->snr_alarm) { buff[0] = SYM_SNR; if (snrVal <= -10) { tfp_sprintf(buff + 1, "%3d%c", snrVal, SYM_DB); } else { tfp_sprintf(buff + 1, "%2d%c%c", snrVal, SYM_DB, ' '); } Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Range increase: The osd_snr_alarm max was raised from 99 to 30 in settings and docs, reducing range; confirm this aligns with hardware/telemetry constraints and prevents invalid configuration after removing SNR filtering. Referred Code min: -20 max: 30 Learn more about managing compliance generic rules or creating your own custom rules

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label