DNP3 Qualifier and Range Field Explained

Back to Blog

What the Qualifier Byte Selects

An object header always carries three things: the object group and variation, then the qualifier, then the range. The qualifier is a single byte whose bits select how the range is expressed - whether indexes are 8-bit or 16-bit, and whether the range is a contiguous span or an explicit list. It is the key that tells the receiver how to read the bytes that follow.

This matters because the same group and variation can address points many ways. A qualifier that means start-stop, 16-bit tells the receiver the next four bytes are a first index and a last index; a qualifier that means count-of-index, 8-bit says the next byte is a count followed by that many one-byte index numbers. Reading the qualifier first is the only way to parse the rest of the header correctly, which is why it pairs so tightly with the object group and variation that precede it.

Start-Stop Ranges Versus Index Lists

A start-stop range is the compact way to ask for a block of contiguous points: read analog inputs from index 0 through 49, for example. It is efficient when the points you want are numbered consecutively, which they usually are in a well-organized point map. The receiver returns each index in the span in order.

A count-of-index list is used when the points are scattered or when a device reports events, because an event report names exactly which point changed rather than a whole block. Events therefore travel with their own index attached, which is how the master knows which of the DNP3 point indexes moved. Understanding both forms is what lets you look at an object header and say precisely which points a message touches, rather than guessing from the group alone.

Common Qualifier Codes at a Glance

A handful of qualifier values cover almost everything seen in real traffic, and because they are fixed by the standard they are worth recognizing on sight:

Qualifier	Range format	Typical use
0x00	8-bit start and stop indexes	Small contiguous block reads
0x01	16-bit start and stop indexes	Contiguous blocks beyond index 255
0x06	No range field - all points	Class polls and integrity polls
0x07	8-bit count, no indexes	Limited-quantity requests
0x17	8-bit count with 8-bit index prefixes	Events and controls on specific points
0x28	16-bit count with 16-bit index prefixes	Events and controls on larger point maps

The split between the 8-bit and 16-bit forms is purely about index width: a device with fewer than 256 points of a type can be addressed with the short forms, while bigger maps need the wide ones. Outstations generally choose the narrowest form that fits when they respond, which is why the same read can come back with different qualifiers from different devices carrying identical data.

Qualifier 0x06: Asking for Everything

The most common request qualifier in a healthy system carries no range at all. Qualifier 0x06 means all points of the requested object, so the master does not need to know the point count in advance. This is how class-based polling works: a request for event objects with qualifier 0x06 says give me whatever you have, and the outstation answers with index-prefixed qualifiers naming exactly which points changed. The same form drives the periodic full refresh - an integrity poll uses it to sweep every static point without enumerating a single index.

That asymmetry is worth noticing: requests are often index-free while responses are index-heavy. The master asks broadly with 0x06; the outstation replies precisely with 0x17 or 0x28 for events, or with start-stop forms for static blocks. Reading a capture with that pattern in mind makes the conversation legible - broad question, specific answer.

A Worked Header Walkthrough

Suppose a capture shows a response header whose group and variation identify analog input events, followed by qualifier 0x28, then a two-byte count of N, then N repetitions of a two-byte index and the event object itself. Reading it is mechanical: 0x28 announces a 16-bit count and a 16-bit index before each object, so the parser takes the count, then loops N times reading index-then-object. Each index maps directly to a tag in the master's point map, so the whole payload can be attributed point by point.

Now suppose the next header carries qualifier 0x01 with a start index of A and a stop index of B: the payload is one object for every index from A through B inclusive, in order and with no per-object indexes, so position within the block is what identifies each point. Practicing this on live traffic is fastest with a protocol-aware tool - capturing DNP3 traffic in Wireshark decodes the qualifier and range for you, which makes checking your manual reading painless.

When a Qualifier Is Rejected

Not every outstation supports every qualifier for every object group. When a request arrives in a form the device cannot honor, it responds with internal indication bits set - typically the parameter-error or unknown-object flags - and no data, which from the master side looks like a poll that returns nothing while the link is clearly alive. The fix is configuration, not retries: consult the outstation's device profile, which documents the qualifiers it accepts for each group, and align the master's request forms with it.

Frequently Asked Questions