KYKR — Solar Router

Note on COM ports: The COM## numbers in this guide are the author’s own, shown as examples — your port will differ. On Windows, open Device Manager → Ports (COM & LPT) with the node plugged in to find the COM number your device enumerated as, and use that in place of the example in every command. On macOS/Linux the equivalent is a /dev/tty.*, /dev/ttyUSB*, or /dev/ttyACM* path. Always confirm your own port before running these commands.

Purpose & Role

KYKR is the fleet’s infrastructure router: a solar node mounted outdoors (destined for a boat-lift piling) whose only job is to relay mesh traffic and extend range. It has no screen, is not carried, and is not where anyone reads or sends messages. Everything about its configuration is tuned for two things: efficient relaying and surviving unattended on solar power.

Because a dedicated router already covers this area, the personal/mobile nodes are kept as quiet clients near home (see their docs) — KYKR is the one node whose job is to rebroadcast.

---

1. Configuration (verified over RF)

Section	Setting	Value	Purpose
Device	role	ROUTER	Dedicated relay; participates in routing
Device	rebroadcast_mode	CORE_PORTNUMS_ONLY	Rebroadcasts only core protocol packets — keeps relay traffic lean
Device	node_info_broadcast_secs	10800	NodeInfo every 3 h
LoRa	region	US	—
LoRa	modem_preset	MEDIUM_FAST	Must match the mesh
LoRa	hop_limit	5	Fleet standard (see hop-limit justification)
LoRa	tx_power	30	Full legal power — maximises relay reach
Position	fixed_position	true	Stationary node; position is pinned
Position	position_broadcast_secs	43200	12 h — see note below
Position	position_flags	811	Altitude, etc.
Power	sds_secs	86400	Super-deep-sleep timer (24 h) — solar survival
Power	ls_secs	86400	Light-sleep timer (24 h) — solar survival
Power	wait_bluetooth_secs	1	Minimal BLE-on time to save power
Neighbor Info	enabled	true	Broadcasts mesh topology info
Neighbor Info	update_interval	14400	Every 4 h — low airtime cost
Neighbor Info	transmit_over_lora	true	Topology data shared over RF
MQTT	enabled	false (default)	Not a gateway — no internet path

Router position broadcast (known behaviour): KYKR will not hold position_broadcast_secs below 43200 (12 h). Values like 3600/7200 ack but revert to 43200 on reboot — this is the ROUTER role enforcing its own floor, tried repeatedly across CLI and GUI. The pin looking “stale” on the map is the expected result, not a failed write. Do not keep re-attempting a shorter interval.

Why the long sleep timers: as a solar node that may be isolated, KYKR uses 24 h super-deep/light-sleep timers and a 1 s Bluetooth wait so it conserves power when unattended. These are deliberate, not defaults.

---

2. CLI Procedure (remote, over RF from a master)

KYKR is a fixed solar node — usually configured remotely over RF from a master node (KYKM/M1 holds an admin key for it), not on a cable. Remote --set reboots the router and RF round-trips are slow; allow a couple of minutes and re-read to confirm. Config values commit reliably this way (the ACK confirms); the admin-key list and channel PSKs do not verify remotely and are best done on serial.

Core config (over RF, from KYKM on COM19):

meshtastic --port COM19 --dest "!bbdb521e" --set device.role ROUTER
meshtastic --port COM19 --dest "!bbdb521e" --set device.rebroadcast_mode CORE_PORTNUMS_ONLY
meshtastic --port COM19 --dest "!bbdb521e" --set lora.hop_limit 5
meshtastic --port COM19 --dest "!bbdb521e" --set lora.tx_power 30
meshtastic --port COM19 --dest "!bbdb521e" --set position.fixed_position true

Public channel precision (approximate location):

meshtastic --port COM19 --dest "!bbdb521e" --ch-index 0 --ch-set module_settings.position_precision 13

Solar-survival power tuning (long sleep timers) is set on serial when the node is built; it is not changed remotely.

To do any of this on a cable instead, substitute --port <PORT> for --host/--dest and drop the --dest. Then verify (Section 5).

3. Channels

Index	Name	Precision	Purpose
0	(primary, default key)	—	Public channel
1	(private)	—	Private traffic — excluded from public docs
2	Reach-Ed	0 (off)	Public contact channel (text only)

Reach-Ed on the router — status and caveat. Reach-Ed was added to KYKR at index 2 over RF, with uplink OFF, downlink OFF, and position precision 0 (text only) — all confirmed. The shared PSK write could not be verified over RF (a remote node’s full channel table can’t be read back; --info is local-only). The channel therefore may still carry an auto-generated key rather than the shared Reach-Ed key.

Because KYKR is a CORE_PORTNUMS_ONLY router, this channel is essentially cosmetic on this node — the router relays core mesh traffic regardless of which channels it holds, and no one reads messages on a screenless router. Reach-Ed’s real home is the handheld (KYKM).

Serial follow-up (do when the router is next accessible): connect over serial/BLE, run --info to read channel 2, and if the PSK is not the shared Reach-Ed key, set it solo:

meshtastic --port <PORT> --ch-index 2 --ch-set psk "base64:<shared Reach-Ed key>"

Verify with --info. Until then, treat KYKR’s Reach-Ed as present-but-unverified.

---

4. Remote Administration

KYKR is a non-master node and is administered by the fleet masters. Current admin-key state: holds M1 and M5 (and a duplicate M5 in the third slot); M2 is not present. It is therefore remotely admin-able from the handheld (M1) and travel node (M5) today — which is how this configuration was read and changed, over RF from KYKM.

Admin over RF works for config values (the hop_limit 3→5 change and all reads here went through and ACKed). It is not reliable for the admin-key list itself — clearing the duplicate and adding M2 needs a serial connection (the reliable path), and KYKR is the hardest node to reach physically. This is deferred: the router is fully manageable from two masters as-is, so fixing the duplicate/adding M2 waits for serial access rather than risking the working M1/M5 admin on an RF list-write.

See the Admin-Key ADR for the fleet model.

---

5. Verification (remote, over RF from a master)

Remote reads are per-section (--info is local-only). From KYKM:

meshtastic --port COM19 --dest "!bbdb521e" --get device
meshtastic --port COM19 --dest "!bbdb521e" --get lora
meshtastic --port COM19 --dest "!bbdb521e" --get position
meshtastic --port COM19 --dest "!bbdb521e" --get power
meshtastic --port COM19 --dest "!bbdb521e" --get neighbor_info

Expected: role ROUTER, rebroadcast_mode CORE_PORTNUMS_ONLY; lora hop_limit 5, MEDIUM_FAST, US, tx_power 30; fixed_position true, position_broadcast_secs 43200; power sds/ls 86400, wait_bluetooth 1; neighbor_info enabled, 14400, over LoRa; mqtt enabled absent (= false).

Channel verification and the Reach-Ed PSK require a local (serial/BLE) --info — not possible over RF.

---

6. Operating Notes

• KYKR is fixed infrastructure — relay and solar survival are the whole design.
• ROUTER + CORE_PORTNUMS_ONLY: it rebroadcasts core traffic efficiently and doesn’t chatter.
• It is not an MQTT gateway (that’s KYKB) — no internet path; stale map-report settings on it are inert.
• Position shows as ~12 h updates by design; a stale-looking map pin is expected.
• Serial to-do list for next physical access: (1) verify/set Reach-Ed PSK at index 2; (2) clear the duplicate admin key and add M2; (3) optionally clear the inert MQTT map-report settings.