0 Fork 0

Files

T

feat(mdbook): publish spec via mdBook on GitHub Pages

Set up the protocol spec as an mdBook and add a GitHub Actions
workflow that builds it on every push/PR and deploys to GitHub
Pages on main. The repo is now both a machine-readable corpus and
a browsable, searchable site.

Structure changes (one-time, mechanical):

- Rename the spec source directory from `spec/` to `src/` to match
  mdBook's default convention. All 21 chapter files move; their
  internal relative cross-links are unchanged.
- Add `src/SUMMARY.md` as the mdBook table of contents, grouping
  chapters under Wire Format, Payloads, Cryptography & Identity,
  and Routing & Higher-Layer Protocols.
- Add `book.toml` at repo root: title, author, search enabled,
  fold enabled, edit-on-GitHub links, navy theme.
- Add `.github/workflows/mdbook.yml`: build on push + PR, deploy
  on push to main only (configure-pages + upload-pages-artifact +
  deploy-pages from actions/).
- Add `/book/` to .gitignore.

Reference updates so the old path is fully retired:

- Every `spec_ref` in `corpus/**/*.json` rewritten from `spec/` to
  `src/` (54 files).
- Schema description text and example path in
  `corpus/schema/test-vector.schema.json`.
- `README.md`: prominent link to the published site near the top;
  "What's Here" updated for the new layout.
- `CONTRIBUTING.md`: spec-editing instructions point at `src/`
  and note the SUMMARY.md requirement.
- `CLAUDE.md`: directory-layout notes updated.

CHANGELOG.md historical entries intentionally keep their `spec/`
paths since those record what the paths were at the time of those
commits.

After this lands, the user needs to enable GitHub Pages in repo
settings with source = "GitHub Actions" (one-time, manual). The
workflow will then publish to https://swaits.github.io/meshcore-spec/
on every push to main.

Verified locally: `mdbook build` produces a clean book/ tree with
all 21 chapters rendered and the SUMMARY-driven sidebar populated.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-12 09:36:28 -06:00

2.6 KiB

Raw Blame History

MeshCore Protocol Specification

Section 20: Bridge Protocol

Overview

The bridge protocol enables MeshCore packet forwarding over non-LoRa transports such as RS232 serial links and ESP-NOW WiFi. It adds a simple framing layer with a magic number and checksum around the raw MeshCore packet.

Frame Format

┌──────────────┬──────────────┬──────────────┬──────────────┐
│  Magic (2B)  │   Payload    │ Checksum (2B)│              │
│   0xC03E     │  (variable)  │ Fletcher-16  │              │
└──────────────┴──────────────┴──────────────┴──────────────┘

Fields

Field	Size	Type	Description
Magic	2 bytes	uint16	`0xC03E` — identifies the frame as a MeshCore bridge packet
Payload	variable	raw	Raw MeshCore packet (as produced by `Packet::writeTo()`)
Checksum	2 bytes	Fletcher-16	Fletcher-16 checksum over the payload

RS232 Variant

The RS232 variant adds a length field between the magic and payload:

┌──────────────┬──────────────┬──────────────┬──────────────┐
│  Magic (2B)  │  Length (2B) │   Payload    │ Checksum (2B)│
│   0xC03E     │  uint16_le   │  (variable)  │ Fletcher-16  │
└──────────────┴──────────────┴──────────────┴──────────────┘

Field	Size	Type	Description
Length	2 bytes	uint16_le	Length of the payload in bytes

Fletcher-16 Checksum

The Fletcher-16 checksum is computed over the payload bytes:

function fletcher16(data):
    sum1 = 0
    sum2 = 0
    for byte in data:
        sum1 = (sum1 + byte) mod 255
        sum2 = (sum2 + sum1) mod 255
    return (sum2 << 8) | sum1

ESP-NOW Variant

For ESP-NOW transport, the frame format is the same as the basic format (magic + payload + checksum) without the length field, since ESP-NOW provides its own length framing.

Cross-References

Section 1: Wire Format — Packet format within payload

Reference Implementation

Bridge handling in MeshCore firmware (board-specific implementations)

2.6 KiB Raw Blame History