The `::init` method in the Adafruit ST7789 library is responsible to
initialize the device. This includes performing a reset, which can be
found in the Adafruit source for `Adafruit_SPITFT`.
Before this change, MeshCore performed its own ST7789 display reset
sequence, which consisted of three steps.
* Pull reset low
* Wait 10ms
* Pull reset high
Importantly, there was no fixed delay after pulling reset high. The
ST7789 driver requires a delay (T<sub>RT</sub>) of 5ms in Sleep In Mode
and 120ms in Sleep Out Mode before it will properly receive commands.
When `Adafruit_SPITFT` resets the device after MeshCore has already
reset it, the mandatory time may not have elapsed, leading to strange
behavior. In the author's case, this issue caused the initial
`fillScreen` to fail, such that the display showed an uninitialized
framebuffer.
This removes the MeshCore delay, leaving the responsibility of reset to
`Adafruit_SPITFT`, where they have the correct delays in place with
extra safety margin. The change was briefly tested by Josiah VanderZee
and Ben Zignego on a custom hardware build using an nRF52840 Dongle and
an Adafruit 4311 TFT display. The user button seemed to behave
strangely, but the display looked correct.
_have_time_sync is reset to false whenever WiFi disconnects, even
though the ESP32 RTC continues to hold accurate time after a
successful SNTP sync. This caused hasTimeSync() to return false
during transient WiFi outages, unnecessarily tearing down MQTT
broker connections and suppressing packet publishing.
Introduce _last_time_sync to record the wall-clock time of the
most recent confirmed sync. Move hasTimeSync() out of the header
into NetworkService.cpp and extend its logic: in addition to the
existing _have_time_sync flag, return true if the system clock is
still sane (>= kMinSaneEpoch) and no more than kMaxOutOfSync (24h)
has elapsed since the last confirmed sync.
This makes the MQTT uplink resilient to brief WiFi dropouts without
requiring any changes to callers of hasTimeSync().
Also bump kMinSaneEpoch from 2025-01-01 to 2026-01-01.
There's no known reason why additional firmware build of this board
with serial logging enabled was needed.
So, removing it for now to optimize building process and cleanup
firmware list.
USE_LR1110 was missing from the preprocessor guard in CommonCLI.cpp,
causing both get and set to fail silently on T1000-E:
- get radio.rxgain returned the full radio config string (fell through
to the memcmp("radio", 5) branch)
- set radio.rxgain returned "unknown config" (no branch matched)
Fix: add -D USE_LR1110 to variants/t1000-e/platformio.ini and include
USE_LR1110 in the #if guard on both get and set branches.
CustomLR1110Wrapper already implements setRxBoostedGainMode() and
getRxBoostedGainMode() via the RadioLibWrapper virtual interface,
so no radio-layer changes are required.
Tested on T1000-E: get/set/persist all confirmed working.
Josiah VanderZee