Installation & Maintenance FAQ

Directly in front of the instrument face, with the dial filling as much of the frame as the 10× zoom allows, and with the camera body rigidly fixed. Vibration is the most common cause of a reading that drifts over time — a bracket that moves by a few millimetres can move the dial out of the recognition region. Mount to structure, not to the instrument itself, where the instrument can be disturbed during maintenance. (For what this approach does and does not suit, see reading pointer and analog gauges remotely.)

Even, indirect light on the dial face. Avoid direct sunlight that changes angle across the day (it can wash out a pointer), and avoid a light source that reflects off a glass cover. If the site has no fixed lighting, tell us at scoping — mounting position and any local illumination are decided together.

The enclosure is rated IP66 with an operating range of −40 °C to +70 °C, which covers outdoor cabinets and unconditioned plant rooms. The rating applies to the enclosure, not to your cable entries — glands and conduit must be sealed to the same standard or water will enter through them.

Reading camera: DC 10–16 V, < 1.5 A, < 18 W (at 25 °C, 12 VDC). Edge computing box: DC 10–28 V, < 1.5 A, < 18 W. Use a supply sized for the lowest temperature on site, and keep the run short or use a locally regulated supply if the drop is significant.

The devices are powered from a DC supply over a separate feed. Plan a power drop to each mounting position alongside the communication path.

RS485, up to 1000 m of run, with 300 W surge protection on the device. Use twisted pair, daisy-chain (not star), and terminate at the physical ends of the bus. In an electrical environment, run the bus away from power cabling and bond the shield at one end only. (For why this bus is used and how the protocol relates to it, see Modbus RTU.)

Modbus RTU, 4800 bps, even parity, over RS485. The device also provides a 100 Mbps Ethernet interface if you prefer to poll over the network.

Each device is a Modbus RTU slave. Assign unique slave addresses before putting more than one on a bus. Two devices with the same address on one segment is the single most common commissioning fault — the symptom is intermittent or nonsensical readings rather than a clean failure, so set addresses deliberately and record them.

• Every device responds at its assigned address, at the correct baud and parity
• The value read matches the physical instrument when read by eye
• The reading is stable over a period that includes a change in ambient light
• Cable entries are sealed to the enclosure rating
• Addresses, mounting positions and meter identities are recorded in your asset list

Accuracy depends on the instrument face, the viewing angle and the lighting. That is why we quote a chargeable sample unit before a rollout — verify recognition on your actual meters, at the actual mounting position, rather than accepting a figure from a datasheet. Compare the device reading against the physical indication across a range of values, not just at one point.

Yes for the reading camera — the recognition library can be upgraded on the device. For the edge computing box, confirm the detail with us. Agree with us how updates will be delivered and who applies them before you have hundreds of units deployed.

Very little in normal operation: check that the mounting has not moved and that the lens and dial are clean. A dusty or fly-specked cover is a realistic long-term cause of recognition degradation in industrial settings, so include the lens in whatever cleaning routine the area already has.

Which cables, sections and joints are to be covered, and how the fibre will be routed to reach them. Check the joints explicitly — a route that covers the cable body but skips the joints is monitoring the least interesting part, and it is an easy omission because the cable run is what people picture.

Someone has to establish which distance along the fibre corresponds to which cable, joint and section, using the as-built routing and the cable schedule. This is site engineering work, not a software setting, and it is routinely underestimated. Our system maps distance onto the asset hierarchy once that information exists; until then, it reports distances — which are still useful, just not yet named.

Name a person before installation. The mapping needs to be created, checked against the physical installation, and then maintained whenever cables are added or rerouted. An unowned mapping decays, and a decayed mapping produces alarms that name the wrong cable — which destroys trust faster than no mapping at all.

Yes. Basic temperature monitoring runs in full without any asset mapping. You can install, verify that profiles are arriving and that hotspots are being detected, and add the mapping as it is built. Deciding to wait for a perfect mapping before switching anything on usually means waiting a long time.

No. Basic temperature monitoring runs in full without load-current data. If current transformers are available, load-correlated assessment is enabled. Note the deliberate boundary: without current data the system will not assert overload or connection fault as a confirmed cause — it reports what it observed and what it cannot determine.

Confirm complete profiles are arriving on every configured channel, and compare a stable period against what the site looks like physically. A useful first commissioning record is a baseline capture: four channels, complete profiles, with the point spacing and temperature range noted. That record becomes the reference for later comparison.

It reports a distinct data-quality condition — never "no anomaly found". Loss of communication is identified within the design target of 15 seconds. The status must be visible, because the alternative (a quiet screen that looks identical to a healthy one) is the most dangerous failure mode in monitoring.

Off-box backup is required — a NAS or independent storage. A directory on the same machine is not accepted as the only backup. Retention is tiered: per-frame profiles for 7 days, minute-level profiles for 1 year, and assessment and alarm evidence for 3 years, with evidence bundles immutable.

Acquisition and platform access recover within 10 minutes of a Windows restart, without anyone logging in. This is a design target, and it is worth testing on site as part of commissioning rather than discovering it during an outage.

Not by the platform, but consider one for the host and the DTS device together. If the host recovers but the sensing device does not, you have an unmonitored cable with a system that is running — which is exactly the condition the data-quality state exists to make visible.

Yes, but the change should be deliberate and recorded. Formal policies are released under control and are immutable once released — an algorithm does not silently modify them. Agree in advance who has authority to change thresholds and alarm routing, and keep a record of what changed and why. Otherwise the first incident review will be unable to explain why the system behaved as it did.

• Which cables, rooms and sections are covered — and which are deliberately not
• The fibre routing and the distance-to-asset mapping, with its version
• Device addresses, mounting positions and meter identities (meter reading)
• The released alarm policy and who owns it
• Retention settings and the backup destination, with a tested restore
• The baseline capture from commissioning

Check, in this order: has the mounting moved; is the dial or lens obscured; has the ambient lighting changed; are two devices sharing a slave address; is the bus termination intact. In practice the first two explain most cases.

Check the fibre path and connectors, then whether the device itself is reporting on the other channels. If some channels are healthy and one is not, the problem is almost certainly in that channel's fibre or connection rather than in the monitoring platform. The system's own communication-loss detection tells you when it stopped, which usually points at what happened on site at that moment.

Not necessarily — it is the system refusing to guess. It means data, coverage, mapping or policy is insufficient to reach a conclusion, and the reason is stated with the verdict. Treat it as a work item: restore whatever is missing and the verdict will resolve. Treating it as a nuisance and lowering the bar is how a monitoring system becomes decorative.

Start with the alarm policy rather than the threshold. Check whether one physical hotspot is producing multiple alarms, whether acknowledging is being treated as resolving, and whether alarm routing matches who is actually on duty. Most alarm volume problems are policy problems, not sensitivity problems.