Field WardenSign inOrder a demo unit

Know what your equipment is doing

Pulse reads your field continuously, shows it honestly, and calls the right person when something goes wrong. It sits on the tree you built in Atlas, so there is nothing to set up twice.

Trends that are actually fast

Zoom, pan, and put several pens on one axis without waiting for a page to rebuild. This matters more than it sounds: the difference between a chart that responds instantly and one that takes four seconds is the difference between exploring a problem and giving up on it.

A live chart running on real data will sit here. It is not here yet, because the honest version of this page does not fake the one thing it is claiming to be good at. Until then, the fastest way to judge it is a device on your own equipment.

Data displayed honestly

Most monitoring software interpolates across an outage without telling you, so a backhaul failure looks like a steady reading. That is the single most misleading thing a trend can do, and it is a choice the software made rather than a limitation. These are commitments about what Pulse will not do.

A gap is drawn as a gap

When a device is offline, the trend stops. It does not draw a straight line between the last value before the outage and the first one after it, because that line is a measurement nobody took.

Quality flags stay visible

A value that arrived late, was clamped at the top of a sensor range, or came from a device reporting a fault is marked as such wherever it appears, including on a report you export.

Smoothing is off, and labelled when on

Nothing is averaged or filtered by default. If you turn smoothing on the chart says so, because a smoothed trend that looks like raw data hides exactly the spikes you are watching for.

Stored values are never edited

A correction is recorded alongside the original rather than replacing it, so the number you acted on in March is still the number you can see in June.

Alarms that reach a person

An alarm nobody sees is not an alarm. Rosters and escalation are platform features rather than monitoring features, so the chain you build here is the one every future module uses when it needs somebody at 3am.

  1. The alarm raises against the node in your tree, so it arrives naming the well rather than a channel id.
  2. The person on call for that branch is notified. Who that is comes from the roster on the tree.
  3. If nobody acknowledges within the time you set, it escalates to the next person on the roster.
  4. If nobody acknowledges at all, it escalates again, and it keeps a record of every step.
  5. An acknowledgement is attributed and timed, so who took it and when is not a matter of memory.

Alarms are evaluated at the device as well as in the cloud, so a threshold is crossed and acted on even while the backhaul is down.

Control, with the safety taken seriously

Writing a setpoint from a phone is genuinely useful and genuinely dangerous, so it is bounded at both ends. Every writable setpoint has a minimum and a maximum you configure, and a value outside that range is refused rather than warned about. A fat-fingered extra zero cannot leave the interface.

Writing is a named privilege separate from viewing and separate from acknowledging alarms, so somebody can be trusted to answer a callout at 3am without also being able to change how the equipment runs.

Every write is recorded with who made it, when, the previous value and the new one.

Put one on something you own

A demo unit on real equipment answers more in a week than any page can.