How to Set Up HART Burst Mode on a Transmitter

Back to Blog

What You Need

You need a HART host or handheld able to configure burst mode, a connection to the transmitter, and, critically, a loop that the transmitter can have to itself. Because a device in burst mode is transmitting its data repeatedly on its own initiative, it dominates the loop, so a bursting device normally must be the only HART device on that loop. Confirming that before you start saves you from enabling burst on a shared loop where it will interfere with other devices. The burst mode overview page explains this one-device constraint in depth.

You also need to know what the receiving side expects. A host or gateway that is going to consume burst data has to be listening for unsolicited publishes rather than only polling, so confirm the receiving end supports and is configured for burst reception. Enabling burst on the device while the host still only polls means the fast publishes go unheard, which defeats the purpose. The pieces have to match on both ends.

Confirm the Loop Has One Device

Verify the transmitter is alone on its HART loop before enabling burst. The reason is mechanical: a bursting device transmits so frequently that it leaves little room for another device's exchanges, so putting burst on a multidrop or shared loop causes contention that degrades everyone's communication. This is the single most common setup error, and it is easy to avoid by confirming the loop is point-to-point with just this one device first.

If you need fast updates from several devices, burst on a shared loop is not the answer, and you should reconsider the architecture rather than force it. Multiple fast points usually call for individual loops, a different transport, or WirelessHART, because the loop-to-itself requirement of burst is a hard constraint, not a preference. Recognizing this before configuration saves rework, and the comparison of multidrop and WirelessHART covers the alternatives when many points are involved.

Choose the Burst Command and Variables

Select what the device will publish. Burst mode publishes the response to a chosen command, and for most monitoring the natural choice is command 3, because it carries the loop current and all four dynamic variables in one publish - the same efficient bundle a host would otherwise poll. Choosing command 3 means each burst delivers the device's full set of live values, which is usually exactly what a monitoring system wants. Other burst commands exist for publishing specific device variables when that is the need.

Then confirm the dynamic-variable mapping is what you intend, because burst publishes whatever the mapping has placed in the variable slots. If you want flow published as the primary value, the flow device variable must be mapped to the PV before you burst command 3, or the device will faithfully publish the wrong variable in that slot. The device-variables page covers that mapping; getting it right before enabling burst avoids publishing a stream of correctly formatted but wrongly assigned data.

Set the Update Rate and Trigger, Then Enable

Set how often the device publishes. Burst mode lets you choose an update rate, and on capable devices a trigger condition - publishing on a fixed interval, or faster when a variable changes by more than a set amount, so slow-moving points do not flood the loop while fast changes are still caught promptly. Choose the slowest rate that meets the monitoring need, since a faster rate consumes more of the loop and, on wireless, more battery. Then enable burst so the device begins publishing.

After enabling, the device starts transmitting its chosen content on its own initiative without waiting to be polled, which is the entire point - the effective update rate rises because the request half of every exchange is gone, so each turn on the wire carries only the device's reply. The burst mode page covers why publishing unsolicited data is faster than polling. Confirm the device is actually in burst mode and not merely configured for it, since some hosts distinguish setting the parameters from turning the mode on.

Verifying the Result

Confirm the host or gateway is receiving the publishes. The setup is only successful when the receiving side is seeing the transmitter's unsolicited updates arrive at the configured rate, not when the device is bursting into a host that is still only polling and hears nothing new. Watch the receiving end for the faster, self-initiated updates, and check that the update rate you observe matches what you configured. If the host still shows polled-rate updates, the receiving side is not consuming the burst.

A second check is that the published variables are the ones you intended, in the slots you meant. Because burst publishes the mapping, verifying that the primary published value is the measurement you wanted confirms both the command choice and the variable mapping in one look. A stream arriving at the right rate but carrying the wrong variable in the primary slot means the mapping, not the burst setup, needs correcting.

Common Mistakes

The classic mistake is enabling burst on a loop that is not point-to-point, so the bursting device contends with others and everyone's communication suffers. The second is configuring burst on the device while the receiving host still only polls, so the fast publishes go unheard and the effort produces no benefit. The third is bursting a command whose variable mapping was never set, so the device reliably publishes the wrong measurement in the primary slot.

A subtler mistake is choosing an unnecessarily fast update rate, which consumes loop time and, on a WirelessHART device, drains the battery faster for no monitoring gain. Match the rate to how fast the measurement actually changes and how fresh the reading truly needs to be. A change-triggered publish often gives fast response when it matters and low traffic when the process is quiet, which is usually the better setting than a blanket high fixed rate.

Frequently Asked Questions