Ghost GPS heading (Hdg) reads ~1000x too small

Closed Beginner friendly
  • Is something wrong?
#7,841 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

A pull request for this has already been merged.

  • #7883 by @r3wretrhy — merged

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
c
Domain
embedded-iot

Research direction

Start in radio/src/telemetry/ghost.cpp and trace the GHST_DL_GPS_SECONDARY decode into the GHOST_ID_GPS_HDG sensor definition and ghostSetDefault(). Run the gtests-radio unit test described in the issue, including the 185.0° and 359.9° cases; done means the heading is stored and exposed at the correct degree scale while other GPS readings remain correct.

Written by the indexing model from the issue text.

Description

bug 🪲 triage
Is there an existing issue for this problem?
  • I have searched the existing issues
What part of EdgeTX is the focus of this bug?

Transmitter firmware

Current Behavior

The GHST GPS heading sensor Hdg shows about 1/1000 of the real course, with 10° resolution. Example: 185° is shown and returned to Lua as 0.18. Same code in v2.11.0 to v2.12.4 and main (d351fddaa8).

Expected Behavior

Hdg shows the GPS course in degrees (e.g. 185.0), like the CRSF Hdg sensor after #3177.

Steps To Reproduce
  1. Betaflight FC with GPS, ImmersionRC Ghost receiver, GPS telemetry enabled.
  2. Discover sensors on the radio, fly or walk with the model in a straight line.
  3. Compare the Hdg sensor value with the actual course (e.g. from the Betaflight OSD).
    Found by reading the code and confirmed with a unit test, see below.
Version

2.12.4

Transmitter

RadioMaster TX16S MK3

Operating System (OS)

No response

OS Version

No response

Anything else?

Cause in radio/src/telemetry/ghost.cpp:

  • GHST_DL_GPS_SECONDARY decode passes whole degrees:
    processGhostTelemetryValue(GHOST_ID_GPS_HDG, _get_u16le(frame, 3) / 10);
    (Betaflight ghst.c sends gpsSol.groundCourse, degrees * 10.)
  • The sensor table declares precision 3:
    GS(GHOST_ID_GPS_HDG, STR_SENSOR_HDG, UNIT_DEGREE, 3),
  • ghostSetDefault() creates the sensor with min<uint8_t>(2, sensor->precision) = 2, so TelemetrySensor::getValue() / convertTelemetryValue() divides by 10 again (prec 3 -> 2): 185 -> 18, i.e. 0.18 with precision 2.

Same bug class as fixed for CRSF in #3177; Ghost was not changed there. Unchanged since the GHST GPS sensors were added (1180fcbe5, OpenTX #8352).

Verified with the EdgeTX unit tests (gtests-radio, main d351fddaa8, PCB X10/TX16S): a GHST_DL_GPS_SECONDARY frame built byte by byte like Betaflight's ghstFrameGpsSecondaryTelemetry() (10 m/s, 185.0°, 12 sats) fed into processGhostTelemetryFrame() gives GSpd 36 km/h and Sats 12 (correct), but Hdg stored 18 with prec 2, i.e. 0.18 in Lua; 359.9° gives 0.35. With table precision 1 and the raw value (no / 10) the same test gives 185 and 359.9.

Not measured on Ghost hardware: this assumes the Ghost firmware forwards the Betaflight frame unchanged (closed source). Betaflight's GHST GPS sender (3b3f4893f8) and this decoder (1180fcbe5) were written by the same author in 2021 and agree on degrees * 10.

Suggested fix: pass the raw value with precision 1 (_get_u16le(frame, 3), 0.1°), or keep / 10 and declare precision 0.

Dominant language
C
Stars
2.4k
Forks
614
Avg merge
2d 14h
Merged PRs (30d)
68

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from EdgeTX/edgetx

All issues in EdgeTX/edgetx

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.