HoTT telemetry improvements by Ralfde · Pull Request #11766 · iNavFlight/inav

Ralfde · 2026-08-07T11:55:07Z

faster response for telemetry.
The Graupner receivers where updated for faster telemetry since years. So it makes sense to use a faster telemetry frequency.
GPS telemetry data:
Home direction corrected
Flight direction added
Flight modes added to the free characters

This change would be also good for maintenance-9.x

test

add GPS sensor flight mode add GPS sensor flight direction

qodo-free-for-open-source-projects · 2026-08-07T11:55:15Z

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. ~~HRST counter never resets~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

hottPrepareGPSResponse() uses a function-static hrstSent counter to limit BOXHOMERESET (“HRST”)
display, but never resets it when the mode is released. After it reaches the limit once, later
home-reset activations will never show HRST again until reboot.

Code

src/main/telemetry/hott.c[R283-286]

+    static uint8_t hrstSent = 0;
+	hottGPSMessage->free_char1 = 79;	//"O";
+	hottGPSMessage->free_char2 = 75;	//"K";
+	hottGPSMessage->free_char3 = 51;	//"3";	32 " "

Evidence

The PR introduces a function-static hrstSent counter and increments it when BOXHOMERESET is
active, but there is no corresponding reset anywhere in the function; this makes the limiter
permanent. The CRSF telemetry code shows the expected lifecycle (reset when BOXHOMERESET becomes
inactive).

src/main/telemetry/hott.c[229-382]
src/main/telemetry/crsf.c[467-522]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`hrstSent` is a function-static counter used to rate-limit the "HRST" indication when `BOXHOMERESET` is active, but it is never reset when the mode becomes inactive. This permanently disables the HRST indication after the first limited run.
## Issue Context
A similar flight-mode text implementation resets `hrstSent` when `BOXHOMERESET` is not active, allowing each new activation to show the indication again.
## Fix Focus Areas
- src/main/telemetry/hott.c[229-382]
### Implementation notes
- After the flight-mode selection logic, add something like:
- `if (!IS_RC_MODE_ACTIVE(BOXHOMERESET) && hrstSent > 0) hrstSent = 0;`
- Optionally also reset `hrstSent` when disarmed to avoid carrying state across arm cycles.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. ~~Stale free-char status~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

hottPrepareGPSResponse() still returns early when there is no GPS fix, but the PR’s new
free_char1..3 status text is set after that return and is not cleared per call. After a GPS fix
drop, the HoTT GPS message can continue transmitting stale free_char values from a previous state.

Code

src/main/telemetry/hott.c[R284-286]

+	hottGPSMessage->free_char1 = 79;	//"O";
+	hottGPSMessage->free_char2 = 75;	//"K";
+	hottGPSMessage->free_char3 = 51;	//"3";	32 " "

Evidence

The GPS message is memset only during initialization. The existing no-fix early return remains, but
the PR added free_char updates after it; therefore those fields are not updated/cleared when the
no-fix return is taken, allowing stale values to persist across messages.

src/main/telemetry/hott.c[180-187]
src/main/telemetry/hott.c[241-249]
src/main/telemetry/hott.c[272-381]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The function returns early on `!STATE(GPS_FIX)` (or `!STATE(GPS_FIX) && !STATE(GPS_ESTIMATED_FIX)`), skipping the newly added free_char status updates. Because the message struct is reused across calls (not memset each time), the free_char bytes can retain stale values after GPS fix loss.
## Issue Context
`initialiseGPSMessage()` zeros the struct once at init; `hottPrepareGPSResponse()` mutates fields in-place and has an early return on no-fix.
## Fix Focus Areas
- src/main/telemetry/hott.c[180-187]
- src/main/telemetry/hott.c[229-381]
### Implementation notes
Choose one of:
1) Set a safe default for `free_char1..3` (e.g. blanks or "---" / "NOF") before the GPS-fix early return and also set them in the no-fix branch.
2) Move the free_char flight-mode/status computation above the GPS-fix early return so it always runs.
Also consider clearing `home_direction`/`flight_direction` in the no-fix path to avoid other stale fields.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. ~~HRST counter never resets~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

hottPrepareGPSResponse() uses a function-static hrstSent counter to limit BOXHOMERESET (“HRST”)
display, but never resets it when the mode is released. After it reaches the limit once, later
home-reset activations will never show HRST again until reboot.

Code

src/main/telemetry/hott.c[R283-286]

+    static uint8_t hrstSent = 0;
+	hottGPSMessage->free_char1 = 79;	//"O";
+	hottGPSMessage->free_char2 = 75;	//"K";
+	hottGPSMessage->free_char3 = 51;	//"3";	32 " "

Evidence

The PR introduces a function-static hrstSent counter and increments it when BOXHOMERESET is
active, but there is no corresponding reset anywhere in the function; this makes the limiter
permanent. The CRSF telemetry code shows the expected lifecycle (reset when BOXHOMERESET becomes
inactive).

src/main/telemetry/hott.c[229-382]
src/main/telemetry/crsf.c[467-522]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`hrstSent` is a function-static counter used to rate-limit the "HRST" indication when `BOXHOMERESET` is active, but it is never reset when the mode becomes inactive. This permanently disables the HRST indication after the first limited run.
## Issue Context
A similar flight-mode text implementation resets `hrstSent` when `BOXHOMERESET` is not active, allowing each new activation to show the indication again.
## Fix Focus Areas
- src/main/telemetry/hott.c[229-382]
### Implementation notes
- After the flight-mode selection logic, add something like:
- `if (!IS_RC_MODE_ACTIVE(BOXHOMERESET) && hrstSent > 0) hrstSent = 0;`
- Optionally also reset `hrstSent` when disarmed to avoid carrying state across arm cycles.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

View review recommended (1)

4. ~~Stale free-char status~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

hottPrepareGPSResponse() still returns early when there is no GPS fix, but the PR’s new
free_char1..3 status text is set after that return and is not cleared per call. After a GPS fix
drop, the HoTT GPS message can continue transmitting stale free_char values from a previous state.

Code

src/main/telemetry/hott.c[R284-286]

+	hottGPSMessage->free_char1 = 79;	//"O";
+	hottGPSMessage->free_char2 = 75;	//"K";
+	hottGPSMessage->free_char3 = 51;	//"3";	32 " "

Evidence

The GPS message is memset only during initialization. The existing no-fix early return remains, but
the PR added free_char updates after it; therefore those fields are not updated/cleared when the
no-fix return is taken, allowing stale values to persist across messages.

src/main/telemetry/hott.c[180-187]
src/main/telemetry/hott.c[241-249]
src/main/telemetry/hott.c[272-381]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The function returns early on `!STATE(GPS_FIX)` (or `!STATE(GPS_FIX) && !STATE(GPS_ESTIMATED_FIX)`), skipping the newly added free_char status updates. Because the message struct is reused across calls (not memset each time), the free_char bytes can retain stale values after GPS fix loss.
## Issue Context
`initialiseGPSMessage()` zeros the struct once at init; `hottPrepareGPSResponse()` mutates fields in-place and has an early return on no-fix.
## Fix Focus Areas
- src/main/telemetry/hott.c[180-187]
- src/main/telemetry/hott.c[229-381]
### Implementation notes
Choose one of:
1) Set a safe default for `free_char1..3` (e.g. blanks or "---" / "NOF") before the GPS-fix early return and also set them in the no-fix branch.
2) Move the free_char flight-mode/status computation above the GPS-fix early return so it always runs.
Also consider clearing `home_direction`/`flight_direction` in the no-fix path to avoid other stale fields.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Tip of the day

💡 Did you know, you can reply 'qodo' on any finding to push back, ask questions, or dig deeper

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

github-actions · 2026-08-07T11:55:18Z

Branch Targeting Suggestion

You've targeted the master branch with this PR. Please consider if a version branch might be more appropriate:

maintenance-9.x - If your change is backward-compatible and won't create compatibility issues between INAV firmware and Configurator 9.x versions. This will allow your PR to be included in the next 9.x release.
maintenance-10.x - If your change introduces compatibility requirements between firmware and configurator that would break 9.x compatibility. This is for PRs which will be included in INAV 10.x

If master is the correct target for this change, no action is needed.

This is an automated suggestion to help route contributions to the appropriate branch.

qodo-free-for-open-source-projects · 2026-08-07T11:57:03Z

PR Summary by Qodo

Increase HoTT telemetry rate and enrich GPS status fields

✨ Enhancement 🐞 Bug fix 🕐 20-40 Minutes

AI Description

• Speed up HoTT telemetry transmission to match modern Graupner receiver firmware timing.
• Fix HoTT GPS home direction scaling and add flight direction telemetry.
• Encode arming/flight-mode status into GPS free-character fields for quick in-radio visibility.

Diagram

graph TD
  RX["Graupner HoTT receiver"] --> SM["HoTT telemetry (hott.c)"] --> TX["Serial TX bytes"] --> RX
  SM -->|"0x8A GPS request"| GPS["Build GPS message"] --> NAV["Nav + flight modes"]
  GPS --> GPSIO["GPS solution"]
  SM -->|"0x8E EAM request"| EAM["Build EAM message"]

High-Level Assessment

The following are alternative approaches to this PR:

1. Priority table for mode-to-text mapping

➕ Easier to extend/reorder mode precedence than a long if/else chain
➕ Centralizes mode labels and reduces risk of overlapping conditions
➖ Requires a small refactor and careful ordering to preserve current behavior

2. Use character literals / helper for free_char fields

➕ Improves readability vs ASCII numeric constants (e.g., 'R','T','H')
➕ Reduces chance of typos in numeric values
➖ Primarily maintainability; minimal functional impact

3. Normalize direction math with wrap/clamp helpers

➕ Makes HoTT field units/scaling explicit for home/flight direction
➕ Reduces ambiguity around negative/overflow course handling
➖ May require validating expected HoTT units/ranges across firmware versions

Recommendation: The chosen approach (faster HoTT timing + richer GPS payload) is appropriate for updated receiver firmware and improves in-radio situational awareness. Consider a follow-up to refactor the mode/status encoding into a priority-ordered mapping and replace ASCII numeric literals with character constants for maintainability.

Files changed (1) +116 / -3

Enhancement (1) +116 / -3

hott.cSpeed up HoTT TX timing and expand GPS telemetry fields +116/-3

Speed up HoTT TX timing and expand GPS telemetry fields

• Reduces HoTT transmission delays (and updates the message preparation frequency constant) to support faster telemetry polling. Adjusts GPS home direction scaling, adds flight direction from ground course, and encodes arming/flight-mode status into the GPS free-character fields (including failsafe, RTH/WP, and GPS-lock/arming-disabled indications).

src/main/telemetry/hott.c

qodo-code-review · 2026-08-07T12:00:31Z

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. ~~HRST counter never resets~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

hottPrepareGPSResponse() uses a function-static hrstSent counter to limit BOXHOMERESET (“HRST”)
display, but never resets it when the mode is released. After it reaches the limit once, later
home-reset activations will never show HRST again until reboot.

Code

src/main/telemetry/hott.c[R283-286]

+    static uint8_t hrstSent = 0;
+	hottGPSMessage->free_char1 = 79;	//"O";
+	hottGPSMessage->free_char2 = 75;	//"K";
+	hottGPSMessage->free_char3 = 51;	//"3";	32 " "

Evidence

The PR introduces a function-static hrstSent counter and increments it when BOXHOMERESET is
active, but there is no corresponding reset anywhere in the function; this makes the limiter
permanent. The CRSF telemetry code shows the expected lifecycle (reset when BOXHOMERESET becomes
inactive).

src/main/telemetry/hott.c[229-382]
src/main/telemetry/crsf.c[467-522]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`hrstSent` is a function-static counter used to rate-limit the "HRST" indication when `BOXHOMERESET` is active, but it is never reset when the mode becomes inactive. This permanently disables the HRST indication after the first limited run.

## Issue Context
A similar flight-mode text implementation resets `hrstSent` when `BOXHOMERESET` is not active, allowing each new activation to show the indication again.

## Fix Focus Areas
- src/main/telemetry/hott.c[229-382]

### Implementation notes
- After the flight-mode selection logic, add something like:
 - `if (!IS_RC_MODE_ACTIVE(BOXHOMERESET) && hrstSent > 0) hrstSent = 0;`
- Optionally also reset `hrstSent` when disarmed to avoid carrying state across arm cycles.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. ~~Stale free-char status~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

hottPrepareGPSResponse() still returns early when there is no GPS fix, but the PR’s new
free_char1..3 status text is set after that return and is not cleared per call. After a GPS fix
drop, the HoTT GPS message can continue transmitting stale free_char values from a previous state.

Code

src/main/telemetry/hott.c[R284-286]

+	hottGPSMessage->free_char1 = 79;	//"O";
+	hottGPSMessage->free_char2 = 75;	//"K";
+	hottGPSMessage->free_char3 = 51;	//"3";	32 " "

Evidence

The GPS message is memset only during initialization. The existing no-fix early return remains, but
the PR added free_char updates after it; therefore those fields are not updated/cleared when the
no-fix return is taken, allowing stale values to persist across messages.

src/main/telemetry/hott.c[180-187]
src/main/telemetry/hott.c[241-249]
src/main/telemetry/hott.c[272-381]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The function returns early on `!STATE(GPS_FIX)` (or `!STATE(GPS_FIX) && !STATE(GPS_ESTIMATED_FIX)`), skipping the newly added free_char status updates. Because the message struct is reused across calls (not memset each time), the free_char bytes can retain stale values after GPS fix loss.

## Issue Context
`initialiseGPSMessage()` zeros the struct once at init; `hottPrepareGPSResponse()` mutates fields in-place and has an early return on no-fix.

## Fix Focus Areas
- src/main/telemetry/hott.c[180-187]
- src/main/telemetry/hott.c[229-381]

### Implementation notes
Choose one of:
1) Set a safe default for `free_char1..3` (e.g. blanks or "---" / "NOF") before the GPS-fix early return and also set them in the no-fix branch.
2) Move the free_char flight-mode/status computation above the GPS-fix early return so it always runs.

Also consider clearing `home_direction`/`flight_direction` in the no-fix path to avoid other stale fields.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

fill in --- for free characters 1-3 at no GPS fix.

sensei-hacker · 2026-08-16T17:54:15Z

Just an FYI for contributors: The tentative schedule for INAV 10 is to have a full release in mid December. That means RC2 needs to be in early to mid November, which places INAV 10.0RC1 at September 1. Please plan to have any new features for INAV 10.0 ready for RC1 no later than September 1. After that, 10.1 will follow about six to seven months later.

Ralfde and others added 3 commits April 16, 2020 12:49

Merge pull request #1 from iNavFlight/master

dc6aa64

test

Merge branch 'iNavFlight:master' into master

458dd91

make telemetry faster, which is allowed at the actual receiver firmwares

39d6104

add GPS sensor flight mode add GPS sensor flight direction

qodo-code-review Bot reviewed Aug 7, 2026

View reviewed changes

Comment thread src/main/telemetry/hott.c

Comment thread src/main/telemetry/hott.c

Ralfde added 2 commits August 7, 2026 15:09

add HRST reset

90fa8df

fill in --- for free characters 1-3 at no GPS fix.

change m/3s to 0m/3s, if the value is out of range

382519a

Navigation Menu

Uh oh!

HoTT telemetry improvements - #11766

HoTT telemetry improvements#11766
Ralfde wants to merge 5 commits into
iNavFlight:masterfrom
Ralfde:HoTT

Ralfde commented Aug 7, 2026 •

edited

Loading

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 7, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Aug 7, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 7, 2026 •

edited by qodo-code-review Bot

Loading

Uh oh!

qodo-code-review Bot commented Aug 7, 2026 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

sensei-hacker commented Aug 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

Ralfde commented Aug 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Uh oh!

github-actions Bot commented Aug 7, 2026

Branch Targeting Suggestion

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 7, 2026 • edited by qodo-code-review Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Summary by Qodo

Uh oh!

qodo-code-review Bot commented Aug 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Uh oh!

Uh oh!

Uh oh!

sensei-hacker commented Aug 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Ralfde commented Aug 7, 2026 •

edited

Loading

qodo-free-for-open-source-projects Bot commented Aug 7, 2026 •

edited

Loading

qodo-free-for-open-source-projects Bot commented Aug 7, 2026 •

edited by qodo-code-review Bot

Loading

qodo-code-review Bot commented Aug 7, 2026 •

edited

Loading