Ordinary HART communication is request-and-response: the host asks a device for a value and the device answers, one round trip at a time. That polling is reliable but slow, because the digital layer is riding on top of an analog 4-20 mA loop and every reading costs a full question-and-answer exchange. Burst mode flips the pattern so the device speaks on its own, repeatedly publishing its variables without waiting to be asked, which raises the effective update rate. This page explains how burst mode works, roughly how much faster it is, why it usually needs the loop to itself, and where it fits against multidrop.
HART Burst Mode in one line: HART burst mode, also called publish mode, is a setting where a field device continuously broadcasts its selected variables onto the loop on its own instead of answering individual poll requests one at a time. Removing the request half of every exchange lets the device send updates roughly three times as often, but because the device is transmitting almost continuously it normally must be the only HART device on that loop.
Standard HART is a master-slave protocol. The host acts as master and issues a command, the device receives it and replies with the requested data, and only then can the next command go out. Each digital value therefore costs a full round trip on a communication layer that is already slow, because the HART digital signal is a low-rate tone superimposed on the analog current loop. For a single process variable that arrives quickly enough, but reading several digital variables or a device's status by repeated polling adds up.
Burst mode changes the device's behavior so it stops waiting to be asked. Once configured, the device repeatedly transmits a chosen HART command response, its process variables, its device status, or another selected message, onto the loop at a regular cadence with no request preceding each one. The host simply listens and takes the values as they arrive. Eliminating the request half of every exchange, and the turnaround time between them, is what makes burst mode faster.
The practical effect is a meaningfully higher update rate for the published variables, commonly cited as roughly triple what polling delivers, because the device is no longer spending time listening for and acknowledging each individual request. For applications that want the freshest possible digital reading from one instrument, such as feeding a secondary variable into a controller, that faster cadence is the whole point of turning burst mode on.
The cost of continuous publishing is the loop itself. Because a bursting device is transmitting nearly all the time, it leaves little room for the normal poll-and-response traffic that lets a host talk to other devices on the same wires. If two devices tried to burst on one loop they would collide, and even one bursting device makes it hard for a host to reliably reach a second device to poll it. For this reason burst mode is essentially a single-device arrangement: the bursting instrument has the HART channel to itself.
That constraint is what separates burst mode from multidrop. Multidrop parks the analog current at a fixed low value and shares one pair of wires among several digitally addressed devices, trading update speed for device count. Burst mode does the opposite: it keeps a single device, often still delivering its primary variable as a live 4-20 mA signal, and spends the digital channel on making that one device's readings arrive as fast as possible. The two modes optimize for opposite goals and are not combined on the same loop.
There is also a host-side consideration. Because a bursting device pushes data rather than answering queries, the receiving system has to be set up to listen for and consume the unsolicited messages. A HART interface or gateway that only knows how to poll will not benefit from burst mode, and can even be confused by the continuous traffic. Configuring burst mode therefore means coordinating both the device's publishing settings and the host's ability to catch what it sends.
For a monitoring system the appeal of burst mode is getting more than the single analog value out of a smart instrument without paying the polling penalty. A modern transmitter measures several things beyond its primary variable, and burst mode is a way to keep one or two of those secondary digital variables refreshed quickly enough to be useful for trending or control. When those values are pulled into a cloud SCADA platform such as Merobix through a HART-capable interface, burst mode is one of the mechanisms that determines how fresh the digital data behind each tag is.
The tradeoff to weigh at a site is speed against fan-in. Burst mode maximizes the update rate from one device but commits an entire loop to that device, so it suits a critical measurement point where fast digital data matters more than wiring density. Where the goal is instead to gather many slow-changing points over shared wiring, multidrop or conventional per-device polling is the better fit. A remote operation typically mixes these, using burst mode selectively where the extra update speed earns its dedicated loop.
Understanding which mode a loop uses also helps interpret the data downstream. A tag fed by a bursting device should update briskly and continuously, so a stalled or stale value points at the device, the loop, or the listening interface rather than at slow polling. Knowing that a point is on burst mode versus a busy polled multidrop segment tells an operator what a delay in updates actually means and where to look when a reading stops refreshing.
Burst mode is commonly described as delivering roughly three times the update rate of ordinary polling, because it removes the request half of every exchange and the turnaround time between requests. The device simply transmits its selected variables on a repeating cadence instead of waiting to be asked. The exact improvement depends on the device and the message it is configured to burst.
No, practically only one device can burst on a given loop. A bursting device transmits almost continuously, so a second bursting device would collide with it and even normal polling of other devices becomes unreliable. Burst mode is therefore a single-device arrangement, which is what distinguishes it from multidrop where several digitally addressed devices share the wires at slower speeds.
Multidrop shares one pair of wires among several devices by parking the analog current low and addressing each device digitally, trading speed for device count. Burst mode keeps a single device and uses the digital channel to publish that device's variables as fast as possible, often while still sending its primary value as a live 4-20 mA signal. They optimize for opposite goals and are not used together on one loop.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.