Why Your Breaker Position Flickers on DNP3 — and What Double-Bit Inputs Fix

The breaker that "opens" every time it closes

An operator closes a feeder breaker from the SCADA. For about 40 milliseconds the position indicator flashes OPEN, then settles on CLOSED. Do it enough times and someone files a ticket: the breaker is bouncing. It isn't. The auxiliary contacts are just doing what mechanical contacts do — the 52a hasn't made yet and the 52b has already broken, so for a moment the outstation sees neither. Read that gap as a single bit and you get a lie: OPEN, briefly, in the middle of a close.

That flicker is the whole reason DNP3 has double-bit binary inputs. If you're mapping breaker or motorized-disconnect status as a plain single-bit Binary Input (object group 1), you've built the flicker in and you'll spend commissioning day writing debounce timers to paper over it. Use the right object and the problem mostly disappears.

One contact can't describe a breaker

A breaker doesn't have two states. It has four things you actually care about: it's open, it's closed, it's moving between the two, or it's confused (stuck, or the contacts disagree). A single bit forces all of that into 0 or 1, so you throw away exactly the information that matters when something goes wrong.

The mechanical reality is two auxiliary contacts. The 52a follows the main contacts — closed when the breaker is closed. The 52b is the mirror — closed when the breaker is open. Feed both into the outstation and you can tell the four states apart:

52a open, 52b closed → breaker is OPEN.
52a closed, 52b open → breaker is CLOSED.
both open → the mechanism is between positions — traveling. This is the flicker window.
both closed → a fault. Contacts shouldn't both assert. Misaligned aux switch, welded contact, or a wiring problem.

DNP3 encodes those two bits directly. Per IEEE 1815-2012, a double-bit point holds a two-bit value:

0b01 — Determined OFF (breaker open)
0b10 — Determined ON (breaker closed)
0b00 — Intermediate (in transition)
0b11 — Indeterminate (abnormal — both or neither in a way that can't resolve)

The bit ordering matters and trips people up: it's not "1 = on." The pair is the value. 10 is ON, 01 is OFF. Get an outstation config where someone swapped the sense and every open breaker reports closed.

The objects: group 3 and group 4

Static (current value) double-bit binary inputs are object group 3. Change events are object group 4. They parallel the single-bit group 1 (static) / group 2 (event) pair exactly, so if you already understand class polling for binary inputs, this is the same mechanism with a wider value.

Variations you'll actually meet:

g3v1 — packed format, no flags. Four points per byte. Fine for a bulk integrity poll where you don't need quality.
g3v2 — with flags. One octet per point: the two-bit state plus the standard flag bits (ONLINE, RESTART, COMM_LOST, REMOTE_FORCED, LOCAL_FORCED, CHATTER_FILTER). Use this. The flags are half the value — an Intermediate state with COMM_LOST set means something different from a clean transition.
g4v1 — event, no time.
g4v2 — event with absolute time.
g4v3 — event with relative time (ms offset from a common time reference).

For breaker status, assign the double-bit points to Class 1 so operations come through as unsolicited events (or a fast Class 1 poll), and request g4v2 so each state change carries a timestamp. When a breaker trips, the timestamp on that Intermediate → Determined-OFF sequence is what your sequence-of-events analysis runs on. A trip without a time is a trip you can't correlate against the protection relay's own record.

Mapping it in the SCADA

The outstation gives you a two-bit value; your master has to turn that into something an operator screen and an alarm engine can use. Two common approaches:

Map to a four-state derived tag. Read the double-bit point into an integer status tag with an enumeration: 0 = Intermediate, 1 = Open, 2 = Closed, 3 = Indeterminate. Drive the breaker symbol color and animation off that: green closed, red open, blinking/hatched for Intermediate, and a distinct fault color for Indeterminate. Most modern SCADA packages (many of them a DNP3 master over a driver) expose double-bit points as exactly this kind of multi-state tag — check whether yours does before you reinvent it with two single-bit tags and expression logic. Rebuilding double-bit decode from two group-1 points in the HMI is the thing to avoid; you'll recreate the flicker you were trying to kill.

Alarm the abnormal states, not the normal ones. Open and Closed are commanded states — don't alarm every operation, that's what a state-change log is for. Alarm on:

Indeterminate (0b11) — this is a real fault. Latch it, priority high. Both aux contacts asserting means the position is genuinely unknown, and "unknown breaker position" is a safety problem, not a nuisance.
Intermediate that doesn't clear. Traveling for 40 ms is normal. Traveling for 5 seconds means the breaker is stuck mid-stroke. Put a timer on the Intermediate state — a few hundred ms longer than the breaker's rated operating time — and alarm if it doesn't resolve to a determined state. Motor-operated disconnects have long travel times, so tune this per device; a 2-second on-delay that's right for a breaker will false-alarm on a slow motorized switch.

Commissioning: prove all four states

The single-bit trap is that it tests fine. Open works, closed works, ship it — and the Intermediate flicker only shows up in production when the timing is unlucky. Double-bit points need you to force all four states on the bench, because the two abnormal ones are exactly the ones nobody exercises.

Open and Closed — operate the breaker, confirm the master reads Determined OFF / Determined ON and the enumeration matches. Watch the sense: an inverted pair reads backward.
Intermediate — you usually catch this live during a real operation. If you want to force it, lift both aux wires momentarily (with the breaker safe) and confirm the state goes to 0b00, not to a determined state or a comms fault.
Indeterminate — jumper both aux inputs closed and confirm 0b11 and the fault alarm. This is the state that catches real wiring errors later, so prove the path works now.

While you're there, check the chatter filter. Aux contacts bounce, and a breaker that reports a burst of transitions on every operation will flood your event buffer and can push good events out. DNP3 outstations expose a chatter-filter setting per binary point; the CHATTER_FILTER flag in g3v2/g4v2 tells you when it's actively suppressing. If you see that flag set during normal operations, the debounce is too tight for these contacts — loosen it at the outstation rather than filtering in the master, where you've already paid the event-buffer cost.

When single-bit is still fine

Not everything needs two bits. A pump run/stop, a valve limit switch you only read one end of, a generic digital input — single-bit group 1/2 is correct and using double-bit there just wastes points and confuses the map. The rule I use: if the device has a genuine transition time you care about, or two independent contacts that can disagree, it earns a double-bit point. Breakers, motor-operated disconnects, and reclosers qualify. A relay output coil doesn't.

The next thing to check after you've mapped the points: whether your sequence-of-events resolution actually survives the trip. Double-bit gives you the states; g4v2 gives you the timestamps — but if the outstation's clock isn't synced, the times are decoration. That's a separate commissioning step, and it's the one that turns a pile of breaker events into an actual fault timeline.