ARGUS REDLINE v0.3.0 — Device Runtime, Screens, and Input

ARGUS REDLINE v0.3.0 Release Notes

Device Runtime, Screens, and Input

ARGUS REDLINE v0.3.0 adds the first shared on-device interface and diagnostic
runtime for the existing single-Hub/single-Node system. Radio and transaction
processing remain independent of the selected screen and OLED power state.

Major additions

• Added deterministic, polled GPIO0 input using active-low INPUT_PULLUP, a
  30 ms debounce threshold, and an 800 ms long-press threshold.
• Added firmware-level suppression for a button already held when application
  code starts. A complete debounced release is required before accepting input.
• Added six shared screens: Home, Radio, Device, Last Packet, Diagnostics, and
  About. Short press advances one screen; long press returns Home.
• Added a 30-second OLED inactivity timeout. The first press wakes the selected
  screen without navigation, and the remainder of that gesture is suppressed.
• Added dirty rendering capped at 10 Hz and live-screen refresh capped at 1 Hz.
  Routine radio activity does not wake the OLED.
• Expanded hardware-independent runtime presentation state with health, error,
  metric availability, activity, the latest decoded inbound packet, saturating
  diagnostic counters, and role-specific peer presentation.
• Added bounded, role-aware presentation snapshots and a shared Heltec/
  ThingPulse OLED renderer with one canonical RG bitmap.
• Added permanent PlatformIO library manifests for the reusable component
  dependency graph.
• Integrated the interface shell into both Hub and Node firmware while keeping
  radio, transaction, duplicate, and input policy in their established owners.

Role-specific behavior

Hub

• Peer presentation uses UNKNOWN, REACHABLE, and DEGRADED based on
  completed transaction results.
• Diagnostics expose transmissions, successful transactions, retries, ACK
  timeouts, malformed or ignored packets, and the latest error.
• Last Packet displays the latest decoded inbound ACK and its raw status when a
  valid one-byte ACK payload is available.

Node

• Peer presentation uses only UNKNOWN and SEEN; silence does not imply Hub
  absence.
• Diagnostics expose decoded packets, accepted commands, completed ACK
  transmissions, duplicates, malformed or ignored packets, and the latest
  error.
• Last Packet is inbound-only and normally displays COMMAND metadata. Outbound
  ACK history is not stored.
• OLED work remains deferred during ACK transmission and until receive mode has
  restarted.

Compatibility

• Firmware identifier: v0.3.0.
• Protocol v0.1 remains Wire Protocol version 1 and is byte-compatible with
  v0.2.0 peers when device configuration matches.
• Packet layout, packet-type values, TEST=0x64, ACK statuses, byte order,
  addressing, and codec rules are unchanged.
• Hub and Node IDs remain compile-time configuration values.
• Retry limits, timeout boundaries, retry delay, sequence lifecycle, ACK
  matching, validation order, and single-entry duplicate semantics are
  unchanged.
• Duplicate ACKs continue to be regenerated from remembered transaction
  metadata and status.

Validation

• Native tests: 178/178 passed.
• Valid Hub and Node configuration fixtures passed.
• Missing-local-ID, missing-peer-ID, and equal-ID fixtures failed with their
  exact intended compile-time diagnostics.
• Hub tx, Node rx, and the unqualified production build passed.
• Final Hub size: 20,216 bytes RAM and 334,477 bytes flash.
• Final Node size: 20,240 bytes RAM and 331,625 bytes flash.
• Two Heltec WiFi LoRa 32 V4.3 boards passed the physical interface and radio
  regression.
• Fourteen consecutive baseline exchanges passed across sequences 9–22.
• Sequences 53–55 each exhausted exactly two retries and terminated; automatic
  recovery began at sequence 56 without resetting the Hub.
• Approximately ten minutes of concurrent navigation, OLED timeout/wake,
  TEST/ACK traffic, and Node interruption/recovery completed without observed
  reset, hang, receive gap, alternating loss, or sequence anomaly.

See the complete v0.3.0 two-board regression record.

Known limitations

• GPIO0 is an ESP32-S3 boot-strapping pin. Holding it during reset can select
  ROM bootloader behavior and prevent normal application startup. Firmware
  startup-held suppression applies only when the application actually boots.
• A controlled physical duplicate condition was not reproduced. Duplicate
  handling remains covered by native transaction-engine tests and source audit.
• Physical malformed/unsupported packet injection was not performed, and no
  production test behavior or packet injector was added. Native tests and
  source audit remain the evidence for those paths.
• There is no authentication, encryption, replay protection, persistent
  settings, runtime provisioning, multi-Node coordination, repeater, routing,
  store-and-forward, production ARGUS integration, or production application
  command set.
• ARGUS REDLINE remains experimental, has not been independently audited, and
  is not safety-certified or suitable for life-safety reliance.