A walkthrough of what happens when you power a Tick device on, how data finds its way to your dashboard, and why an outage doesn’t cost you readings.
About thirty seconds, start to finish. Most of that is the cellular network handshake.
No router config. No SIM activation paperwork. No enrollment portal. The device’s identity is derived from its hardware, so reflashing or factory-resetting doesn’t break anything — the same device shows up with the same identity, every time.
A naïve sensor either samples too rarely (and misses short events) or floods the backend with raw readings. Tick does neither.
Tick samples your equipment as often as the use case demands — once a minute, every thirty seconds, whatever’s right. Each sample is folded into a rolling window. On a separate cadence, Tick reports a compact summary of that window: minimum, maximum, average, and most-recent value, with timestamps for the first and last reading.
That means a thirty-second freezer spike inside a thirty-minute reporting window still shows up as the maximum. You catch the event without paying for thousands of redundant data points.
The accumulator survives outages. If the device’s power blips, the modem reboots, or a network goes down for two days — sensing keeps going, the window keeps building, and the next successful report carries the full picture. The only thing an outage costs is the moment the data lands, not the data itself.
When the network is down longer than the sensor window, Tick writes unsent readings to a dedicated flash partition. Reboots, power cycles, and multi-day outages don’t cost you the data — the device drains the backlog as soon as it’s reachable again.
A dedicated 64 KB flash partition (not RAM) holds up to 3,840 reading records in an append-only ring. That’s roughly 64 hours of one-minute records or 26 days of ten-minute records waiting on the device with the power off.
The queue is committed to flash, not RAM, with CRC-16 on every slot and a header sector that tracks head and tail. A watchdog reboot mid-flight doesn’t lose records. A dirty boot replays the header; an invalid header wipes cleanly with no half-state.
When the device gets back online, the send loop empties the RAM queue first, then drains the on-flash queue oldest-first. Each replayed record arrives as an OP_READING_PUSH event with its original capture timestamp, so dashboards backfill in chronological order.
Both transports run continuously. Either one can carry traffic. The device picks the right transport for each send, and recovers from outages on its own.
If a send fails on WiFi, the next one tries cellular. Per-send, not per-session. A five-second hotspot stutter doesn’t cost you a reading.
WiFi failing? The device reconnects every 10 minutes. Cellular failing? Modem reboots every 30 minutes. Both failing? Full recovery cycle every hour. No operator action needed.
Bad config or wrong auth key? The device rejects the change or auto-reverts after a few failed attempts. You can’t accidentally strand a device in the field.
Every reading comes with the metadata you need to debug a deployment from your desk.
Every reading shows whether WiFi or cellular delivered it. You can see at a glance which transport is doing the work, and which one’s been quiet.
Network round-trip from device send-start to backend receive, recorded on every reading. Spot a slow site without leaving your dashboard.
Uptime, free memory, signal strength. Catch a memory leak that takes weeks to surface, or a cell tower whose RSSI dropped after a roof was rebuilt.
When something needs a closer look, queue a command from the dashboard. The device runs it on its next check-in and returns the result — everything you’d type at the bench, only it’s a unit on a tower across town.
Pick the device, type a command, hit send. Inspect state, dump the on-device error log, toggle WiFi, change the chkin cadence, kick the modem, target a firmware image. The device executes, returns output as an event, and the operator UI renders it inline. Every queued command and every result is signed with the operator’s identity and saved to audit.
Firmware over the air, over either transport. Per-device targeting, chunked download with compression and SHA verification, resume on crash, progress visible end-to-end.
Pick a firmware image, target it at one device or many. The portal serves the directive on the device’s next check-in, the device downloads and verifies, the outcome lands as an event. Different devices can run different images at once.
The same OTA pipeline runs over WiFi or cellular. The device picks automatically, or an operator can pin a specific transport with ota go wifi / ota go cell. WiFi-first if available; cellular as a fallback or first-class option for sites with no LAN.
Operator queues a target from the dashboard and the device pulls on its next chkin — or the device pulls on its own from the serial console with ota check / ota go. Either way it’s the same directive, same verification, same audit trail.
Images are compressed and shipped in chunks small enough to survive cellular. SHA over the inflated image; mismatched bytes never flash. Crashes mid-flash resume from the last good chunk on reboot.
The portal emits sampled progress events as chunks land — “OTA 14 / 32” renders right in the per-device panel. No more wondering if the device picked up the new build.
OTAs can be paused mid-flight and resumed later from the last good chunk. A bad image never half-flashes — SHA verification gates the swap. If the new image won’t boot, the bootloader rolls back to the previous slot on its own.
Every Tick maintains a structured error log in flash — 64KB partition, 1024 indexed entries, breadcrumb in every check-in. When something goes wrong on a unit you can’t physically reach, you find out without rolling a truck.
The breadcrumb rides with every check-in: most-recent error sequence, source, severity, code, timestamp. The portal renders it as a colored chip on the device row — green for clean, yellow for warnings, red when something tripped. Drill in, queue errlog show, and the full entry comes back as an event with the kv context the device captured when the error fired.
Modem failures, PDP attach errors, NVS write faults, watchdog resets, OTA verification mismatches — all instrumented. The error log survives reboot and reflash (it’s a dedicated partition, not RAM).