Pulse counting is available on the following DM devices:
"Optimised" Pulse Counting: Eagle, Falcon*, SensorData LoRaWAN, SensorNode LoRaWAN
Non-Optimised Pulse Counting: Dart2, G62, G120
*Only available on hardware revisions 74.3 and 74.4
TABLE OF CONTENTS
- TABLE OF CONTENTS
- Optimised Pulse Counting on the Eagle and Falcon (Cellular Devices)
- Rising Edge Counts
- Example Cellular Device Payload
- How do I count pulses from a rain gauge/flow meter on the Eagle or Falcon?
- Pulse Counting on the SensorData and SensorNode LoRaWAN®
- 'Optimised' Pulse Counting Power Draw
- "Non-Optimised" Pulse Counting on the Dart2, G62 and G120
Optimised Pulse Counting on the Eagle and Falcon (Cellular Devices)
The pulse count is designed for low power, and applications such as monitoring rain gauges. As such, pulses much faster than 1Hz, with very short pulse widths (<100ms), may not be able to be detected reliably. However using a shorter debounce time can allow for faster pulses to be counted. So keep this rough limit in mind, and test prior to deployment if you expect fast pulses.
Analogues 1 to 10 are 16 bit), so the count can range from -32,768 to +32,767
Analogues 11 to 20 (32 bit), they range from -2,147,483,648 to +2,147,483,647.
Resets and Count Overruns
Pulse counts are stored in flash memory, so should not be lost should power be lost. They may be reset during a firmware upgrade. If a user wishes to reset the pulse count, this must be handled on the server.
One way to handle resets occurring due to an overrun or FW update, would be to determine if the count goes down from a previous value, ignore any counts from the last value, but start again from the new one. for example, you get 4, 7, 10, 30, 10, 12, ignore the 30 -> 10 difference and start from 10. so it would be 30 + (10-12) = 32
if ( value[n] < value[n-1] )
newValue = value[n-1] + value[n + 1] - value[n];
To set up a Digital input to measure pulses on input 1, you can follow the below parameters
- Set to Digital Input. There is a "Rain Gauge" option, but in general this should not be used (even for rain gauges, confusingly) - see why below
- Logging and Uploads
- In general, Logging and uploads should be disabled to save data on higher frequency pulse sources and accurate timestamps are not required. Heartbeats (see 'Basic Tracking') can be used to periodically upload counts every X minutes/hours.
- Active Level
- The active level will depend on how your application applies to pulse counting. For more information on Active levels, See our article here
- Bias Resistor
- See our Article here
- Debounce Time
- This field is used to determine your debounce time (time input needs to be stable for the pulse to be registered). This is useful for filtering noisy inputs, but also has a direct relation to the shortest pulse widths/highest pulse frequencies that can be measured. If pulses aren't being counted, try lowering this value. If a lot of errant pulses are counted, try increasing it.
- Rising edge Count:
- see next section below.
- Analog Input:
- Chose analogue number to store count in, 1-20. Inputs 11-20 have a higher maximum pulse count due to being 32 bit vs 16 bits for inputs 1-10.
Rising Edge Counts
- Rising Edge Count
- Yes or No
If you want the pulse counter to increase the count on the rising edge which is the first green line, set to yes, if you want the count to increase on the falling edge, set to No.
Example Cellular Device Payload
An example of the pulse count coming through on analogue 17. The count will simply appear in Field ID 6 or 7 (analogue data fields), in the whatever analogue is chosen in parameters:
"6": 9984, // %Battery remaining
"17": 5 //Pulse Count
"FType": 6 // Field ID# - DMT-Data-Fields.pdf
How do I count pulses from a rain gauge/flow meter on the Eagle or Falcon?
So, with the information above, for a tipping rain gauge (or other device) which generates pulses, to configure we need to:
- Connect the rain gauge
- Ensure the Function is set to Digital Input
- Select a rising or falling edge count and debounce time.
- Then the count of pulses appears in the Analogue input we have set (or 17 by default).
- If we are expecting a lot of pulses, we probably don't want a "Digital Input Changed" log for every single pulse. So if that is the case, ensure to set Log On Active and Log On Inactive to No to avoid getting all of these logs.
The "Rain Gauge" Digital input function is a specific feature set and results in this behaviour when set:
- When a digital input change is detected the log reason is "Rain Gauge Tipped" - and the only fields uploaded with the log are the Digital Inputs (and not the analogue inputs)
- So we don't actually get the count uploaded with each tip as it is in the analogue fields - so this option should be avoided (it exists for a specific customer use case)
Pulse Counting on the SensorData and SensorNode LoRaWAN®
The same limitations and caveats apply. However configuration is simply slightly different and is covered in the relevant guides:
- SensorNode LoRaWAN® - Configuration and Usage Guide
- SensorData LoRaWAN® - Configuration and Usage Guide
'Optimised' Pulse Counting Power Draw
For the Eagle, Falcon, SensorData and SensorNode, we can estimate the power draw for various pulse rates and debounce periods.
Whenever the digital input on one of these devices changes, it wakes the board up from sleep to do a debounce cycle, and possibly count the edge and take an action. How much this affects the long-term power draw depends on how often the input changes, and how long the debounce period is. For example, if we set the SensorNode up to do a 10 ms debounce (the shortest before disabling debouncing entirely), and drive it with one pulse every 5 seconds, the average sleep current goes up from about 6 uA to 18 uA. The current draw looks like this at the moment the input changes:
And there are two of those every 5 seconds, for the rising and falling edge of the pulse:
Extrapolating to other settings we get (NOT including the cost of any alarms):
So we can see that on the default debounce setting (1000 ms, or 100 stable counts), counting one pulse per minute will use 13% of the battery every year.
Whereas, if we are confident that the pulses are very clean, we can turn the debounce off, and count 1 pulse per second for slightly less battery.
When the debounce is turned off, every detected change will be counted so long as there is at least 10 ms since the last change.
Different types of mechanical switches can have typical bounce times between 2 and 200 ms, so the lower settings should be used with caution.
"Non-Optimised" Pulse Counting on the Dart2, G62 and G120
The Dart2, G62 and G120 are primarily vehicle trackers and as such were not designed with pulse-counting as a primary feature/function. So there are caveats to the operation. It may be useful in some applications, and these devices might be desirable for other features meaning they are selected.
Parameter set up is as above for the Eagle and Falcon, with a few caveats:
- The function must be set to Pulse Counter
- The Config parameter sets both the analogue where the count is stored, and the debounce.
- If analogues 1-10 are selected, the debounce time is 10ms
- If analogues 11-20 are used, the debounce time is 20ms
So for all intents and purposes, the "Pulse Count" on these devices is effectively just a fast edge counter, that will not support counting fast pulses reliably. Additionally, the count is not stored in non-volatile memory, and will be lost on a device reset (i.e. parameter change, firmware update, power loss)