Dragino PS-LB-NA Pulse Counts: Verify Restart Persistence and Reporting Mode
After a remote node restarts, a lower pulse value can be mistaken for negative consumption, a quiet production line or a failed meter. The answer is to define what each reported number means before maintenance: an accumulated count, an interval count or a new baseline after an event. Preserve the change record and test the receiving calculation as well as the device.
This guide concerns the Dragino PS-LB-NA documentation, not every Dragino pulse product. It proposes an acceptance record and a controlled test for a competent integrator. Confirm the exact hardware, firmware and input specification before connecting a pulse source or changing a deployed configuration.
Separate counting mode from restart persistence
Dragino documents COUNTMOD from firmware v1.2.1: mode 0 accumulates pulses, while mode 1 clears the count each TDC period. Its CNTSAVE feature, documented from v1.2.6, separately controls reading a saved count after reset; the documented default is disabled. A periodic count reset and restart persistence are therefore different settings. Verify both on the installed unit.
The ProSense catalogue photograph shows the analogue-interface product family. It is not evidence that an arbitrary terminal accepts a customer's pulse signal. Check the PS-LB-NA manual and the supplied configuration for the specific counting input, electrical limits and wiring. Do not connect a powered industrial output to an unverified input.
Write down the receiving calculation
Ask the platform owner which field is used and how it becomes consumption or production. For an accumulated count, a simple difference between consecutive readings can be useful only while those readings share a valid baseline. For an interval count, the value belongs to its reporting interval. Subtracting one interval value from the next answers a different question.
Record the pulse factor with its direction and units. 'Ten' is insufficient: ten pulses per litre differs from ten litres per pulse. Keep this engineering conversion separate from the raw device count, and retain raw observations during testing. If the integration already applies a factor, applying it again in a dashboard would change the result.
Use a small, controlled acceptance test
Arrange a test window with the process owner. Use an isolated test arrangement or an approved way to observe known events without operating equipment unexpectedly. Record the device identity, firmware, counting mode, persistence setting, reporting interval, raw count, platform value and time before starting. Protect network keys and credentials in all shared records.
Introduce a known, independently counted number of valid events at an input rate and waveform permitted by the exact manual. Compare the expected change with the raw report and with the final engineering value. Passing a hand-operated contact test does not prove performance at the fastest real process rate; that requires its own suitable test method.
With permission and a documented recovery plan, test the intended restart behaviour. Record the last observation before the restart and the first usable observation afterwards. Check the configuration again rather than assuming it survived. Do not use a factory reset as a substitute for the specific restart being assessed: it may change additional settings.
A hypothetical baseline discontinuity
Suppose a cumulative counter reports 12,000 pulses before maintenance and 15 pulses afterwards. At ten pulses per litre, blindly subtracting gives minus 1,198.5 litres. That is an invalid consumption result if maintenance created a new baseline; it is not evidence that water flowed backwards. Keep the old segment, mark the discontinuity and establish the new segment explicitly.
Conversely, if the configured mode reports interval counts, successive values of 80 and 95 represent their respective intervals. Their difference of 15 is not the second interval's consumption. In this hypothetical example, ten pulses per litre would make the two interval quantities eight and 9.5 litres, subject to the test assumptions.
Do not silently repair an unexplained decrease
The receiving system should flag an unexpected counter decrease for investigation. A restart, deliberate clear, configuration change, rollover, duplicate or out-of-order observation may need different handling. Do not add a guessed rollover modulus or replace every decrease with zero. Establish the model's documented behaviour and preserve enough evidence to explain the chosen interpretation.
Do not promise lossless accounting from the existence of a save setting. Test the specific maintenance event and required accuracy. Events during a recording gap need an independent basis if they matter to reporting. Historical-data features should not be assumed to recover missing pulse events unless that exact capability is documented and demonstrated.
Hand over the result and the limits
Record the tested firmware, observed settings, event counts, raw reports, conversion rule and restart outcome. State which conditions were not tested, such as an abrupt power interruption or prolonged communications outage. For help, send ProSense the exact model, redacted payload examples and the required reporting outcome. Have the integration owner approve how discontinuities are represented before relying on totals.
Manufacturer reference and pictured equipment
Need help with your application?
For instrument enquiries, visit ProSense Instruments, email sales@prosenseinstruments.com.au or call 1800 560 854. Include the exact model, application and operating conditions.
For complete monitoring and automation projects, visit ProSense Solutions or email sales@prosense.com.au.
For software enquiries, visit ProSight Software or email info@prosightsoftware.com. Device and protocol integration must be confirmed for your application.
Comments