Hunter Industries got stable DNP3 trend behavior from its QuickServer integration instead of generating event changes at every 1 mA step. The fix was not a hardware change. It was a configuration refinement in the event-handling logic that had to be identified and tested quickly under a tight deadline.
This project was not a generic gateway setup. The upstream side used a Hunter Industries protocol, while the downstream side needed DNP3 Ethernet behavior that would trend and buffer changes the way the client expected. Chipkin used a Chipkin QuickServer to refine the configuration and stop unnecessary event churn caused by a CAST_Delta value that had been left at zero.
At a Glance
- Industry: Irrigation / automation
- Customer: Hunter Industries
- Facility type: OEM controls integration environment
- Client role: Automation software team
- Protocols: From: Hunter Industries protocol → To: DNP3 Ethernet
- Chipkin product: Chipkin QuickServer
- Project window: 17 days
Hunter Industries Controller → Proprietary Protocol → Chipkin QuickServer → DNP3 Ethernet → SCADA / Telemetry Client
Hunter Industries Protocol to DNP3 Ethernet Challenge
The customer was not fighting a total communications failure. The harder issue was that the downstream trend behavior needed refinement. Instead of logging only meaningful changes, the system was recording changes at every 1 mA step when the intended threshold was 45 mA. That kind of event behavior uses more buffer capacity and makes the telemetry stream less useful.
Chipkin traced the issue to the StoreOnChange MapDescriptors. The CAST_Delta parameter was set to 0, which meant the downstream DNP3 side treated every tiny analog movement as an event. The project was under a tight deadline, so the customer needed a configuration correction they could test quickly instead of a longer redesign cycle.
This was a good example of why protocol-conversion projects fail even when the devices are technically connected. The downstream system did not just need data. It needed the right event behavior.
Why Chipkin
Chipkin was a fit for this project because the problem sat in the translation logic between the upstream source behavior and the downstream DNP3 Ethernet expectations. A generic gateway answer would not have helped much. The project needed someone to review the event-handling configuration, isolate the threshold behavior, and turn around a corrected file quickly.
Chipkin QuickServer provided the platform, but the actual value came from identifying the exact configuration parameter that was creating the trend noise and updating it without forcing the customer into a longer redesign cycle.
The Solution
Hunter Industries Controller → Proprietary Protocol → Chipkin QuickServer → DNP3 Ethernet → SCADA / Telemetry Client
Chipkin reviewed the existing configuration, confirmed that the StoreOnChange behavior was too aggressive, and revised the QuickServer file so the downstream DNP3 client would only trend meaningful analog changes. The key technical correction was removing the zero-threshold behavior created by CAST_Delta=0.
That fix mattered because the project was not about getting any value across the wire. It was about getting the right change behavior into the downstream telemetry system so the event buffer would remain usable under real operating conditions.
With the revised configuration in place, the customer could retest the project against the actual trend requirements instead of continuing to review event behavior at the client level.
DNP3 Trend-Stability Results
- Corrected trend behavior — the downstream DNP3 system no longer had to process event changes at every 1 mA step.
- 3 configuration revisions were enough to isolate and correct the event-threshold problem.
- 10 support hours were invested across the review, update, and validation cycle.
- 17-day turnaround kept the project moving under a tight customer deadline.
- 60% customer-side wait time indicates the critical fix was delivered quickly once the logs and retest feedback were available.
Before: The integration produced too many downstream events because the change threshold was effectively zero.
After: The customer had a revised QuickServer configuration aligned to the intended 45 mA trend behavior, reducing event churn and protecting downstream buffer capacity.
Have a Similar Protocol-to-DNP3 Project?
If your downstream DNP3 system is technically connected but trending, buffering, or event behavior still needs refinement, Chipkin can review the gateway logic, correct the conversion rules, and help you get to a usable telemetry handoff faster. Tell us about your project.