Chinese
Spanish
Russian
Portuguese
French
German
Indonesian
Thai
Vietnamese
Arabic
Italian
Turkish
Polish
Japanese
When telemetry returns after an outage, an RTU may transmit older buffered samples together with a new reading. Water level RTU data recovery must preserve their original order and meaning. Otherwise the platform can show a historic flood peak as current, duplicate observations or conceal a period when nothing was measured.
Separate measurement loss from transmission loss
Determine whether the sensor and logger continued operating while the link was unavailable. A functioning local buffer may preserve valid observations during a communications outage. A power failure can instead leave a genuine measurement gap. The reporting system should not describe these two events as equivalent.
For each recovered record, retain acquisition time and quality where supported, separately from upload time. If the clock was uncertain, retain that limitation rather than silently assigning the reconnection time to every sample. Choose a consistent time-zone convention for storage and display.
| Recovered item | Platform treatment to define |
|---|---|
| Buffered sample | Store it at its original acquisition time and distinguish it from a current observation. |
| Repeated upload | Recognise the same record without counting it as another measurement. |
| Unknown time | Retain a quality indication instead of fabricating an exact sampling time. |
| Missing interval | Show the gap or clearly labelled authorised estimate, not an invented measured series. |
Specify water level RTU data recovery before selecting storage
Agree how much outage history must be retained at the chosen sampling interval. Ask the RTU supplier how records survive power loss, what happens when storage fills and how acknowledgements and retransmission work. Do not assume a cellular modem itself provides durable measurement storage.
The METRAVON MV-RD12T can supply an appropriately configured analogue or RS485 water-level signal. Its product description does not establish an internal historical archive or a telemetry replay service. Allocate buffering, record identity and upload handling explicitly to the selected RTU or data logger.
Test replay without confusing live alarm handling
Use a controlled communications test with known sample times, then compare the retained local records with the platform. Check order, duplicates, omitted records and any restart-related sequence reset. Use the system's documented record identifiers rather than assuming that a timestamp alone always identifies a unique sample.
Define how historical threshold crossings are reported. A recovered old high-water sample may deserve an event record, but it should not silently replace the live value used for current operating decisions. Any local control or protective function needs its own availability design during telemetry loss.
Q1. Can the latest received packet always update the live display?
No. Reception order can differ from acquisition order during replay. The platform must identify the latest valid observation rather than the last packet received.
Q2. Does a complete-looking trend prove no data were lost?
No. Interpolation or repeated values can hide gaps. Inspect original records and quality information as well as the plotted line.
Summary
Recover history without presenting it as current measurement. Provide the MV-RD12T interface, logging interval and RTU recovery requirements to define the sensor-to-platform responsibilities.
