Idea
Use a MeshCore companion radio (e.g. Heltec / TTGO LoRa boards running the MeshCore companion firmware) as a DAPPS bearer. Two variants, in implementation order:
H1 - Companion-over-USB
The companion exposes a serial protocol over USB. DAPPS opens that serial port, sends companion datagrams carrying our BackhaulMessage payloads, and listens for inbound datagrams. Discovery beacon support if the companion firmware allows it; otherwise rely on Phase B5's flood-then-learn over this bearer instead of explicit beacons.
This is the higher-level interface - companion datagrams have addressing baked in, so DAPPS treats it like AGW: hand it a payload + destination, it gets there or it doesn't.
H2 - KISS-over-USB
Same hardware as H1 but via the MeshCore KISS interface - raw frames rather than companion-level datagrams. Trades convenience for control: DAPPS does its own framing on top of plain KISS. Same BackhaulMessage codec; same packetiser. Probably done after H1 once H1 has shaken out the wire-shape questions.
Why both, and in this order
H1 first because the companion abstraction is closer to AGW's existing shape and gets us a working LoRa bearer without rewriting the addressing layer. H2 follows once we know what we want from the bearer and have a reason to give up the companion's conveniences (e.g. wanting to talk to a non-companion-firmware MeshCore node, or wanting tighter control of the airtime budget).
Status
External-blocked on hardware availability. The radio is cheap (~£15) but writing serial-protocol code without a real radio in the loop produces something that "compiles." Wait until at least one author has the hardware in front of them.
Migrated from plan.md Phase H1+H2 sections and the scratchpad bullet "what about using Meshcore as a transport?".
Idea
Use a MeshCore companion radio (e.g. Heltec / TTGO LoRa boards running the MeshCore companion firmware) as a DAPPS bearer. Two variants, in implementation order:
H1 - Companion-over-USB
The companion exposes a serial protocol over USB. DAPPS opens that serial port, sends companion datagrams carrying our
BackhaulMessagepayloads, and listens for inbound datagrams. Discovery beacon support if the companion firmware allows it; otherwise rely on Phase B5's flood-then-learn over this bearer instead of explicit beacons.This is the higher-level interface - companion datagrams have addressing baked in, so DAPPS treats it like AGW: hand it a payload + destination, it gets there or it doesn't.
H2 - KISS-over-USB
Same hardware as H1 but via the MeshCore KISS interface - raw frames rather than companion-level datagrams. Trades convenience for control: DAPPS does its own framing on top of plain KISS. Same
BackhaulMessagecodec; same packetiser. Probably done after H1 once H1 has shaken out the wire-shape questions.Why both, and in this order
H1 first because the companion abstraction is closer to AGW's existing shape and gets us a working LoRa bearer without rewriting the addressing layer. H2 follows once we know what we want from the bearer and have a reason to give up the companion's conveniences (e.g. wanting to talk to a non-companion-firmware MeshCore node, or wanting tighter control of the airtime budget).
Status
External-blocked on hardware availability. The radio is cheap (~£15) but writing serial-protocol code without a real radio in the loop produces something that "compiles." Wait until at least one author has the hardware in front of them.
Migrated from
plan.mdPhase H1+H2 sections and the scratchpad bullet "what about using Meshcore as a transport?".