Skip to content

update docs - softserial limit #11771

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
RomanLut wants to merge 1 commit into
base: master
Choose a base branch
from
+2 −2
Open

update docs - softserial limit #11771

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions docs/Telemetry.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -206,7 +206,7 @@ More information about the fields, encoding and enumerations may be found [on th

MAVLink is a lightweight header-only message marshalling library for micro air vehicles. INAV supports MAVLink for compatibility with ground stations, OSDs and antenna trackers built for PX4, PIXHAWK, APM and Parrot AR.Drone platforms.

MAVLink implementation in INAV is transmit-only and usable on low baud rates and can be used over soft serial (requires 19200 baud). MAVLink V1 and V2 are supported.
MAVLink implementation in INAV is transmit-only, is usable at low baud rates. MAVLink V1 and V2 are supported.

@qodo-code-review qodo-code-review Bot Aug 8, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Informational

2. Mavlink sentence punctuation 🐞 Bug ⚙ Maintainability

The new sentence “transmit-only, is usable…” is a comma splice and reads ambiguously. This reduces
clarity in the updated documentation.
Agent Prompt 
### Issue description
The updated MAVLink line uses a comma splice (“transmit-only, is usable”), which is grammatically awkward and can be misread.

### Issue Context
This is purely a documentation clarity/readability fix.

### Fix Focus Areas
- docs/Telemetry.md[205-210]

### Suggested change
Reword to something like:
- “MAVLink implementation in INAV is transmit-only and usable at low baud rates. MAVLink V1 and V2 are supported.”

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

@qodo-free-for-open-source-projects qodo-free-for-open-source-projects Bot Aug 8, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. Mavlink not transmit-only 🐞 Bug ≡ Correctness

docs/Telemetry.md states MAVLink in INAV is “transmit-only”, but the current MAVLink telemetry
implementation reads and processes incoming MAVLink messages (missions/params/RC override/etc). This
misleads users about MAVLink capabilities and is in-scope because the PR edited this sentence but
kept the incorrect claim.
Agent Prompt 
### Issue description
`docs/Telemetry.md` says MAVLink is transmit-only, but the implementation processes inbound MAVLink messages. This is incorrect documentation and can lead users to wrong configuration/expectations.

### Issue Context
The telemetry MAVLink code contains an explicit receive loop and dispatches received message IDs.

### Fix Focus Areas
- docs/Telemetry.md[205-210]
- src/main/telemetry/mavlink.c[1388-1433]
- src/main/telemetry/mavlink.c[1444-1456]

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



## Cellular telemetry via text messages
Expand All @@ -233,7 +233,7 @@ To receive acceleration event messages, set one or more of the acceleration even
Ibus telemetry requires a single connection from the TX pin of a bidirectional serial port to the Ibus sens pin on an FlySky telemetry receiver. (tested with fs-iA6B receiver, iA10 should work)

It shares 1 line for both TX and RX, the rx pin cannot be used for other serial port stuff.
It runs at a fixed baud rate of 115200, so it need hardware uart (softserial is limit to 19200).

@qodo-free-for-open-source-projects qodo-free-for-open-source-projects Bot Aug 8, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remediation recommended

2. Softserial baud docs conflict 🐞 Bug ⚙ Maintainability

This PR removes the “softserial is limit to 19200” note from the iBus telemetry section, but other
docs still state SoftSerial is limited to 19200 baud. This leaves contradictory guidance across the
documentation set and will confuse users configuring SoftSerial-based telemetry/logging.
Agent Prompt 
### Issue description
After this PR, `docs/Telemetry.md` no longer mentions a 19200 SoftSerial limit for iBus, but `docs/Serial.md` and `docs/Blackbox.md` still claim SoftSerial is limited to 19200 baud. This is conflicting documentation.

### Issue Context
The PR’s stated goal is to fix misleading SoftSerial-limit docs; this should be applied consistently across the documentation set.

### Fix Focus Areas
- docs/Telemetry.md[231-237]
- docs/Serial.md[46-48]
- docs/Blackbox.md[68-75]

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

It runs at a fixed baud rate of 115200.

@qodo-code-review qodo-code-review Bot Aug 8, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remediation recommended

1. Softserial limit docs conflict 🐞 Bug ⚙ Maintainability

docs/Telemetry.md removes the “softserial limited to 19200” guidance, but other docs still claim
SoftSerial is capped at 19200, creating contradictory configuration guidance. The SoftSerial
implementation appears to accept an arbitrary baud (no explicit 19200 clamp), so the remaining
“19200 limit” statements are likely misleading or at least need qualification as a practical
recommendation rather than a hard limit.
Agent Prompt 
### Issue description
`docs/Telemetry.md` no longer states SoftSerial is limited to 19200 baud, but `docs/Serial.md` and `docs/Blackbox.md` still state (as a hard limit) that SoftSerial is limited to 19200. This creates contradictory documentation after this PR.

### Issue Context
The SoftSerial code path takes a `baud` parameter and configures timers from it without a clear 19200 cap, so documentation that presents 19200 as a strict limit is inconsistent with the current implementation.

### Fix Focus Areas
- docs/Telemetry.md[205-236]
- docs/Serial.md[36-49]
- docs/Blackbox.md[68-76]
- src/main/drivers/serial_softserial.c[170-189]
- src/main/drivers/serial_softserial.c[204-345]

### Suggested change
Update the other docs to match the new reality (e.g., remove the “limited to 19200” hard-limit phrasing) or rephrase consistently as a practical/recommended limit if that’s the intended guidance (e.g., “SoftSerial may be unreliable at high baud rates; prefer hardware UART for >19200 / high bandwidth”).

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

```
_______
/ \ /-------------\
Expand Down
Loading