The Alfa HazardX field node is a sealed field unit on a fabricated board, carrying gas, flame, climate, motion, sound and camera sensing on one embedded controller. It streams a full channel set every ten seconds, drops to a 1 Hz forensic recording for five minutes when the platform opens an incident, and runs a six-stop directional sweep to work out which way a hazard is coming from. Two generations exist: a v1 reference build, and the v2 field node described here.
Alfa HazardX is a deployable V2 field node. It is not a certified industrial safety product, and nothing on this page should be read as a certification claim.
The node's hardware block diagram. Every sensing element and every output maps to a specific GPIO, and on the v2 board that pin map is generated from the PCB netlist rather than maintained by hand.
Two generations, deliberately kept apart
The v1 reference build is the simplest thing that works: one controller, four gas channels, ambient temperature, flame, vibration and sound, assembled on a bench. It is a teaching build and a proving build, and it is where the method was first shown to hold.
The v2 field node is a fabricated board in a sealed housing, and its sensing set is materially wider: combustible gas, carbon monoxide and air quality reporting in ppm; air temperature, humidity and barometric pressure; a contact probe for surface temperature, independent of the air around it; three-axis vibration; sound level; a camera; and a display that makes the node readable without a laptop. Eleven measurement channels in total.
The platform now runs the v2 field node only. The v1 build has been retired from it: every reading is stored as a sensor vector - one record carrying the full channel set - rather than in a fixed column per sensor, so a channel added to the board does not need a schema change to reach the dashboard.
The pin map comes from the netlist
On the v2 board the firmware's pin map is generated from the PCB netlist rather than transcribed from it, and the bill of materials matches the same source. This sounds like housekeeping and is not: a hand-maintained pin map is the single most reliable way to produce a board that is correct, firmware that is correct, and a system that does not work.
The practical rule that falls out of it is blunt - do not change pins without changing the board.
Two speeds: NORMAL and BURST
The control loop. Local evaluation and alarm complete before the publish step, so neither a slow network nor a burst directive can delay a local alarm.
In NORMAL mode the node posts its full channel set every ten seconds. That is frequent enough to watch a process and slow enough to be affordable in bandwidth and storage over months of continuous operation.
When the server recognises a hazard signature or classifies risk as HIGH, it opens an incident and replies to the node with a burst directive. The node then streams at 1 Hz for five minutes, and every frame is stored as a forensic replay frame. After five minutes it returns to ten-second reporting on its own.
This is the black box, and the reasoning behind it is the same as an aircraft's. Detail is expensive to store continuously and invaluable for the ninety seconds around an event. Rather than choose one resolution and live with the compromise, the node changes resolution when something is happening - and the trigger for that change is the cloud's judgement, not the node's, so the decision is made where the full signature library lives.
The adaptive scanner, and why it waits
A fixed sensor tells you a hazard exists. It does not tell you where it is coming from. The adaptive scanner addresses that: on request from the server, the node runs a six-stop, sixty-degree sweep, sampling every sensor at each stop and posting the samples with a bearing, so concentration can be compared across sectors.
The rotation itself is done by a second, separate controller that drives the enclosure's stepper motor. The sensing node does not command that motor directly - it queues the move through the server, and then waits until the base motor acknowledges the move as done before it samples.
That closed loop is the detail worth pausing on. The obvious implementation is to command a move, wait a fixed delay, then sample. It works right up until the motor stalls, slips or runs slow. From then on every sample is attributed to the wrong bearing, and the direction estimate is confidently wrong. Waiting for an acknowledgement costs a little latency and removes an entire class of silent error.
The camera holds no keys
The camera captures a JPEG and uploads it through the application server, which puts it in the snapshot bucket. The node holds no storage credentials of its own.
That is a security decision rather than a convenience one. A field device sitting on a factory floor is physically accessible to anyone in the building, and a device that holds object-storage keys is a device that hands those keys to whoever removes it from the wall. Routing uploads through the server means a stolen node yields nothing beyond its own ingest credentials, which can be revoked per device.
What the operator sees on the node itself
The display cycles six screens, driven by the onboard BOOT button and a slow auto-rotate - there is no touch on this board. The six screens. A dashboard of sensor cards with an alert badge. The Hazard-DNA genome, showing local risk and the matched signature. The adaptive scanner's radar view, with concentration and bearing per sector. The black-box state, with incident id and the five-minute countdown. The camera preview and upload state. And a node status screen carrying Wi-Fi and IP, identifiers, mode, per-sensor health and free heap.
The last of those is the one that gets used most in practice. A field engineer standing in front of a misbehaving node wants per-sensor health and a heap figure, and wants them without a laptop.
The awkward details
The flame channel reads inverted - a brighter flame pulls the value down - so every threshold check for it is inverted to match, on the node and on the server. It is the kind of detail that is obvious once and invisible forever after, and it is written down for that reason.
The gas channels need a burn-in period of a day or two before they read stably, and the node learns its own baseline at power-on on the assumption that the surrounding air is clean. Power a node up in a room that is already contaminated and it will treat that contamination as its zero. This is a real operational constraint, not a footnote, and it is why commissioning has a procedure rather than a switch.
The vibration input is latched in firmware for a full second, because a knock shorter than the sample interval would otherwise fall between two samples and never be seen at all.
Board bring-up has its own constraints, documented for whoever services a unit rather than published here - the sort of thing that belongs in a service manual and not on a marketing site.
