Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 5 additions & 13 deletions 60-lone-worker-panic-fall-detection-beacon/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,27 +8,27 @@ This reference application is intended to provide inspiration and help you get s

</Note>

This project is a wearable [safety assurance](https://blues.com/safety-assurance/) device for utility linemen, oilfield pumpers, field service technicians, and solo contractors. A single [Notecard for Skylo](https://shop.blues.com/products/notecard-for-skylo?utm_source=dev-blues&utm_medium=web&utm_campaign=store-link) — one M.2 module that carries cellular, WiFi, and Skylo satellite radios and fails over between them automatically turns a belt-clip enclosure into a cellular-first, satellite-backed distress beacon — detecting falls and accepting an explicit panic-button press — that can reach a dispatcher from the middle of nowhere, exactly where lone-worker incidents happen.
This project is a wearable [safety assurance](https://blues.com/safety-assurance/) device for utility linemen, oilfield pumpers, field service technicians, and solo contractors. A single [Notecard for Skylo](https://shop.blues.com/products/notecard-for-skylo?utm_source=dev-blues&utm_medium=web&utm_campaign=store-link) carries cellular, WiFi, and Skylo NTN satellite radios on one module and fails over between them automatically. It turns a belt-clip enclosure into a cellular-first, satellite-backed distress beacon — detecting falls and accepting an explicit panic-button press — that can reach a dispatcher from the middle of nowhere, exactly where lone-worker incidents happen.

## 1. Project Overview

<Warning>

**Not a certified life-safety device.** This is a proof-of-concept reference design intended to demonstrate Blues hardware and firmware patterns. It is not a certified personal emergency response system (PERS), not a classified man-down or lone-worker protection device under any regulatory scheme, and has not been evaluated for fail-safe or safety-critical operation. It must **supplement, not replace** — established lone-worker safety procedures, mandatory check-in protocols, required PPE, and any regulatory or contractual safety obligations that apply to your operation. Never deploy this design as a sole means of worker protection.
**Not a certified life-safety device.** This is a proof-of-concept reference design intended to demonstrate Blues hardware and firmware patterns. It is not a certified personal emergency response system, not a classified man-down or lone-worker protection device under any regulatory scheme, and has not been evaluated for fail-safe or safety-critical operation. It must **supplement, not replace** — established lone-worker safety procedures, mandatory check-in protocols, required PPE, and any regulatory or contractual safety obligations that apply to your operation. Never deploy this design as a sole means of worker protection.

</Warning>

**The problem.** A utility lineman working an isolated substation, an oilfield pumper checking a remote wellhead at night, a field-service tech in a basement boiler room at 2 AM — each of these workers shares a common vulnerability: if something goes wrong, nobody will know for hours. Lone-worker incidents don't always announce themselves. Falls from elevation are silent. Heart events are silent. The worker simply stops moving, and no one notices until a shift check-in is missed or a buddy does a welfare call.

The gap isn't awareness — most safety-conscious operations already require check-in procedures. The gap is *automatic, continuous* monitoring that doesn't depend on the worker remembering to push a button every 30 minutes. What these workers need is a device that monitors for the physical signatures of an incident — sudden free-fall, violent deceleration on impact, prolonged motionlessness after a fall, and raises an alarm without any action on the part of the worker. The panic button is a secondary escape valve: an explicit human override for situations where the physics don't look like a fall but the worker knows something is very wrong.

This project is that device — a wearable safety beacon built on two core detection modes: automatic fall detection and explicit panic-button input. The onboard Cygnet STM32L433 host runs a two-stage fall-detection algorithm on the LIS3DH accelerometer sampled at ~100 Hz (a 10-sample inner loop runs at 10 milliseconds intervals so free-fall phases as short as 80 milliseconds are always observed; Notecard I/O and state checks run at the outer ~10 Hz cadence; see [Section 6](#7-firmware-design) for the sampling design), monitors a held-down panic button with debounce logic, and drives a haptic motor to acknowledge every confirmed event. On fall or panic, the firmware immediately queues a compact emergency Note carrying the Notecard's cached location and transmits it with `sync:true` — no GPS wait before the alert goes out. A non-blocking background GPS search then runs without suspending fall or button monitoring; if a fresh fix arrives within the timeout window, a follow-up `beacon_location.qo` Note is queued with the event-time coordinates. See [Section 6](#7-firmware-design) for the full two-Note flow.
This project is that device — a wearable safety beacon built on two core detection modes: automatic fall detection and explicit panic-button input. The onboard Cygnet STM32L433 host runs a two-stage fall-detection algorithm on the LIS3DH accelerometer, monitors a held-down panic button with debounce logic, and drives a haptic motor to acknowledge every confirmed event. The accelerometer is sampled at ~100 Hz: a 10-sample inner loop runs at 10-millisecond intervals so free-fall phases as short as 80 milliseconds are always observed, while Notecard I/O and state checks run at the outer ~10 Hz cadence (see [Section 7](#7-firmware-design) for the sampling design). On fall or panic, the firmware immediately queues a compact emergency Note carrying the Notecard's cached location and transmits it with `sync:true` — no GPS wait before the alert goes out. A non-blocking background GPS search then runs without suspending fall or button monitoring; if a fresh fix arrives within the timeout window, a follow-up `beacon_location.qo` Note is queued with the event-time coordinates. See [Section 7](#7-firmware-design) for the full two-Note flow.

**Why Notecard.** Cellular coverage is not a given for the environments where lone-worker incidents happen. A substation at the edge of a service area, a gas compressor station in a rural county, a mine portal — these are precisely the places where a worker is most isolated *and* where cellular signal is most likely to be marginal or absent. Relying on cellular alone creates the dangerous assumption that signal is available when it's needed most.

<NewToBlues/>

That's the reason [Notecard for Skylo](https://shop.blues.com/products/notecard-for-skylo?utm_source=dev-blues&utm_medium=web&utm_campaign=store-link) (NOTE-NBGLWX) is the foundation of this design, not as a nice-to-have, but as the architectural foundation. It carries three radios on one M.2 module — cellular (LTE-M / NB-IoT / GPRS), WiFi, and satellite over the [Skylo](https://www.skylo.tech/) non-terrestrial network (NTN) — and selects among them automatically. The cellular path covers the vast majority of activations — cellular is broadly deployed, even in surprisingly rural areas. But when cellular genuinely fails, the Skylo satellite link is there, on the same board: no companion module, no second device to wire in. Skylo covers supported regions (see the [Notecard for Skylo datasheet](https://dev.blues.io/datasheets/notecard-datasheet/note-nbglwx/) for the current coverage footprint); within that footprint, a device with an unobstructed view of the sky can deliver a distress message to the [Blues Notehub](https://blues.com/notehub/) cloud service even when every terrestrial network is unavailable. Satellite coverage is not guaranteed in every no-cellular location — it depends on the Skylo coverage region, sky-view geometry, and antenna orientation, but for the substations, oilfields, and rural worksites this design targets, it provides the safety margin that cellular alone cannot.
That's why [Notecard for Skylo](https://shop.blues.com/products/notecard-for-skylo?utm_source=dev-blues&utm_medium=web&utm_campaign=store-link) (NOTE-NBGLWX) is the architectural foundation of this design, not a nice-to-have bolted on afterward. It carries three radios on one M.2 module — cellular (LTE-M / NB-IoT / GPRS), WiFi, and satellite over the [Skylo](https://www.skylo.tech/) non-terrestrial network (NTN) — and selects among them automatically. The cellular path covers the vast majority of activations — cellular is broadly deployed, even in surprisingly rural areas. But when cellular genuinely fails, the Skylo satellite link is there, on the same board: no companion module, no second device to wire in. Skylo covers supported regions (see the [Notecard for Skylo datasheet](https://dev.blues.io/datasheets/notecard-datasheet/note-nbglwx/) for the current coverage footprint); within that footprint, a device with an unobstructed view of the sky can deliver a distress message to the [Blues Notehub](https://blues.com/notehub/) cloud service even when every terrestrial network is unavailable. Satellite coverage is not guaranteed in every no-cellular location; it depends on the Skylo coverage region, sky-view geometry, and antenna orientation. But for the substations, oilfields, and rural worksites this design targets, it provides the safety margin that cellular alone cannot.

The firmware sets a single [`card.transport`](https://dev.blues.io/api-reference/notecard-api/card-requests/#card-transport) preference of `wifi-cell-ntn`: the Notecard prefers WiFi where a provisioned AP is reachable, falls back to cellular (the de-facto primary for a roaming worker), and falls back again to Skylo satellite when every terrestrial network is unavailable. Failover happens inside the Notecard; the host firmware never branches on which network is live. The WiFi path is an opportunistic bonus — a field tech standing near a facility WiFi AP may sync an alert without any cellular usage at all — but it is only active when network credentials have been provisioned on the Notecard and a compatible AP is within range.

Expand All @@ -52,7 +52,7 @@ When the worker walks into a coverage hole and cellular fails, Notecard for Skyl

**What you'll have when you're done:** a wearable beacon that detects falls and panic-button presses, transmits alerts to Notehub over cellular or satellite, and provides haptic feedback on every event.

**Prerequisites:** Arduino IDE or `arduino-cli`, a Notehub account, and a Notecarrier CX fully assembled per the wiring in [Section 4](#5-wiring-and-assembly).
**Prerequisites:** Arduino IDE or `arduino-cli`, a Notehub account, and a Notecarrier CX fully assembled per the wiring in [Section 5](#5-wiring-and-assembly).

**Step 1: Install dependencies**

Expand Down Expand Up @@ -139,10 +139,6 @@ Notecard for Skylo ships with an active global SIM including 500 MB of cellular

**Installer-supplied, deployment-specific item.** Belt clip or wearable mounting hardware — attaches the beacon to a worker's belt, hard-hat band, or safety vest. Select a clip rated for the enclosure weight (~300 g fully loaded). Some enclosure families include an optional clip-arm accessory; a spring-steel belt clip can be mounted to the enclosure exterior with M3 screws.

</Note>

<Note>

**Charging and power access.** No LiPo charging circuit, dock, or power-switch hardware is included in this BOM or wiring. The project runs on a bare LiPo cell until depleted. A production wearable needs a USB-C LiPo charging circuit integrated into the enclosure, plus overcharge and short-circuit protection if not already provided by the cell's built-in circuitry. See [Section 9](#11-limitations-and-next-steps) for details; adding a charging path is the expected next step for anyone moving from bench validation toward a field-deployed unit.

</Note>
Expand Down Expand Up @@ -175,10 +171,6 @@ Pin-by-pin:

**Antenna placement and connector mapping.** Notecard for Skylo uses two u.FL ports. Connect the included Skylo-certified antenna to the `MAIN` port — it carries **both** the cellular signal and the Skylo satellite link, so a single antenna serves both networks — and connect the passive GPS/GNSS antenna to the `GPS` port. Adhere both elements to the top (sky-facing) interior wall of the polycarbonate enclosure: polycarbonate is RF-transparent, so no external pigtail routing or bulkhead is needed. A belt-worn beacon only reaches the Skylo satellite network when its `MAIN` antenna can see the sky, so orient that wall upward when the unit is worn; in the northern hemisphere a southward orientation improves Skylo link margin. Use only the Skylo-certified antenna supplied with Notecard for Skylo on the `MAIN` port — substituting an uncertified antenna risks regulatory non-compliance and link failure. The `GPS` port is the location source for all `card.location` data embedded in alert Notes.

</Note>

<Note>

**Charging is out of scope for this POC.** No charging circuit, dock, or inductive coil is wired in this build. Route the LiPo JST connector to an accessible point on the enclosure wall so the battery can be swapped or a bench charger connected without fully disassembling the unit. Do not seal the JST connector inside the enclosure with no external access path.

</Note>
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ This reference application is intended to provide inspiration and help you get s

</Note>

This project is a [safety assurance](https://blues.com/safety-assurance/) reference design that gives pharmacies, clinical laboratories, and vaccine depots a continuous, automatically-timestamped temperature record for every refrigerator and freezer in their compliance scopedelivered over a cellular data path that bypasses the facility's regulated network entirely, with immediate alerts when the temperature strays outside its configured range or a door is left open too long.
This project is a [safety assurance](https://blues.com/safety-assurance/) reference design that gives pharmacies, clinical laboratories, and vaccine depots a continuous, automatically-timestamped temperature record for every refrigerator and freezer in their compliance scope, delivered over a cellular data path that bypasses the facility's regulated network entirely. Immediate alerts fire the moment the temperature strays outside its configured range or a door is left open too long.

## 1. Project Overview

Expand All @@ -26,7 +26,7 @@ That independence also matters for continuity. Facility WiFi goes down for maint

WiFi fallback on the MBGLW is available as a secondary path, but only for sites that provide an explicitly approved, segregated IoT network for the device. Using the facility's primary pharmacy or clinical LAN defeats the network-independence rationale of this design, and a compliance monitor sitting behind a firewall exception is one network policy change away from silent failure.

**Deployment scenario.** A small weatherproof enclosure mounts on the **exterior** of the cold storage unit, never inside the refrigerated compartment (sustained cold and condensation will damage unprotected electronics, and a metal refrigerator body will block cellular signal). The Adafruit MAX31865 amplifier board mounts inside the enclosure; the Adafruit PT1000 probe cable exits through a cable gland and routes into the compartment through the cabinet's manufacturer-provided probe port or door-gasket pass-through (see [§5 Wiring and Assembly](#5-wiring-and-assembly)), placing the stainless-steel probe capsule at the geometric center of the storage volume. The VEML7700 light sensor mounts at the exterior of the door frame, not inside the cold zone — where it detects light spillage when the door is ajar; see [Limitations](#11-limitations-and-next-steps) for condensation-tolerant production placement options. Door switch halves mount on the door and frame. The Notecarrier CX sits in the enclosure, USB-C powered from a wall adapter. The cellular antenna mounts on the exterior of the enclosure where it has line of sight to the network. No network configuration, no IT ticket, no manual download. **For bench development** without a probe routed into a cabinet, a TMP117 breakout (bench library-swap required) mounted inside the enclosure measures exterior ambient air and lets you validate the firmware architecture and cellular data path.
**Deployment scenario.** A small weatherproof enclosure mounts on the **exterior** of the cold storage unit, never inside the refrigerated compartment (sustained cold and condensation will damage unprotected electronics, and a metal refrigerator body will block cellular signal). The Adafruit MAX31865 amplifier board mounts inside the enclosure; the Adafruit PT1000 probe cable exits through a cable gland and routes into the compartment through the cabinet's manufacturer-provided probe port or door-gasket pass-through (see [§5 Wiring and Assembly](#5-wiring-and-assembly)), placing the stainless-steel probe capsule at the geometric center of the storage volume. The VEML7700 light sensor mounts on the exterior of the door frame — not inside the cold zone — where it detects light spillage when the door is ajar. See [Limitations](#11-limitations-and-next-steps) for condensation-tolerant production placement options. Door switch halves mount on the door and frame. The Notecarrier CX sits in the enclosure, USB-C powered from a wall adapter. The cellular antenna mounts on the exterior of the enclosure where it has line of sight to the network. No network configuration, no IT ticket, no manual download. **For bench development** without a probe routed into a cabinet, a TMP117 breakout (bench library-swap required) mounted inside the enclosure measures exterior ambient air and lets you validate the firmware architecture and cellular data path.

## 2. System Architecture

Expand Down Expand Up @@ -478,7 +478,6 @@ See the [MBGLW datasheet](https://dev.blues.io/datasheets/notecard-datasheet/not
- Verify the Notecard is entering sleep mode. On a +VBAT bench setup (no USB-C), the baseline current should be single-digit µA between samples. If the baseline is persistently > 1 mA, the ATTN pin wiring may be incorrect, or the `NotePayloadSaveAndSleep` call may not be executing. Check the ATTN pin connection from the Notecard to the Notecarrier CX enable gate.
- On a USB-C powered deployment, the Notecard's idle current is higher than the µA bench figures (see [§9 Power validation](#9-validation-and-testing)). This is expected.


## 11. Limitations and Next Steps

This reference design produces the measurement record and the cellular data path an auditor cares about, but several of the surrounding pieces of a regulated cold-chain program are explicitly out of scope — the calibration certificate that goes with each probe, the SOPs that govern the program, the multi-point mapping that a large freezer needs, and the ultra-cold (−80°C) hardware path. The list below names those boundaries so anyone evaluating this design against a real compliance program can see exactly what they still need to bring.
Expand Down
Loading
Loading