Dragino Pulse Counting for Rain Gauges and Production Counters: Choosing the Right Input Device
Updated: 5 days ago
A pulse counter sounds simple until the first missed tip of a rain gauge, the first double-counted relay click, or the first production total that does not match the machine’s own counter. The device is only part of the system. The pulse source, wiring, input type, debounce setting, report schedule, and count range all decide whether the data can be trusted.
Dragino input devices are often used where a small sensor or machine output needs to send counts over LoRaWAN or another low-power network. That makes them a good fit for remote rain gauges, water meters, utility meters, and basic production counters. The key is choosing the right input device for the signal already available on the equipment.

Pulse counting starts with the type of signal
A pulse counter does not count “rain” or “parts” directly. It counts changes at an input. The first question is what kind of electrical signal creates those changes.
Common pulse sources include:
Dry contact closures A reed switch, relay contact, or microswitch closes and opens without supplying voltage. Many tipping bucket rain gauges work this way.
Open collector or open drain outputs A transistor output pulls the input low when active. This is common on industrial sensors, some meters, and PLC outputs.
Voltage pulse outputs The source sends a defined voltage pulse, such as from a powered sensor, controller, or meter module.
PNP or NPN proximity sensors These are common in production counting. The sensor may switch positive voltage or switch to ground, depending on the design.
Relay outputs from a machine or PLC These can be easy to connect, but relay bounce and electrical noise need attention.
A Dragino pulse input device must match the source. A dry contact input is not the same as a voltage input. A device that expects a clean contact closure may not be suitable for a 24 V sensor output unless the specification says it can accept that signal. A device designed for an open collector input may need pull-up behavior, polarity checks, or a shared reference.
Before selecting hardware, identify these details:
Detail to check | Why it matters |
Contact or voltage output | Prevents damage and missed counts |
Pulse voltage range | Confirms the input can safely read the signal |
Sink or source output | Helps match NPN, PNP, or open collector signals |
Minimum pulse width | Ensures short pulses last long enough to be counted |
Maximum pulse rate | Prevents undercounting at high speed |
Shared ground requirement | Avoids floating or unstable signals |
Isolation needs | Reduces risk when connecting to existing machinery |
Rain gauges are usually the easier case. A tipping bucket often uses a low-speed reed switch. Production counters can be more demanding because they may run faster, use powered sensors, and sit near motors, contactors, drives, and other noise sources.
That is why Dragino Pulse Counting for Rain Gauges and Production Counters should not be treated as a one-product decision. It is an input-matching decision.
Rain gauges need clean contact counting
A tipping bucket rain gauge usually closes a reed switch each time the bucket tips. One pulse equals one known amount of rain, based on the gauge calibration. For example, a gauge may produce one pulse for each 0.2 mm, 0.254 mm, or 0.01 inch of rainfall, depending on its design.
The input device does not need to understand the rainfall amount. It only needs to count each closure once. The software or receiving platform can convert pulses into rainfall total.
A good rain gauge setup needs:
A pulse input compatible with a dry contact or reed switch
Suitable debounce for the reed switch
Outdoor-rated enclosure and cable entry
Battery life that matches the site visit schedule
A reporting interval that catches useful changes without wasting power
Coverage from the LoRaWAN gateway or network
Rain gauges also need care during storms. The pulse rate may be slow most of the year, then rise sharply during heavy rain. The device should be able to count pulses locally between transmissions, rather than relying on one network message per pulse. Sending one uplink for every tip can waste battery and overload the network during the exact period when the data matters most.
The better pattern is simple: count every tip locally, then report totals at a sensible interval.
Production counting has more ways to go wrong
Production counters often seem easy because there is already a machine signal somewhere. That signal might come from a photoelectric sensor, proximity sensor, reject gate, PLC output, machine relay, or existing counter terminal.
The challenge is that “one product equals one pulse” is not always true at the electrical level.
A photoeye may chatter if the product edge is irregular. A relay output may bounce. A proximity sensor may create narrow pulses at high line speed. A PLC output may use a voltage level that the input device cannot accept directly. A machine may already have a count output, but it may count cycles rather than finished parts.
Before choosing a Dragino input device, define the count event in physical terms:
A bottle passes a photoeye
A carton trips a proximity sensor
A press completes one cycle
A reject actuator fires
A pallet leaves a conveyor zone
A PLC output turns on after a verified good part
Then define the electrical signal that represents that event.
That distinction matters. Counting a press stroke may be simple, but it may not equal good production. Counting a reject gate pulse may help quality data, but it will not give total output. Counting a photoeye pulse may give finished units, but only if product spacing and sensor alignment are reliable.

Debounce decides whether one event becomes one count
Mechanical contacts do not always close cleanly. A reed switch or relay can bounce, opening and closing several times in a few milliseconds. Without filtering, the counter may see one physical event as several pulses.
Debounce is the filter that prevents this. After the input detects a change, the device ignores further changes for a short period. For rain gauges and relay contacts, debounce is often essential.
The risk is setting debounce too long.
If the debounce time is longer than the gap between real pulses, the device will ignore valid events. That is usually not a problem for a slow tipping bucket in light rain, but it can matter during intense rainfall or on fast production machinery.
A practical way to think about debounce is this:
Too short Contact bounce may be counted as extra pulses.
Too long Real pulses close together may be missed.
Just right One physical event produces one count.
For rain gauges, the debounce setting should suit the reed switch and the fastest expected tip rate. For a machine counter, it should suit the sensor type and line speed. A solid-state proximity sensor may need little or no debounce. A relay output may need more filtering.
The safest approach is to test with the real signal. Bench testing with a button can prove the input works, but it may not reveal what happens on a vibrating machine or during heavy rain. A short live test can catch double counts, missed counts, polarity errors, and noise problems before the installation becomes permanent.
Reporting intervals affect battery life and data value
A pulse input node usually counts locally, then sends a value at set intervals. That interval affects battery life, network traffic, and how quickly changes appear in the monitoring system.
Short intervals give more current data. Long intervals save power and reduce network use. The right choice depends on the application.
For rain monitoring, a site may only need regular totals during normal weather, but faster reporting during storms can be useful. If the platform supports alerts based on accumulated count or rainfall rate, the report schedule should support those alerts.
For production counting, reporting may need to match operations. A factory may want totals every few minutes, every hour, or at shift change. If managers use the data to compare line output, find stoppages, or verify batches, reporting too slowly can reduce its value.
Use a simple calculation before deployment:
`maximum counts per report = maximum pulse rate × reporting interval`
If a production line can create 2 pulses per second and the device reports every 10 minutes, it must store at least 1,200 counts between reports. If the line can create 20 pulses per second, the same interval becomes 12,000 counts.
For rain gauges, the pulse rate is usually much lower, but the device must still handle storm bursts and long offline periods. If the network connection drops, a local counter can continue to increase. The platform should also handle the next reported total correctly when communication returns.

Count limits and rollover need checking before installation
Every pulse counter has limits. These may include the highest pulse frequency it can count, the shortest pulse width it can detect, the largest accumulated count it can store, and the way it handles rollover.
Count rollover happens when a counter reaches its maximum value and returns to zero. This is normal in many digital systems, but the receiving software needs to account for it. If it does not, a normal rollover can look like a reset or a data error.
Check these points in the device documentation before purchase:
Maximum input frequency
Minimum high and low pulse duration
Counter register size or maximum count
Whether counts are stored through power loss
Whether the payload sends total count, interval count, or both
How resets are handled
Whether the counter can be cleared remotely or only locally
The difference between total count and interval count matters.
A total count keeps increasing over time. It is useful because the receiving system can calculate the difference between reports. It can also recover better from missed messages.
An interval count reports only the pulses since the last message. It is easy to read, but a missed message may mean lost count data unless the device or platform stores history.
Some devices can provide both, depending on configuration. The best choice depends on the monitoring platform and how the data will be used.
How to choose a Dragino input device for existing equipment
The right Dragino device is the one that matches the existing signal with the fewest adapters and the least risk. Start with the field equipment, not the catalog.
A selection process should include these steps:
Identify the source of the pulse
Confirm whether the signal comes from a reed switch, relay, open collector output, proximity sensor, photoeye, meter output, or PLC.
Measure or confirm the signal level
Check voltage, polarity, pulse width, and whether a shared ground is required. Use drawings where available, but verify on real equipment when practical.
Estimate the fastest pulse rate
Use the highest expected machine speed, not the average. For rain gauges, consider heavy rainfall and the gauge resolution.
Match the input type
Choose a device that supports the pulse source directly, or plan a proper interface such as a relay, opto-isolator, or signal conditioner.
Set debounce for the real source
Use enough filtering to prevent false counts, but not so much that valid pulses are missed.
Choose the reporting interval
Balance battery life, LoRaWAN traffic, alert needs, and the usefulness of the data.
Check count capacity
Make sure the counter can handle the expected count between reports, during outages, and over the required operating period.
Test before scaling
Compare the Dragino-reported count against the existing machine counter, rainfall calibration, or manual count over a known period.
Where ProSense Instruments helps
ProSense Instruments can help buyers avoid the common trap of choosing a pulse counter only by product name. The better question is: what signal does the existing equipment provide, and what does the monitoring system need to receive?
That support can include checking the pulse source, narrowing the suitable Dragino input device options, and flagging items that need confirmation before purchase. For example, a rain gauge with a reed switch may need a different input setup than a powered 24 V proximity sensor on a conveyor. A slow production counter may work with a basic contact input, while a faster line may need careful review of pulse frequency and pulse width.
ProSense Instruments can also help define the practical parts of the installation:
Battery-powered or externally powered device
Outdoor or indoor enclosure needs
Cable length and protection
LoRaWAN region and gateway coverage
Payload decoding and count conversion
Rainfall-per-tip or units-per-pulse scaling
Existing PLC, meter, or sensor compatibility
Testing plan before rollout
For buyers with existing equipment, this is often the fastest path. Instead of replacing a working rain gauge or machine sensor, the right Dragino input device can read the signal that is already there.

The best device is the one that counts the real event correctly
Pulse counting is useful because it turns simple events into reliable remote data. A bucket tips. A carton passes. A relay closes. A machine completes a cycle. The value comes from counting those events once, storing them safely, and reporting them at the right time.
For rain gauges, focus on dry contact compatibility, reed switch debounce, weather protection, and sensible reporting during storms. For production counters, focus on the electrical output type, pulse frequency, noise, debounce, and what the pulse really represents in the process.
ProSense Instruments can help match Dragino input devices to existing equipment before anything is installed. That means fewer wiring surprises, fewer missed counts, and data that stands up when compared with the gauge, meter, or machine counter already on site.
Need help with your application?
ProSense Instruments — explore instruments, sensors, data loggers and test equipment.
ProSense Solutions — discuss complete monitoring and automation systems.
ProSight Software — explore cloud dashboards, alarms and reporting. Device integration must be confirmed for your application.
Instrument enquiries: sales@prosenseinstruments.com.au | 1800 560 854
Project enquiries: sales@prosense.com.au. Software enquiries: info@prosightsoftware.com.




Comments