Ground: Seismic & Acoustic Perimeter Mesh

Five nodes means flashing has to be boring and repeatable, so I drive everything from the command line: the Arduino-ESP32 core installed with arduino-cli, firmware compiled and uploaded the same way every time, and the SX1262 radio driven through the RadioLib library. The region is fixed at 915 MHz, the North American ISM band; 868 MHz hardware is for Europe and stays out of this build.

FLASH A HELTEC V3 NODE (macOS)

# toolchain and board core
arduino-cli core update-index
arduino-cli core install esp32:esp32

# build and upload over USB
arduino-cli compile --fqbn esp32:esp32:heltec_wifi_lora_32_V3 firmware/node
arduino-cli upload  --fqbn esp32:esp32:heltec_wifi_lora_32_V3 \
  --port /dev/cu.usbserial-0001 firmware/node

What can go wrong: a board that will not enumerate usually needs BOOT held during reset to enter the download stub. How I verified: arduino-cli monitor shows the boot banner and radio.begin() returning RADIOLIB_ERR_NONE on every board before it gets a node ID.

Before designing any mesh topology I wanted the honest hop distance, not the number on the datasheet. One node beacons from the bench at a fixed 10 dBm; I walk the second node down the street while the receiver logs RSSI and SNR for every decoded packet to a CSV over serial. That log is what decides node spacing later.

RANGE SNIFFER, RECEIVER CORE (RADIOLIB)

// freq MHz, BW kHz, SF, CR, sync, power dBm, preamble, TCXO
int state = radio.begin(915.0, 125.0, 9, 5, 18, 10, 8, 0);
radio.startReceive();
// in loop(), on DIO1 interrupt:
int len = radio.getPacketLength();
if (radio.readData(rx, len) == RADIOLIB_ERR_NONE) {
  Serial.printf("%lu,%s,%.0f,%.1f\n", millis(), rx,
                radio.getRSSI(), radio.getSNR());
}

CAPTURE THE LOG

arduino-cli monitor -p /dev/cu.usbserial-0001 \
  --config baudrate=115200 > range-log.csv

What can go wrong: RSSI comparisons are meaningless if TX power or spreading factor changes between runs, so both are pinned in firmware. How I verified: I walk the same route twice at different times of day so I can sanity-check repeatability before trusting the map.

The ADXL355-class MEMS accelerometer rides on the SPI bus; the ADXL355 supports both SPI and I2C, but SPI is the wiring choice here because it avoids I2C pull-up noise at speed, and it streams the vertical (Z) axis at roughly 1 kHz. The enclosure base carries a spike that couples the sensor into the ground; coupling quality matters more than sensor price, a loose box is just a wind detector.

ADXL355 SELF-CHECK AND STREAM SETUP

SPI.begin(SCK, MISO, MOSI, CS);
SPI.beginTransaction(SPISettings(10000000, MSBFIRST, SPI_MODE0));

uint8_t id = spiRead(0x00);          // DEVID register
if (id != 0xAD) { Serial.println("ADXL355 not found"); while (true); }

spiWrite(0x2C, 0x01);                // RANGE: +/- 2 g
spiWrite(0x28, 0x02);                // FILTER: ODR 1000 Hz
spiWrite(0x2D, 0x00);                // POWER_CTL: measurement mode
// then burst-read XDATA3..ZDATA0 (0x08..0x10, 9 bytes) per sample

What can go wrong: reading all 0x00 or all 0xFF means the wrong SPI mode or a CS wiring mistake, the 355 is strictly MODE0. How I verified: the DEVID self-check at boot, then a bench drop test watching the Z axis spike in the serial plotter at the expected polarity.

A 1 kHz stream is far too much to send over LoRa and too much to classify raw on a microcontroller, so each node windows 1024 samples (about one second) and compresses the window into a small feature vector: RMS amplitude plus the energy in three spectral bands from an FFT. The classifier downstream sees a handful of numbers per second, not a thousand samples.

WINDOW TO RMS + BAND ENERGIES (ARDUINOFFT)

static double vReal[1024], vImag[1024];   // static: no heap churn
ArduinoFFT<double> FFT(vReal, vImag, 1024, 1000.0);

double rms = 0;
for (int i = 0; i < 1024; i++) { vReal[i] = z[i]; vImag[i] = 0; rms += z[i]*z[i]; }
rms = sqrt(rms / 1024);

FFT.dcRemoval();
FFT.windowing(FFTWindow::Hamming, FFT_FORWARD);
FFT.compute(FFT_FORWARD);
FFT.complexToMagnitude();
// sum bins into bands: 5-20 Hz (vehicle rumble),
// 20-80 Hz (footstep energy), 80-250 Hz (broadband / wind)

What can go wrong: allocating those FFT buffers per window fragments the ESP32 heap within hours, they are static. How I verified: a host-side unit test feeds a synthetic 50 Hz sine through the same code path and confirms the energy lands in the expected band before I trust the on-device version.

First pass is explainable thresholds, because a rule I can read is a rule I can debug in the field: quiet gating on RMS, vehicles as sustained low-band-dominant energy that grows and fades as they pass, footsteps as a periodic cadence peak in a walking band, and everything else filed as wind or unknown. The second pass, once my labelled dataset is big enough, is a tiny model trained in Python and converted with TensorFlow Lite Micro (via Edge Impulse) running on the same feature vector.

THRESHOLD CLASSIFIER, FIRST PASS

const char* classify(float rms, float bandLo, float bandMid, float dur) {
  if (rms < NOISE_FLOOR * 3.0f)             return "quiet";
  if (bandLo > 0.6f && dur > 2.0f)            return "vehicle";
  if (cadenceHz > 1.5f && cadenceHz < 2.5f)   return "footsteps";
  return "wind_or_unknown";
}

EMBED THE ML MODEL WHEN IT SHIPS

xxd -i model.tflite > model_data.h   # C array, compiled into firmware

What can go wrong: thresholds tuned on one node do not transfer, soil, mounting, and sensor variance all shift the noise floor, so each node runs a quiet-period calibration on install. How I verified: labelled recordings are replayed through the classifier on the host first; a firmware build only gets flashed if the replay matches the expected labels.

The mesh carries a small fixed-format packet: version, type, source node, hop counter, per-source sequence number, payload, and a CRC. Forwarding is controlled flooding over raw LoRa (this is application-level flooding, not LoRaWAN), every node that hears a packet retransmits it once, with the hop counter as the kill switch and a (src, seq) seen-cache as the dedup. Spreading factor 9 at 125 kHz bandwidth is my range-versus-airtime compromise for this spacing.

MESH PACKET FORMAT (FIRMWARE)

struct MeshPacket {
  uint8_t  version;      // 0x02
  uint8_t  type;         // 0x01 detection, 0x02 ack, 0x03 heartbeat
  uint8_t  src;          // node id 1-5
  uint8_t  hops;         // incremented per forward, dropped at 4
  uint32_t seq;          // per-source sequence; dedup key with src
  uint8_t  payload[180];
  uint16_t crc16;
} __attribute__((packed));

What can go wrong: without the seen-cache, two forwarding nodes ping-pong the same packet forever; and simultaneous retransmits collide, so each node adds a randomized backoff keyed on its ID. How I verified: a three-node bench flood with the relay node powered off mid-test, confirming the remaining path still delivers and no packet loops.

Gateways reboot, links drop, and I will absolutely break the gateway while tinkering. When no ACK comes back, the node appends the signed detection to an append-only log in LittleFS and keeps sensing. On link restore it replays oldest-first, waiting for the gateway ACK before truncating each record, the same store-and-forward pattern as my DDIL-proof DevOps work, shrunk onto a microcontroller.

BUFFER AND REPLAY (LITTLEFS)

if (!gatewayAcked) {
  File f = LittleFS.open("/queue.bin", FILE_APPEND);
  f.write((uint8_t*)&det, sizeof(det));
  f.close();
}
// on reconnect: read oldest record, retransmit,
// wait for ACK(seq), then truncate. Repeat until empty.

What can go wrong: flash wears out and filesystems fill, the queue is capped, drop-oldest events are counted and reported in the heartbeat, and only detections are ever buffered, never raw waveforms. How I verified: pull the gateway's power for a set interval, generate detections, restart it, and confirm every sequence number arrives without loss and in order, with the (src, seq) dedup giving effectively-once processing after deduplication on repeats.

The gateway is a Raspberry Pi wearing a LoRa HAT on the 40-pin header. A small Python service decodes mesh packets, verifies the Ed25519 signature against a per-node public key table, drops replays via the (src, seq) dedup, and republishes clean detections to mosquitto, which listens on localhost only, so the broker is never exposed to the LAN.

GATEWAY SERVICE (PYNACL + PAHO-MQTT)

from nacl.signing import VerifyKey
import paho.mqtt.client as mqtt

def on_packet(pkt):
    det, sig = split_payload(pkt)
    if seen(det["src"], det["seq"]):
        return                                  # replay, drop
    VerifyKey(pubkeys[det["src"]]).verify(det_bytes, sig)  # raises on forgery
    mq.publish("perimeter/ground/detections", json.dumps(det), qos=1)

BROKER CONFIG, LOCALHOST ONLY

# /etc/mosquitto/conf.d/perimeter.conf
listener 1883 127.0.0.1
allow_anonymous true

What can go wrong: every HAT wires CE and reset to different GPIOs, read the HAT's docs instead of assuming. How I verified: a negative test, I sign a packet with the wrong key and confirm the service rejects it and logs the attempt, because a verifier that never fails is a verifier that is not running.

Each node runs on 18650 cells in protected holders, topped up by a small solar panel through a charge board, inside a weatherproof box with IP65 glands for the sensor and panel leads. The power budget, not the sensor, decides whether a node survives a dark January week, so the firmware duty-cycles hard: wake, sample a one-second window, classify, transmit only if there is a detection, deep sleep again.

DUTY-CYCLE SLEEP (FIRMWARE)

// one sensing cycle done; radio off, sleep until next window
esp_sleep_enable_timer_wakeup(4 * 1000000ULL);
esp_deep_sleep_start();   // ESP32 chip deep sleep is microamp-class; the full board
                         // (regulator, USB-UART bridge, charge circuit) draws more, measure the board

What can go wrong: a radio TX burst can brown out a cold or tired cell mid-packet, hence the bulk capacitor across the rail, and the standing rule that a frozen Li-ion cell warms up before it ever sees charge current. How I verified: a multimeter in series over many full duty cycles, checking the measured average current matches the spreadsheet budget before the box gets sealed.

Every node owns an Ed25519 keypair; the private key never leaves the device. Each detection is serialized, signed on the node with libsodium's Ed25519 implementation (RFC 8032), and the gateway verifies before anything reaches the common operating picture. A forged or corrupted message dies at the gateway, which is exactly where untrusted input should die. Note on library choice: Monocypher's default crypto_eddsa_* is a BLAKE2b-based EdDSA variant, not interoperable RFC 8032 Ed25519, so it would not verify against the PyNaCl gateway; libsodium's crypto_sign_detached is used instead, which the gateway verifies with PyNaCl.

DETECTION MESSAGE, WHAT LEAVES THE NODE

{
  "node": 2, "seq": 1187, "ts": 1758268800,
  "class": "vehicle", "conf": 0.91,
  "rms": 0.042, "bands": [0.61, 0.28, 0.11],
  "sig": "Ed25519 signature over the fields above, base64"
}

SIGN ON THE NODE (LIBSODIUM, RFC 8032 ED25519)

crypto_sign_detached(sig, NULL, msg, msg_len, sk);   // detached Ed25519 signature; sk is the 64-byte libsodium secret key, verified on the gateway with PyNaCl

What can go wrong: key management is the weak point, private keys are generated per node and recorded offline, and a lost key means a reflash, not a recovery procedure. How I verified: flip one byte in a signed message and confirm the gateway rejects it; the negative test is the test that matters.

The three SM-24 geophones are the sensitivity upgrade: a true moving-coil geophone picks up vehicle signatures at ranges a MEMS accelerometer cannot touch. The SM-24 feeds a low-noise preamp and then an ADS1256-class 24-bit ADC, which shares the SPI bus with the ADXL355 on its own chip-select, so the feature pipeline and classifier carry over unchanged and only the front-end driver differs. The three labelled geophones in the bench photo are staged for exactly this swap.

SM-24 FRONT END (ADS1256, SHARED SPI)

adc.begin(SCK, MISO, MOSI, CS_ADC, DRDY);
adc.setPGA(PGA_16);            // geophone output is millivolt-class
adc.setDRATE(DRATE_500SPS);    // plenty for a 10 Hz geophone

What can go wrong: mains hum swamps a high-gain geophone preamp on the bench, battery power and short twisted leads keep it quiet, and the geophone must sit vertical to read ground motion correctly. How I verified: side-by-side with the ADXL355 on the same spike, tapping the ground at a measured distance and comparing signal-to-noise between the two front ends.

A mesh detection does not trigger anything automatic, it lands in the alert queue of the common operating picture and waits for a human. I read the detection, and if it deserves eyes, I task the GPS-denied rover or the thermal SAR drone to go look; the asset's confirmation flows back onto the dashboard as a track update. The human tasks, the machine ferries.

HUMAN TASKING (OPERATOR CONSOLE)

mosquitto_pub -h localhost -t "perimeter/tasking" -m \
  '{"asset":"rover","action":"goto","node":2,"reason":"detection seq=1187"}'

What can go wrong: automation creep, the tasking topic only accepts publishes from the operator console, never from the mesh or the gateway service, so no sensor output can task an asset by itself, ever. How I verified: attempted to publish a tasking message from the gateway's service account and confirmed it is rejected.