next_check and next_gps_update stored a future millis() value in a signed
long and compared with a naive '>'. After the ~24.8-day millis() sign flip
the deadline sits above the wrapped millis(), so the block never runs again
and GPS->RTC time-sync (and the location cache refresh) stall permanently
until reboot. Switch to unsigned deadlines with the wrap-safe signed-
difference compare '(long)(millis() - deadline) > 0', matching the idiom in
Dispatcher::millisHasNowPassed.
Also: reorder the MicroNMEALocationProvider ctor init-list to declaration
order (silences -Wreorder) and drop the always-true 'if (_claims > 0)' guard
in claim() (claim() always runs after _claims++, so it is >= 1).
Previously load() returned true unconditionally on file-open success,
masking truncated or corrupt /regions2 files. Additionally, the first
field of each entry record (r->id) used the same success-chaining
pattern as subsequent fields, so a clean EOF at a record boundary set
success=false and would have been indistinguishable from real
corruption once the return value was fixed.
The r->id read is now split out: n==0 is a clean EOF (break, success
retains its prior value from the header read), n!=sizeof(r->id) is a
partial read or corruption (break, success=false). load() now returns
success instead of an unconditional true, so its return value reflects
the actual parse outcome.
Companion fix to #2372, which fixed the same return-true hardcoding
in save(). (#1891 originally reported this on load() but was closed
when #2372 landed — that PR only touched save(); this addresses the
load() side.)
GPS support was implemented incorrectly for the ThinkNode M3. The reset
pin was being driven when it should be left floating for this unit. The
enable pin also wasn't being picked up by `MicroNMEALocationProvider`
because of a mismatch in constant naming conventions. I did a general
cleanup of the GPS and ThinkNode M3 bring-up code so that constant names
line up and "*_ACTIVE" constants are used consistently vs hardcoding
`HIGH`/`LOW`. After making these changes, serial data immediately starts
streaming in from the NMEA on boot and GPS detection just works.
LED handling was also not quite right for the ThinkNode M3. The LoRa TX
LED was being driven high to turn it on when it should actually be
driven low. I changed the code to use the `LED_STATE_ON` constant and
also added a little code to the shutdown path to properly make sure that
all LEDs are turned off.
Tested and confirmed working on real hardware.
Resolves both #1864 and #2879.
hasSeen() was simultaneously a predicate and a mutator — it inserted the
packet hash on every miss, making five call sites that only wanted to mark
a packet as sent call it with the return value discarded.
Split into:
- wasSeen() — pure predicate, no side effects
- markSeen() — explicit insert
All query sites now call markSeen() immediately after wasSeen() returns
false, preserving identical runtime behaviour. The five mark-only send
sites (sendFlood, sendDirect, sendZeroHop x2) now call markSeen directly.
Also fixes three bridge sites (BridgeBase, ESPNowBridge, RS232Bridge)
that had the same query+implicit-insert pattern.
Tests: add test/test_mesh_tables/ covering wasSeen purity, markSeen,
dup stats, and clear. Update SHA256 mock to produce deterministic output
(previously finalize() was a no-op). Add Packet.cpp to native build filter.
- Added build flag "SX126X_USE_REGULATOR_LDO" (set to 1 to enable) to use LDO for the SX1262 radio instead of DC-DC when the DCDC pin isn't wired up (e.g. t-echo lite)
- Added additional debug mode diagnostic messages during SX1262 init to better highlight faults
While working on some sensor code implementations, I ran into
some hard crashes that root-caused to the 4KB loop task stack
being exhausted.
Looking for various optimization schemes resulted in this relatively
low-lift fix. RAK3401 and RAK4631 both support hardware crypto.
Rather than loading in one of the two software crypto libs,
we can just use the onboard hardware. This is faster, should
consume less power, and in testing used a scant up to 700
bytes in the run loop vs 2.5-3KB per advert.
This change **only** affects advert verification processing, which
currently consumes a significant chunk of the 4KB run loop.
I figured such a change should likely be implemented in phases.
After soaking, this hardware crypto verification
process could be implemented across the entire MeshCore
cryptographic function on RAK nodes. Also possible other nodes
have available hardware crypto, however, I have not checked,
so future improvements may also exist there.
Tested on:
- RAK3401 RAK 1W
- RAK4631 19001
The SH1106 OLED on the LilyGo T-Beam Supreme V3 never lights up because:
1. The primary I2C bus (Wire) that the OLED, BME280 and magnetometer share
is never initialized. The PMU/RTC use Wire1 (via XPowersLib); nothing
brings up Wire on PIN_BOARD_SDA/PIN_BOARD_SCL, so the display driver
talks on the wrong default pins.
2. The OLED is at I2C address 0x3D on this board (0x3C is taken by the
QMC6310 magnetometer), but SH1106Display::begin() only tried 0x3C.
Initialize Wire for TBEAM_SUPREME_SX1262, and have SH1106Display::begin()
prefer 0x3D (only ever used by the OLED) before falling back to 0x3C.
Backwards-compatible for boards with the OLED at 0x3C.
Closes#2609
Ryan Gregg