RxBt Vfas conflict

Open
  • Is something wrong?
#7,953 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
c
Domain
embedded-iot

Research direction

Start by tracing how EdgeTX parses and identifies CRSF telemetry sensors, especially CRSF_FRAMETYPE_BATTERY_SENSOR (0x08); the issue does not name source files or tests. Check whether sensor identity includes the sending device when two sources report this frame, then reproduce with ExpressLRS and oXs battery frames enabled. Done means both sources’ battery values are handled without conflict and the behavior is covered by a test or clear confirmation.

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
CRSF Battery sensor conflict with multiple telemetry sources

I am using an ExpressLRS receiver together with an oXs telemetry sensor sending CRSF telemetry.

ExpressLRS provides the receiver voltage (RxBt), around 5.3 V.

oXs also sends a standard CRSF Battery Sensor frame (0x08) containing voltage, current and capacity.

Observed behavior:

  • With oXs Battery frames disabled, RxBt remains correctly displayed at 5.3 V.
  • With oXs Battery frames enabled, Curr and Capa appear, but the battery telemetry from the two sources seems to conflict.
  • Other oXs sensors such as RPM, temperatures, vario, attitude, altitude and airspeed work normally.

It looks like EdgeTX may not distinguish two different CRSF sources sending the same CRSF_FRAMETYPE_BATTERY_SENSOR (0x08) frame type.

Could you confirm how EdgeTX identifies/instances CRSF Battery sensors when multiple devices send frame type 0x08?

Expected Behavior
CRSF Battery sensor conflict with multiple telemetry sources

I am using an ExpressLRS receiver together with an oXs telemetry sensor sending CRSF telemetry.

ExpressLRS provides the receiver voltage (RxBt), around 5.3 V.

oXs also sends a standard CRSF Battery Sensor frame (0x08) containing voltage, current and capacity.

Observed behavior:

  • With oXs Battery frames disabled, RxBt remains correctly displayed at 5.3 V.
  • With oXs Battery frames enabled, Curr and Capa appear, but the battery telemetry from the two sources seems to conflict.
  • Other oXs sensors such as RPM, temperatures, vario, attitude, altitude and airspeed work normally.

It looks like EdgeTX may not distinguish two different CRSF sources sending the same CRSF_FRAMETYPE_BATTERY_SENSOR (0x08) frame type.

Could you confirm how EdgeTX identifies/instances CRSF Battery sensors when multiple devices send frame type 0x08?

Steps To Reproduce
CRSF Battery sensor conflict with multiple telemetry sources

I am using an ExpressLRS receiver together with an oXs telemetry sensor sending CRSF telemetry.

ExpressLRS provides the receiver voltage (RxBt), around 5.3 V.

oXs also sends a standard CRSF Battery Sensor frame (0x08) containing voltage, current and capacity.

Observed behavior:

  • With oXs Battery frames disabled, RxBt remains correctly displayed at 5.3 V.
  • With oXs Battery frames enabled, Curr and Capa appear, but the battery telemetry from the two sources seems to conflict.
  • Other oXs sensors such as RPM, temperatures, vario, attitude, altitude and airspeed work normally.

It looks like EdgeTX may not distinguish two different CRSF sources sending the same CRSF_FRAMETYPE_BATTERY_SENSOR (0x08) frame type.

Could you confirm how EdgeTX identifies/instances CRSF Battery sensors when multiple devices send frame type 0x08?

Version

2.12.4

Transmitter

RadioMaster TX16S / TX16S Mark II

Operating System (OS)

Windows

OS Version

No response

Anything else?

No response

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.