Add a board-aware battery SOC system replacing the two independent
linear approximations that existed in the UI helpers.
New helpers/battery_curve.{h,c}: a 21-point (5% step) OCV lookup table
with integer linear interpolation. The default generic LiPo curve is a
weak symbol — any board can override it by dropping a battery_curve.c
into its board directory. CMakeLists.txt selects the board-specific file
when present, falling back to the generic.
Board.h gains getBattPercent() (default 0); ZephyrBoard implements it
via battery_curve_lookup().
Board-specific curves added for boards with measured cell data:
t1000_e, rak_wismesh_tag, thinknode_m6, sensecap_solar, wio_tracker_l1.
ADC multiplier corrections applied across all nRF52840 boards:
- Boards using a correctly-derived 3600×ratio formula get +0.5% to
compensate for nRF SAADC gain error (7200→7236, 6300→6332, etc.)
- rak_wismesh_tag, rak3401_1watt, gat562_30s had multipliers copied
from Arduino's 3.0V AREF formula; corrected to 3600×1.73×1.005=6259
- xiao_nrf52840 (10911) left unchanged — empirically calibrated value
above the theoretical, assumed already correct for that hardware
get adc.multiplier now reports current mV reading and the board's
curve 100% target, making field calibration self-guiding.
A room server is an endpoint, not a repeater. Strip the repeater
machinery the role inherited from the RepeaterMesh clone:
- allowPacketForward() returns false unconditionally — never relays
transit traffic. (Upstream's simple_room_server gates this on
disable_fwd; hard-off here since the role should never repeat.)
- neighbour tracking: NeighbourInfo/neighbours[], putNeighbour,
onAdvertRecv, removeNeighbor; formatNeighborsReply -> "not supported"
- node discovery: onControlDataRecv, sendNodeDiscoverReq, the
discover.neighbors CLI, discover rate-limiter + pending state
- loop detection: isLooped + max_loop_* tables + loop_detect pref
- dead code: RepeaterStats struct, GET_NEIGHBOURS handler, simple_sort
-344 lines net. Builds clean (FLASH 30.7% / RAM 32.2%); login, post,
push/sync, read-only guest and admin remote-management all
hardware-verified on the GAT562 kit.
- README: add Room Server to "Device Roles" + a build command in "Building"
- ARCHITECTURE.md: role list two -> four (add Room Server + the
previously-undocumented Observer)
- Repeater_CLI_commands.md: note the room server shares this CLI
- boards/example_board/README.md: add the room_server.conf build snippet
The room server's onAnonDataRecv handles login inline (the room login
protocol carries a sync_since cursor the repeater's doesn't), so the
cloned repeater helpers handleLoginReq + handleAnonRegionsReq /
handleAnonOwnerReq / handleAnonClockReq — and the anon_limiter they used
— were dead after the port. Remove them (~160 lines). No behavior change.
The inherited neighbor-tracking / node-discovery machinery is also unused
on a room server; left in place for now (can be trimmed in a follow-up).
StrHelper::strncpy null-terminates but does NOT zero-pad the 16-byte
password buffer, so setting a shorter password over a longer previous
value (e.g. one inherited from a prior repeater config) leaves trailing
garbage. onAnonDataRecv's constant-time compare runs over the full
buffer width, so a correct password stopped matching — admin/guest
logins were silently rejected, or downgraded to a read-only guest when
allow_read_only was on (the login looked identical to read-only).
Fix: copy both stored passwords into zeroed buffers (up to strnlen)
before the constant-time compare, so the comparison reflects the actual
string while staying constant-time over the full width.
Hardware-verified on the kit: admin login with the correct password now
grants ADMIN (post + remote management), confirmed server-side via
get acl (perms 03).
Note: the repeater's handleLoginReq shares this latent issue.
Cleanups 1–3 (cosmetic):
Removed the dead uart1_default/uart1_sleep pinctrl groups + stale "GPS on UART1" comments → gat562_30s-pinctrl.dtsi
Removed the QSPI pinctrl groups (board has no QSPI; pins collide with the joystick) and replaced them with a comment explaining why
Untangled the GPS UART0-vs-async rationale in the DTS and the &uart1 comment
GPS driver switch (functional, you approved the full switch) → gat562_30s.dts, board.conf:
gnss-nmea-generic → luatos,air530z with on-off-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH> (matches the sibling rak_wismesh_tag, same AT6558R chip)
Deleted the always-on gps_power_en gpio-hog (the driver owns P1.02 now → GPS can be powered down)
Removed the CONFIG_UART_ASYNC_API=y override
Updated all related comments
Two hardware-found fixes after on-air testing on the GAT562 kit:
- Add a 500ms push timer in main_room_server.cpp so the post-sync
engine advances at its intended cadence. ZephCore is event-driven
(no Arduino superloop), so without this the engine only ran on the
5s housekeeping tick — posts dripped out every ~5s and transmits
bunched up, causing timeouts/resends.
- Lower the post-sync hold from upstream's conservative defaults
(POST_SYNC_DELAY 6s -> 2s, PUSH_NOTIFY 2000ms -> 1000ms). These are
server-side timing only (no wire-format change), and take measured
delivery from ~6-7s down to ~2s.
Verified on hardware (910.525/62.5/SF7/CR8, two clients): normal-pace
messages deliver in ~2s with clean ACKs. Rapid-fire bursts can still
drop out-of-order messages via the per-client timestamp replay check
(unchanged from upstream) — left as-is to stay upstream-compatible.
Add the MeshCore Room Server role to ZephCore — a store-and-forward
shared message room. Clients log in with an admin or guest password
and post messages; the server pushes each new post to all other
logged-in clients (round-robin, per-client sync cursor, ACK + retry,
3-strike eviction).
Ported from upstream MeshCore's simple_room_server, structured as a
near-clone of RepeaterMesh so it reuses the proven ACL, region
filtering, CLI, adverts and telemetry; the post buffer + push engine
are the only net-new pieces:
- RoomServerMesh: PostInfo ring (MAX_UNSYNCED_POSTS=32), addPost,
pushPostToClient, getUnsyncedCount, processAck, onAckRecv, the
loop() push driver; room login (onAnonDataRecv parses the
sync_since cursor); posts/admin-CLI/keep-alive (onPeerDataRecv);
ADV_TYPE_ROOM advert; ServerStats wire layout; disable_fwd=1.
- main_room_server.cpp: event-loop entry (USB serial CLI, no BLE).
- Kconfig: ZEPHCORE_ROLE_ROOM_SERVER + ZEPHCORE_MAX_UNSYNCED_POSTS.
- CMakeLists role gating; boards/common/room_server.conf.
Post frame, SHA-256 ACK and login-reply layouts match upstream for
MeshCore app compatibility. Builds for gat562_30s
(FLASH 30.95% / RAM 32.46%). Not yet hardware-tested.
The GAT562 30S Mesh Kit is an nRF52840 + SX1262 board built on the
RAK4631 WisBlock core module with a 30 dBm (1 W) external PA, so it
reuses the proven rak4631 LoRa path. Deltas vs rak4631: 1.8 V TCXO
(per the MeshCore variant), battery multiplier 6232, buzzer on P1.01,
an AT6558R UART GPS, active-high LEDs, and a 5-way joystick that
selects the joystick companion menu UI.
A single board serves both the full kit and the screenless solar
repeater pod; absent peripherals (OLED, GPS, joystick, buzzer) are
optional in devicetree and skipped at runtime.
Board-specific notes:
- GPS: AT6558R NMEA on UART0 @ 9600 (P0.15 RX / P0.16 TX), powered by a
WB_IO2/P1.02 gpio-hog and parsed by gnss-nmea-generic. Uses
CONFIG_UART_ASYNC_API (DMA receive); nRF UARTE interrupt-driven RX did
not feed the modem backend.
- The 6 button/joystick inputs are routed to GPIO SENSE (sense-edge-mask
on &gpio0) so they don't consume the GPIOTE channel the SX1262 DIO1
"done" IRQ needs.
Registration: board definition, CMakeLists.txt platform-conf match,
build.sh (nRF_boards), supported_boards.md, the top-level README board
table, and the porting-guide board table.
Hardware-tested on the kit, companion and repeater: LoRa TX/RX with BLE
active (no CAD errors), BLE pairing (PIN 123456) and two-way messaging,
joystick menu UI, SSD1306 OLED, buzzer, battery %, UF2 + DFU-zip
flashing, and a 14-satellite GPS fix.
Swap the vendored orlp/ed25519 (frozen ~2017 ref10) for Monocypher
4.0.2, an actively maintained, audited, single-file implementation.
The persisted private key keeps its 64-byte expanded layout
(clamped SHA-512(seed) scalar a || nonce prefix), so identities
written by older firmware load, sign, verify and key-exchange
unchanged -- no re-key, no storage migration, full wire
compatibility with the existing mesh and Arduino MeshCore.
Because the stored key carries no seed for Monocypher's high-level
EdDSA API, Identity drives signing from the low-level primitives
(crypto_sha512 + crypto_eddsa_reduce/scalarbase/mul_add); verify
uses crypto_ed25519_check and ECDH uses crypto_eddsa_to_x25519 +
crypto_x25519. Nonce material is now wiped after signing.
Validated byte-for-byte against the previous orlp output via a
known-answer harness (keygen, sign-from-expanded-key, verify
accept/reject, X25519-over-Ed25519 shared secret) before the swap.
Frees ~42 KB of flash: orlp linked ~55 KB (dominated by its ~30 KB
ref10 precomputed tables); the Monocypher Ed25519/X25519/SHA-512
paths link ~14 KB, with --gc-sections dropping all unused algos.
wio_tracker_l1 pristine build: FLASH 54.14%, links clean.
Monocypher is CC0-1.0 OR BSD-2-Clause.
A device-side cable yank often skips the DTR=0 line-state change, so the
companion stayed stuck on the USB interface and rejected every BLE
connection until reboot. Treat USBD_MSG_VBUS_REMOVED as a DTR drop.
Companion BLE/USB direct & zero-hop sends enqueue with delay 0 from
sysworkq, off the main loop. Since 57b971f dropped the per-frame RX
wake, fire the tx-queued callback for delay 0 too so they actually
drain (USB companion has no tx-idle backstop and would stall).
Channel replies from the Unread screen passed index -1, which
sendComposedMessage can't route, so they silently failed to send. Look
up the real channel slot by name and bail if it can't be resolved.
liquidraver