What Is the HART Preamble and Message Timing?
Every HART frame begins with a run of identical sync bytes before any real content, and the timing of who speaks when is carefully governed. Understanding the preamble and the message timing explains a class of intermittent HART problems that look like nothing else - a device that talks to one host but not another, or a link that works until you shorten a delay. This page covers what the preamble does, why its length varies, and how timing rules keep two masters from colliding. It is for anyone debugging flaky HART communication at the frame level.
HART Preamble in one line: The HART preamble is a run of identical sync bytes that begins every frame, giving the receiver time to detect the carrier and lock onto the incoming signal before the real message starts. The number of preamble bytes a device needs can be read and set, and HART's message-timing rules govern the gaps between transmissions so a second master and the field devices take turns without colliding.
Why Every Frame Starts With Sync Bytes
A HART frame does not begin with its address or command; it begins with a preamble, a series of identical bytes whose only job is to prepare the receiver. When the FSK tone starts on an otherwise idle loop, the receiver needs a moment to detect that a carrier is present and to synchronize its bit timing to the incoming stream. The preamble is that moment made explicit: a run of known bytes the receiver can lock onto, so that by the time the real message content arrives, the receiver is fully in step and reads it correctly.
The number of preamble bytes required is not fixed for every device. Some receivers lock on quickly and need only a short preamble; others, or noisier links, need more sync bytes to establish reliable reception. HART handles this by letting a host discover how many preamble bytes a device needs and configuring its own transmissions accordingly, so it sends enough preamble to satisfy the slowest receiver in the exchange without wasting time on excess. Sending too few preamble bytes is a real failure mode: a receiver that has not finished synchronizing simply misses the start of the message.
This is why a device can be readable by one host and not another. If a host is configured to send fewer preamble bytes than a particular device needs, that device intermittently or consistently fails to catch the message start, even though the wiring is fine and other devices on the same host work. Preamble mismatch is one of the quieter causes behind a HART communicator that cannot find a device, alongside the addressing and wiring issues the troubleshooting page for that symptom covers.
Message Timing and Taking Turns
Beyond the preamble within a single frame, HART governs the timing between frames so that the devices sharing a loop take orderly turns. After a master sends a request, there is a bounded window in which the addressed device must reply, and there are defined gaps a master must observe before it may transmit again or before the second master may take its turn. These timing rules are what let two masters coexist without a central clock: the arbitration between primary and secondary masters is enforced partly through these disciplined delays.
The timing discipline is also what prevents a master from stepping on a reply that is still in flight. A master that transmits too soon after issuing a request risks colliding with the device's response, corrupting both. Respecting the reply window and the inter-message gaps is therefore not optional politeness but a correctness requirement, and a host or a poorly written driver that shortcuts these delays produces exactly the kind of intermittent, hard-to-reproduce failures that make HART links seem unreliable when the physical layer is perfectly sound.
For the person debugging at this level, the useful mental model is that a healthy HART exchange has a rhythm: preamble, then message, then a disciplined gap, then the reply, then another gap before the next initiator speaks. When that rhythm is violated - too little preamble, too short a gap, a master transmitting into a reply window - the symptoms are intermittent rather than total, which is what makes them frustrating. The master-roles page explains the turn-taking these timing rules enforce, and together they cover why frame timing, not just wiring, determines whether a loop communicates cleanly.
Frequently Asked Questions
What is the HART preamble for?
It is a run of identical sync bytes at the start of every frame that gives the receiver time to detect the carrier and synchronize its bit timing before the real message begins. Without enough preamble the receiver has not finished locking on when the content arrives and misses the message start, so the preamble is essential for reliable reception, not overhead.
Why can one host read a HART device that another cannot?
One common cause is preamble mismatch. Devices differ in how many preamble bytes they need to synchronize, and a host configured to send fewer than a particular device requires will intermittently or consistently fail to reach it, even with good wiring. HART lets a host discover a device's required preamble count and send enough, which is why matching preamble length matters for compatibility.
Why do HART masters have to wait between messages?
The timing gaps let the devices on a loop take orderly turns and prevent a master from transmitting into a reply that is still in flight. A master that transmits too soon can collide with the device's response and corrupt both. These disciplined delays also enforce the turn-taking between the primary and secondary masters, so respecting them is a correctness requirement, not politeness.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.