mammotion-rtk-lora

KO | EN

gitlite — search

#docker #agents #kubernetes #video #artificial-intelligence #editor #data-science #api #bash #terminal

mammotion-rtk-lora

(★ 9)

The Mammotion RTK 3 reference station broadcasts standard

File Explorer

ZIP Download

- compose.yaml
- decode.ps1
- Dockerfile
- gnuradio-setup.md
- sdr-workflow.md
- - hop_follower.ino
- README.md
- analyze_burst.py
- gr_lora_decode.py
- lora_probe.py
- map_hops.py
- parse_containers.py
- requirements.txt
- scan_rtcm.py
- serial_capture.py
.gitignore
LICENSE
PROTOCOL.md
README.md

# Use via CDN

jsDelivr

jsDelivr serves any public GitHub repository as a CDN with zero setup. Pick a version and a file to get a ready-to-paste link and snippet.

Version

File

Link

Example

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

Reverse-engineering the radio link between a **Mammotion RTK 3** reference
station (model RBS03) and a **Luba mini AWD 800H** robot mower, in
"Antenna Over Datalink" mode.

It turns out to be standard **RTCM3 GNSS corrections** in a thin proprietary
wrapper, sent over **LoRa SF7 / BW 250 kHz**, frequency-hopping across
**25 channels 1 MHz apart** with a **600 ms dwell** and a **15.000 s** cycle.

A single inexpensive SX1276 board that follows the hop sequence recovers about
**98%** of the stream.

**[Full protocol description → PROTOCOL.md](PROTOCOL.md)**

Repository: https://github.com/Ve2mrx/mammotion-rtk-lora

Receive-only work on my own equipment. Nothing is transmitted, injected or
modified, and no captured traffic is included in this repository.

---

## What's here

```
PROTOCOL.md              the protocol, start here
firmware/hop_follower/   Arduino sketch: hop-following receiver (RadioLib)
tools/                   Python analysis and decode tools
docs/                    SDR capture workflow, GNU Radio setup
docker/                  containerised gr-lora_sdr, if you want it
```

## Quick start

If you just want to receive the link and get RTCM out:

1. Flash `firmware/hop_follower/` to an SX1276 board. Mine is an iLabs
   Challenger RP2040 LoRa; any RFM95-class module works. See
   [firmware/README.md](firmware/README.md).
2. Collect frames over USB and decode:

```bash
pip install -r tools/requirements.txt
python tools/serial_capture.py --port COM11 --seconds 180 -o hop.bin
python tools/parse_containers.py hop.bin -o rtcm.bin
```

`rtcm.bin` is then a plain RTCM3 stream — feed it to `pyrtcm`, RTKLIB, or an
NTRIP caster.

Your station has **its own address**, and the tools detect it automatically
(validated against the per-frame CRC16), so nothing needs configuring.

## Tools

| Tool | Purpose |
|---|---|
| `analyze_burst.py` | IQ capture → bandwidth, symbol time, spreading factor, "is this LoRa?" |
| `lora_probe.py` | Pure-numpy LoRa probe: preamble, CFO, **sync word**, raw symbols. Also preps baseband for gr-lora_sdr |
| `map_hops.py` | Channelised hop mapper: recovers the channel grid, dwell time and hop order from a wideband capture |
| `serial_capture.py` | Collect frames from the hop-following receiver |
| `parse_containers.py` | Frame + container layer → validated RTCM3 |
| `scan_rtcm.py` | Find and decode RTCM3 in any byte stream |
| `gr_lora_decode.py` | Offline LoRa demodulation via gr-lora_sdr (needs GNU Radio) |

Only `gr_lora_decode.py` needs GNU Radio. Everything else is numpy/scipy/pyserial.

## Finding your own link

If your station differs — EU 868 MHz, different firmware — the same sequence
works from scratch:

1. **Find it.** Sweep the ISM band on an SDR. RTCM goes out on a regular cycle,
   so look for a periodic pattern rather than continuous traffic.
2. **Characterise a burst.** `analyze_burst.py` gives bandwidth and spreading
   factor, and tells you whether it's LoRa at all.
3. **Get the sync word.** `lora_probe.py`. This is the one parameter you cannot
   read off a spectrum plot.
4. **Map the hops.** `map_hops.py` on a wideband capture gives the channel grid,
   dwell and order.
5. **Follow them.** Adjust the constants at the top of the firmware and run.

## Notes and caveats

- Parameters are from **one station** in the US 902–928 MHz band. EU units and
  other firmware versions will differ.
- The **channel grid, dwell and cycle** are the values to check first if nothing
  decodes — they're the top of `hop_follower.ino` and adjustable at runtime over
  serial.
- RTCM message **1006 carries the base station's surveyed position to
  centimetre precision.** For most owners that is their garden. Think before
  posting decoded output.

## Credits

By **Martin Boissonneault (VE2MRX)**, with huge help from **Anthropic Claude
Opus 5** — which wrote most of the tooling and firmware here, and did the
analysis that untangled the channel grid, the container format and the two
checksum layers.

A note on how that actually went, since it's the interesting part: nearly every
breakthrough came from *measuring* rather than reasoning. Claude's confident
early guesses — that the module was an Ebyte E22, that the link couldn't be
frequency-hopping, that the garbled frames were bit errors — were all wrong, and
all corrected by data. What worked was building small tools that tabulate results
against a structural property and then reading the table. The debugging technique
in [PROTOCOL.md §8](PROTOCOL.md) is the real takeaway.

## Licence

MIT — see [LICENSE](LICENSE).

mammotion-rtk-lora

File Explorer

# Use via CDN

Was this content helpful?

Recent Feedback

Download README