1. Will our idea work?
Yes, in a staged way. No existing project does what LTAK wants (no-app captive portal, four-color check-in, mailbox with receipts, leader dashboard, voice check-in). But each piece has been done somewhere, and MeshCore already supplies the hard part, the radio routing. The work is the layer on top. We should not write a routing protocol from scratch.
What we build on
MeshCore routing and encryption, carrying our own binary message types. Pi-based repeaters hold the data and run the dashboard.What we build new
The captive-portal firmware for the pocket node, the LTAK message format, the mailbox and delta sync, the leader dashboard, and the provisioning tools.What could stop us
Phone captive-portal behavior, HTTPS-only phone location, battery life with Wi-Fi on, and whether MeshCore path learning scales cleanly to 20+ repeaters. All are testable in about a month.Honest limits. I could not test hardware. Version numbers and dates in the web sources were inconsistent in places (some pages cite firmware dates that look wrong), so check release pages before pinning versions. FCC points below come from secondary sources, not the regulation text.
2. Which base system should we start from?
Scored against LTAK's actual needs, not general popularity.
| Requirement | Meshtastic | MeshCore | disaster.radio | From scratch |
|---|---|---|---|---|
| Runs on XIAO ESP32S3 + Wio-SX1262 | Yes | Yes (official) | Old boards; port needed | Yes (RadioLib) |
| No-app phone access (Wi-Fi hotspot + web page) | No: Wi-Fi is client-only | Not built in; we add it | Yes, its core idea | We build it |
| Routing that doesn't flood everything | Floods broadcasts; next-hop for DMs only | Learned paths, repeaters-only relay | Simple distance-vector, small scale | Months of work, easy to get wrong |
| Custom message types (check-in, mail, receipts) | Possible via custom port numbers | Binary group data + raw custom packets, opaque data_type | Datagram layer, 234 bytes | Anything |
| Python bridge on a Pi | Yes | Yes, and you already use it | No | We build it |
| Store-and-forward for offline people | Server needs PSRAM, limited history | Room server holds about 32 messages | None | Ours (SQLite on the Pi) |
| Project health | Very active | Very active, forks exist (e.g. a "Team Edition") | Paused since about 2020-21 | n/a |
| License | GPL-3.0 | MIT | Open source | Ours |
Recommendation: MeshCore as the radio base, plus disaster.radio's user experience idea. Start with stock MeshCore to prove range and routing in week one, then fork only what we must. The existing Team Edition fork shows forking MeshCore is a normal thing to do.
Why not Meshtastic as the base? It can't host a Wi-Fi hotspot on the ESP32, so it can't give you the no-app captive portal that is the heart of LTAK. It also floods broadcasts through every node, which fights your "don't clog the network" goal. It remains the best partner network (see section 5).
3. Recommended architecture
Green = use as is, amber = modify, red = new work.
Apps
Phone web UI (check-in, mail), leader dashboard, voice check-in, library
NEW
LTAK protocol
Our message types in compact binary: check-in, DM, receipt, admin, sync. Each signed by its sender.
NEW
Transport
MeshCore datagrams: binary group data (with our own
data_type number) or raw custom packetsSTOCK
Routing
MeshCore: first message floods, then the learned path is reused; only repeaters relay
STOCK
Radio
SX1262 on our own frequency, with our own sync word and network key
CONFIG / SMALL FORK
Watch-outs found in research. MeshCore group datagrams carry no sender identity or timestamp, so LTAK must put its own signed sender ID, sequence number and time inside every payload. MeshCore also reserves a range of
data_type values for developers and hands out registered blocks, so we should use the developer range while prototyping.Pocket node vs repeater roles
| Device | Firmware | Notes |
|---|---|---|
| Pocket node (XIAO S3) | Forked MeshCore companion + Wi-Fi AP + captive portal + LTAK app | Phone talks to it over Wi-Fi (not Bluetooth), so no app is needed. The node itself holds the logic. |
| Repeater radio (XIAO S3 on the Pi) | Stock MeshCore companion, driven over USB by Python | Your ping bot already does this. The Pi is the brain. |
| Relay-only site (no Pi) | Stock MeshCore repeater | Cheap coverage filler on a roof or hill. |
| Screen version | T-Deck Plus running our app layer | MeshCore already runs on it. |
4. What frequency should LTAK use?
Short answer: a private channel inside the US 902–928 MHz unlicensed band, chosen by a local spectrum survey, with its own sync word and encryption key. You don't need a license, but you must follow the Part 15 rules.
Why not just use the public channels?
- Meshtastic defaults to about 906.875 MHz (LongFast, 250 kHz). Newer firmware may default to a 500 kHz preset near 908.75 MHz, but I couldn't confirm that.
- MeshCore US presets center near 910.525 MHz.
- LoRaWAN (TTN, Helium and other sensors) occupies roughly 903–915 MHz for uplinks and 923.3–927.5 MHz for downlinks. Sub-band 2 (about 903.9–905.3 MHz) is especially busy.
- In dense areas the default channels are congested. In a disaster, everyone with a Meshtastic node also hammers the default channel.
Important: separate frequency is not the same as invisible
Meshtastic and MeshCore use different LoRa sync words (reported as 0x2B and 0x12), so receivers drop each other's frames. That stops decoding, not interference. Overlapping transmissions on the same frequency still raise each other's noise floor. So a private sync word protects privacy and mixing, but picking a quiet frequency is what protects reliability.
The Part 15 rules that matter (summary, verify before building)
| If we use… | Typical rule | What it means for LTAK |
|---|---|---|
| Digital modulation (DTS), 6 dB bandwidth ≥ 500 kHz | Up to 1 W conducted. PSD limit 8 dBm per 3 kHz. Antenna gain above 6 dBi requires reducing power. | The cleanest legal path. LoRa at 500 kHz is reported to qualify. Cost: less sensitivity than narrow bandwidths, so less range. |
| Frequency hopping (FHSS) | Needs 25 to 50+ hop channels and dwell limits (0.4 s in 10–20 s) | Harder to do in a store-and-forward mesh. Probably not worth it. |
| Narrow LoRa (125 kHz or 62.5 kHz) as most meshes run | Compliance depends on exact configuration and is debated in the community | Many hobby meshes run here. A church network that wants to be above reproach should either use 500 kHz or get a written opinion (e.g. from a certified test lab or an RF lawyer). |
Honest trade-off. 500 kHz bandwidth costs roughly 6 dB of link budget compared with 125 kHz at the same spreading factor. That is a real range hit, so we make it back with roof-mounted repeaters, a better antenna, and a higher spreading factor, and by using repeaters instead of pocket-to-pocket links. This is exactly the sort of thing the Phase 0 range survey settles.
How to pick the actual frequency
- Survey your area. With an RTL-SDR on an outdoor antenna, sweep 902–928 MHz for at least a day (community guidance suggests
rtl_powerover 902M:928M with long integration) with your own nodes off. Do it at 3 to 4 sites across your 20 sq mi. - Find a quiet 500 kHz-wide slot. Avoid the default Meshtastic slot and MeshCore's default frequency, the LoRaWAN uplink sub-bands, and the LoRaWAN downlink block, plus anything you see in the survey. The 915–923 MHz stretch may be less crowded by LoRa, but other devices live there, so only the survey tells you.
- Pick a primary and a fallback. For example: primary slot A, fallback slot B at least 1 MHz away. Every node stores both. A leader can send a signed "move to B" command if A becomes noisy.
- Use a private sync word and network key so stock Meshtastic and MeshCore nodes never decode (or relay) our traffic.
- Re-survey every year and after any new local mesh appears.
Hardware compliance note
Use radio modules sold as FCC-certified and keep power and antenna gain within their certification. Higher-gain antennas on repeaters need a power reduction. Document the exact settings you ship.Starting recommendation: private LTAK channel, 500 kHz bandwidth (DTS), custom sync word, AES-encrypted, primary + fallback frequencies chosen from a local survey. Spend a month testing before locking the plan. Encrypted traffic is fine on 915 MHz ISM, but never on amateur bands.
5. Can people use Meshtastic or LTAK? (dual system)
Two kinds of "dual": one device that speaks both, or two networks that exchange information.
| Approach | Feasibility | Verdict |
|---|---|---|
| A. One radio runs both firmwares at once | Not possible | The same SX1262 chip can't run two protocols or sync words at the same moment. Some experimental firmware can listen to both sync words, but that gives limited visibility, not real interoperability. |
| B. One device, time-sliced between LTAK and Meshtastic | Technically possible, practically poor | Misses packets from both networks, doubles the firmware complexity, and drains AA batteries. Not worth it. |
| C. Two radios in a repeater, with a bridge on the Pi | Feasible | Best option. A second XIAO running Meshtastic sits on the Pi. The bridge forwards selected things: LTAK check-ins as short text to a Meshtastic channel, and Meshtastic text to LTAK mailboxes. Cost: about $12–18 per repeater plus an antenna. |
| D. Give some members a Meshtastic node instead of LTAK hardware | Works, with caveats | They'd have to use the Meshtastic phone app (no captive portal). Their messages reach LTAK only through the bridge in C. No four-color buttons unless we add a quick-reply convention (e.g. "GREEN", "RED"). |
| E. Share TAK maps (ATAK / iTAK) | Feasible | Meshtastic and MeshCore both have TAK integrations. The LTAK dashboard can export positions and check-ins as TAK Cursor-on-Target (CoT), which also helps working with responders. |
What a bridge should and shouldn't do
- Do: forward check-in summaries ("MRN-hidden alias, color, location") only to a private Meshtastic channel that leaders and willing members join. Forward inbound Meshtastic direct messages to a mailbox.
- Don't: bridge everything. A bridge that mirrors all traffic both ways is a traffic amplifier and a loop risk. Add loop detection, a rate limit, and a kill switch.
- Don't send member numbers, addresses or medical data to a Meshtastic network we don't control. Use aliases.
- Don't put the bridge on the public default channel. Use a private channel with its own key so the bridge doesn't add to public congestion.
Recommendation: LTAK pocket nodes stay LTAK-only (simpler, lower power). Optional Meshtastic bridge on a few repeaters (approach C), plus TAK export (E). This gives Meshtastic owners a way in without compromising LTAK's design. Build it after the core system works (after Phase 4).
6. Making it seamless and robust
The plan has to survive people moving, parts breaking, and stress. These additions are ranked by how much failure they prevent.
A. When hardware breaks
| Feature | Why | Priority |
|---|---|---|
| Overlapping coverage (every pocket node should reach 2+ repeaters) | One repeater dying must not black out a neighborhood. Verify with the range survey. | Must |
| Spare kit per zone: a pre-configured Pi SD/SSD image, XIAO, SDR, cables, fuse, in a labeled box | Fix in 30 minutes by swapping parts, no expertise needed. | Must |
| Disk image + config backup to a USB stick weekly, plus offsite copy of the directory | A failed SSD shouldn't lose the system. | Must |
| Read-only OS, hardware watchdog, auto-restart services | Power loss and freezes are the commonest Pi failures. | Must |
| Repeater health beacons (battery volts, temperature, uptime, last-heard list) every 10 min | Leaders see "Zone 3 repeater battery 11.8 V and falling" days before it dies. | Must |
| Relay-only stock-MeshCore fallback on a cheap solar unit near each repeater | If the Pi dies, the radio path keeps working, just without mailbox. | Should |
| Pocket node self-test (battery, radio, heard-a-repeater LED or screen) | Tells a user in 5 seconds whether their node is working. Do it at every drill. | Should |
B. When people move or roles change
| Feature | Why | Priority |
|---|---|---|
| Directory as the single source of truth with an admin screen to reassign someone to a new captain, home repeater or address | People move. Everything (home repeater, org chart, friends list) should follow from one record. | Must |
| Over-the-air config updates for pocket nodes (signed): friends list, home repeater, frequency fallback | You can't re-flash 100 devices each time something changes. Nodes pick up changes the next time they check in at a repeater. | Must |
| Dynamic home repeater: a node's mail follows it to whichever repeater hears it, via backbone lookup | If a member moves across town, mail still finds them. | Should |
| Host-handoff procedure for a repeater house: checklist, transfer key, spare mount, new-host agreement | Repeater hosts move or lose interest. Decide in advance who takes it over. | Must |
| Deputy chain: every leader role has a named backup with their own key | If the main leader is unreachable, the system keeps running with a legitimate handover. | Must |
| Annual roster review and inactive-node cleanup (revoke lost or unused nodes) | Keeps the "not checked in" list honest. | Should |
C. When power, internet or radio fail
| Feature | Why | Priority |
|---|---|---|
| Everything works with no internet | Home Wi-Fi will be down. Email and VPN sync are bonuses, never requirements. | Must |
| Store-and-forward at every layer: node queues in flash, repeater queues in SQLite, retries with backoff | Messages survive power-offs and long gaps. | Must |
| Primary and fallback frequencies with a signed "move now" command | If a jammer or a new neighbor hits our channel, we can move without visiting every device. | Should |
| Priority lanes: Red/Black check-ins and leader alerts jump the queue; bulk sync and email wait | Congestion must never delay the worst emergencies. | Must |
| Low-power repeater mode: when battery is low, repeater stops Wi-Fi/dashboard but keeps radio + storage | Stretches runtime from days to weeks. | Should |
| Generator / car-charger input on repeaters | Days of overcast weather happen. | Should |
| Paper and window-sheet fallback (already in your kits) plus a printable check-in list | The system should still help when all the electronics are down. | Must |
D. Data safety
| Feature | Why | Priority |
|---|---|---|
| Append-only signed log with delta sync (already planned) | No single compromised or broken node can erase history. | Must |
| Quarantine, not delete for revoked nodes | You can review what a bad node did, and restore good data. | Must |
| Encrypted disks and role-based access on repeaters | A stolen Pi shouldn't expose the whole directory. | Must |
| "Break-glass" sealed envelope with recovery keys and passwords, held by two trusted people | Keys lost = system lost. | Must |
E. Seamless experience for ordinary people
| Feature | Why | Priority |
|---|---|---|
| One-tap check-in on the very first screen for returning users (after password) | Under stress, fewer taps wins. | Must |
| Plain-language status: "Sent to the node. Waiting for a repeater…" then "Safe at Zone 2" | People need to know it worked. Receipts do this. | Must |
| Printed one-page "if the page doesn't open" steps for iPhone and Android, including the fallback URL | Captive portals are the biggest usability risk. | Must |
| Quarterly drills with a short checklist, and a "drill mode" flag in the data | An unpracticed system fails. This matters more than any feature. | Must |
| Large-text, high-contrast, Spanish-ready pages | Works for older users and non-English speakers. | Should |
| Preset reasons on Yellow/Red (medical, trapped, no water, shelter, transport) | Faster than typing, and sortable by leaders. | Should |
| "Not checked in" list with auto door-to-door routes | The most valuable report in a disaster. | Must |
7. Go / no-go gates
Stop and decide at each gate. Don't spend on the next stage until the gate passes.
GATE 0 · about 2 weeksStock MeshCore on 3 XIAO kits plus the Pi bridge. Range survey with the ping bot. Pass: reliable links at expected distances.
GATE 1 · about 4 weeksSpectrum survey done and frequency chosen. Captive portal + HTTPS location tested on real iPhones and Androids. AA battery draw measured. Pass: portal works on current phones; battery plan acceptable.
GATE 2 · about 8 weeksLTAK message round trip: node → repeater → leader board, with receipts. Custom sync word and encryption. Pass: check-in shows on the board in seconds, survives power-off.
GATE 3 · about 3 months3 repeaters, 15 nodes, delta sync, revocation, backups, one live drill. Pass: drill works, failures are understood.
GATE 4 · laterMailbox + email, voice check-in, library, Meshtastic bridge, TAK export, screen kit, radio kit.
8. About the name "LTAK"
Dropping "mesh" is fine, and "LTAK" reads as LoRa + TAK, which suits the optional TAK export. Two things to check before printing labels:
- Close to an existing product. "loraTAK" is a commercial Meshtastic-to-TAK gateway from xTAK. I found no standalone LTAK project in this space, but the names are very similar. A short trademark search (USPTO) is worth doing.
- "TAK" is associated with a US government program (ATAK/TAK Product Center). If LTAK doesn't actually integrate with TAK, the name could mislead. If you do add TAK export, the connection is real, and you should still avoid implying official endorsement.
Sources
- LoRa mesh systems compared: can they talk to Meshtastic? (MeshAtlas)
- US 915 MHz rules for mesh radios (Mesh Radio Supply)
- FCC 15.247 and 500 kHz LoRa (NodakMesh)
- FCC regulations and MeshCore 500 (Philly Mesh)
- 47 CFR 15.247 text (read the primary text before finalizing)
- Is Meshtastic legal in the USA? (LoRa Mesh Atlas)
- Meshtastic LoRa configuration
- Meshtastic radio settings
- LongTurbo vs LongFast (NodakMesh) (unverified firmware-default claim)
- MeshCore companion protocol
- MeshCore payload format
- MeshCore Team Edition fork
- meshtacore (dual sync-word experiment)
- LoRaWAN US902-928 plan (TTN)
- RTL-SDR spectrum survey method (OKI Mesh)
- NodakMesh tools
- Meshtastic ATAK integration
- Meshtastic Android TAK docs
- loraTAK (xTAK) (name conflict check)
- KISS_LoRa_TAK
- disaster.radio layered model