Add wireless communication options comparison document for LifeTrac

[Copilot]

LifeTrac lacks documentation on wireless options for long-range, low-latency remote control. This adds LifeTrac-v25/WIRELESS_OPTIONS.md covering 15 technologies with actionable specs and recommendations.

What's in the document

• Comparison table — 15 technologies side-by-side: LoS range, NLoS range, latency, data rate, frequency, power draw, cost, and open source status (✅ fully open / 🔶 partially open / ❌ proprietary)
• Technology deep-dives — RC (2.4 GHz FHSS + 900 MHz), ExpressLRS, LoRa, Meshtastic, WiFi, Cellular
• Meshtastic speed breakdown — per-mode table (LongFast → ShortTurbo) with air data rate, throughput, and real-world latency; concludes Meshtastic is unsuitable as a primary control link (100 ms–10 s latency depending on mode)
• Recommendations — ranked primary control and secondary telemetry options, each with open source status noted
• Integration snippets — ELRS CRSF/SBUS wiring to Arduino Opta and ESP32, LoRa telemetry module config; SBUS notes include correct serial settings (100000 baud, 8E2 — even parity, 2 stop bits, inverted signal) and hardware inverter requirements
• Hardware purchase links — table of 21 example products with store links (Radiomaster, BetaFPV, GetFPV, Adafruit, Amazon, AliExpress, Heltec, RAK, Digi) and approximate prices for every technology covered, including the Digi XBee Pro 900HP

Key findings

Priority	Use	Technology	Latency	LoS Range	Open Source
1st	Primary control	ELRS 900 MHz	4–20 ms	20–40 km	✅ Firmware + HW
2nd	Primary control	RC 900 MHz (FrSky R9)	10–30 ms	5–15 km	🔶 Firmware only
1st	Telemetry	LoRa 900 MHz	50–150 ms	2–15 km	🔶 Firmware only
2nd	Telemetry	Meshtastic	100 ms–2+ s	1–10 km	✅ Firmware + HW

The Digi XBee Pro 900HP (3–10 km LoS, 15–50 ms, 156 kbps, industrial FHSS, ❌ proprietary) is a viable option for telemetry or slow-rate control via simple UART serial integration, though ELRS offers better latency at lower cost for primary control.

Current v25 BLE and WiFi/MQTT integrations are retained and noted as suitable for close-range/on-site use only.

[Copilot]

Pull request overview

Adds a new LifeTrac v25 documentation page that compares wireless technologies for long-range, low-latency remote control and provides integration guidance for recommended options.

Changes:

• Introduces a side-by-side comparison table for 15 wireless technologies (range, latency, data rate, frequency, power, cost).
• Adds deeper dives for key candidates (RC, ExpressLRS, LoRa, Meshtastic, WiFi, Cellular) plus ranked recommendations for control vs telemetry.
• Includes practical integration notes/snippets for ELRS (CRSF/SBUS) and LoRa telemetry configuration.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The LoRa latency range description is internally inconsistent and reverses the relationship between spreading factor/bandwidth and airtime: highest SF + narrow BW produces the longest packet times (often hundreds of ms to seconds), while lowest SF + wide BW is the lowest latency. Please reword this line to match the examples immediately below (SF7/BW500kHz vs SF12/BW125kHz).

Suggested change

	- **Latency**: Highly variable — from ~100 ms (highest spreading factor, narrowest bandwidth) to ~20 ms (lowest SF, widest BW)
	- **Latency**: Highly variable — from ~20 ms (lowest SF, widest bandwidth) to over 2 s (highest spreading factor, narrowest bandwidth)

[Copilot]

The SBUS integration note is missing key serial settings: SBUS is typically 100000 baud with even parity and 2 stop bits (8E2) and an inverted signal, and many MCUs require a hardware inverter or an inverted-UART feature. Adding these details here would prevent readers from wiring/configuring the UART incorrectly.

[dorkmo]

@copilot can we make a table within the document that links to stores for the hardware required for each option?

[Copilot]

@copilot can we make a table within the document that links to stores for the hardware required for each option?

Added a Hardware Purchase Links section (commit 39e59e4) with a 20-row table covering all major options in the document — ELRS TX/RX modules, FrSky R9, LoRa dev boards, Meshtastic devices (LilyGO T-Beam, Heltec, RAK WisBlock), ESP32, Ubiquiti NanoStation, and cellular modems. Each row includes the component type, example product name, a direct store link (Radiomaster, BetaFPV, GetFPV, Adafruit, Amazon, AliExpress, Heltec, RAK), and approximate price.

[dorkmo]

@copilot would these work?
https://www.digi.com/products/embedded-systems/digi-xbee/rf-modules/sub-1-ghz-rf-modules/xbee-pro-900hp

[Copilot]

@copilot would these work?
https://www.digi.com/products/embedded-systems/digi-xbee/rf-modules/sub-1-ghz-rf-modules/xbee-pro-900hp

Yes, the XBee Pro 900HP would work for LifeTrac — it was already included in the comparison table (row: "Digi XBee Pro (900 MHz)": 3–10 km LoS, 15–50 ms latency, 156 kbps, industrial-grade FHSS). Added it to the hardware purchase links table in commit 2564765 with a direct link to the Digi store (~$50–$80 each; you need a pair).

A few notes for your use case:

• Telemetry/secondary link: ✅ Excellent fit — serial UART output connects directly to Arduino Opta or ESP32, robust industrial FHSS, supports DigiMesh for multi-node setups.
• Primary control link: ⚠️ Workable but not ideal — 15–50 ms latency is acceptable for tractor control speeds, but ELRS 900 MHz gives better latency (4–20 ms) at a lower price point. The XBee shines for its industrial reliability and easy serial integration if you're not using an RC-style radio.
• Failsafe: You'll need to implement a software timeout on the Arduino side to detect signal loss and bring the tractor to a safe stop, since XBee doesn't have a built-in RC-style failsafe like ELRS/SBUS does.

[dorkmo]

@copilot can add a column to the tables to indicate which options have open source code and open source hardware available

[Copilot]

@copilot can add a column to the tables to indicate which options have open source code and open source hardware available

Added an Open Source column to both the main comparison table and the recommendation tables (commit b45f86f). Each entry uses:

• ✅ Fully open (firmware + hardware designs) — ELRS, Meshtastic
• 🔶 Partially open (open firmware/standard, closed hardware) — Traditional RC (OpenTX/EdgeTX), LoRa libraries, BLE/WiFi standards
• ❌ Proprietary/closed — Cellular, Digi XBee Pro, Ubiquiti airMAX

A legend is also added below the comparison table for reference.

[dorkmo]

@copilot anything we forgot to include?

[Copilot]

@copilot anything we forgot to include?

The document covers the major ground well. A few things worth considering for a future update:

1. Regulatory/FCC compliance note — Some ELRS TX modules ship at 1–2 W output, which exceeds FCC Part 15 EIRP limits for unlicensed use on 900 MHz. A brief note pointing readers to check local regulations (FCC Part 15 / Part 97 amateur, ETSI EN 300 220 for Europe) would be valuable before someone orders a high-power module for field use.

2. Antenna selection guidance — The document doesn't mention antenna type tradeoffs (omnidirectional whip vs. directional patch/yagi, dBi gain, cable loss). A short note on typical antenna choices for mobile (tractor) vs. fixed (base station) ends would help with real deployments.

3. RSSI/link quality monitoring — No mention of how to monitor signal strength in the field (ELRS provides RSSI/LQ over CRSF telemetry back to the TX; LoRa modules expose RSSI/SNR). This is useful for understanding when to stop driving and is safety-relevant.

4. Failsafe configuration walkthrough — Failsafe is listed as a requirement in the overview but the integration section doesn't explain how to configure ELRS failsafe (e.g., set all channels to "no pulses" / hold last position in the Lua script) or how to detect it on the Arduino side.

5. MAVLink/ROS2 telemetry integration — The doc mentions "easy to interface with ROS2" for CRSF but doesn't show it. A snippet for publishing CRSF channel data to a ROS2 topic would complete the picture for the software side.

None of these are blocking, but regulatory and failsafe configuration are probably the most safety-critical gaps. Happy to add any of them if you'd like.