Some communication standards just emerge. Not because they are pushed by a large group of vendors or a special standards organisation. These standards—like the Modbus interface—emerge because they are good, simple to implement and are therefore adapted by many manufacturers. Because of this, Modbusbecame the first widely accepted fieldbus standard.

Modbus has its roots in the late seventies of the previous century. It is 1979 when PLC manufacturer Modicon—now a brand of Schneider Electric’s Telemecanique—published the Modbus communication interface for a multidrop network based on a master/client architecture. Communication between the Modbus nodes was achieved with messages. It was an open standard that described the messaging structure. The physical layer of the Modbus interface was free to choose. The original Modbus interface ran on RS-232, but most later Modbus implementations used RS-485 because it allowed longer distances, higher speeds and the possibility of a true multi-drop network. In a short time hunderds of vendors implemented the Modbus messaging system in their devices and Modbus became the de facto standard for industrial communication networks.

MODBUS is an application layer messaging protocol that provides client/server communication between devices connected on different types of buses or networks.

MODBUS is a request – replay protocol offering services specified by function codes. It can be implemented on different physical supports and networks such as: RS232, RS485 or Ethernet.

MODBUS/TCP is a communication protocol designed to allow equipment such as Programmable Logic Controllers, computers, operator panels, motors, sensors, and other types of physical input/output devices to communicate over a network.

The master of system sends telegrams to a specific slave unit (uni-casting dialog) or to all the units (broadcasting dialog) that are linked in the network, and after that he wait for the response of them. The response is processed generating a new action.

In the table and figure present the levels of protocol in accordance with the general form of OSI layers.


OSI Model




MODBUS Application Protocol










Link MODBUS Serial Protocol


Physical EIA/TIA-232 or EIA/TIA-485

 The layers of MODBUS protocol (EPA architecture)

The standard protocol define some abbreviations:

ADU Application Data Unit
HDLC High level Data Link Control
MAC Medium Access Control
PDU Protocol Data Unit

In the case of MODBUS protocol the application data unit is build by the client that initiate a transaction to the server. The server will process the request and will response with a new telegram at the client.

MODBUS frame Application Data Unit

MODBUS frame Application Data Unit that includes Protocol Data Unit

The transmission mode defines the bit contents of the message bytes transmitted along the network, and how the message information is to be packed into the message stream and decoded. MODBUS serial communication and MODBUS TCP/IP are compared to the 7 layers of the OSI model.



The code functions accepted by MODBUS are represented by a byte, which accept one of the values 1 to 255 (the codes between 128 to 255 are reserved for exceptions). The code functions specify for the server the action that it must perform. 

Sub-function codes are added to some function codes to define multiple actions. The data field of messages sent from a client to server contains additional information that the server uses to take the action corresponding to function code.

This can include items like discrete and register addresses, the quantity of items to be handled, and the count of actual data bytes in the field and so on. Some function can be transmitted without operands.

For a normal response, the server simply echoes the original function code. If the telegram is properly received the server will return to client the response with data requested. If the telegram is received with error the server will return an error message that will generate the resend of initial telegram (we name this a exception code). If the error are maintained an uncovered error will by generated in order to indicate the status of the link.



modbus protocolSend RequestRequest

transmission modbus

           Perform the action requested

Receive the response  

 Typical dialog between client and server for MODBUS protol

  • To send request means to transmit the function code and the data corresponding for it.
  • The response will include the function code and the data requested.

Three categories of MODBUS function codes are defined:

  • Public function Codes
  • User-defined function Codes
  • Reserved function Codes

The first category include well-defined public function codes, unique defined for all the users of protocol. These functions are documented in the MODBUS IETF RFC and are verified by the MODBUS organization.

The user-defined codes, assure the flexibility of protocol that accept that the producer can add new functions without the approval of These codes not present the guaranty that they are unique. In this case the producers must initiate a new RFC in order to publish the specification of them.

Related to the reserved functions, these are functions used by companies for legacy products and not represent public functions interest.

Table 5.4 Address of functions


Which are the dedication of domain address

111 to 127

Public Function Codes

100 to 110

User-defined Function Codes

73 to 99

Public Function Codes

66 to 72

User-defined Function Codes

1 to 65

Public Function Codes

Standard MODBUS networks employ one of two types of transmission modes:

  • ASCII Mode
  • RTU Mode.

The mode of transmission is usually selected along with other serial port communication parameters (baud rate, parity, etc.) as part of the device configuration.

 ASCII Transmission Mode

In the ASCII Transmission Mode (American Standard Code for Information Interchange), each character byte in a message is sent as 2 ASCII characters. This mode allows time intervals of up to a second between characters during transmission without generating errors.

RTU (Remote Terminal Unit) Transmission Mode

In RTU (Remote Terminal Unit) Mode, each 8-bit message byte contains two 4-bit hexadecimal characters, and the message is transmitted in a continuous stream. The greater effective character density increases throughput over ASCII mode at the same baud rate.

RTU transmission mode

 RTU transmission mode

 Details related to the modbus serial implementation

In the serial implementation, the ASDU with the PDU are transmitted through a serial line that can be RS232 line (short distance), if the line link two elements, or RS485 line (long distance) if the link between the elements is a bus.

In ASCII mode, the word size is 7 bits, while in RTU mode; the word size is 8 bits. Thus, every 8 bits of an RTU message is effectively 11 bits when accounting for the start, stop, and parity bits of the data frame. The structure of the data frame depends on the transmission mode (ASCII or RTU).

The MODBUS data link layer comprises two separate sub layers:

  1. Master / slave protocol
  2. Transmission mode (RTU vs ASCII modes)

The state diagrams of a master and a slave that are independent of transmission modes used describe the reception and the sending of a frame are described in figure placed bellow.

State Diagram for Master MODBUS

 State Diagram for Master MODBUS

In the case of Master MODBUS, the steady state of system is idle state. In this case no pending requests are active.  A request can only be sent in “Idle” state. After sending a request, the Master leaves the “Idle” state, and cannot send a second request at the same time.

When a unicast request is sent to a slave, the master goes into “Waiting for reply” state, and a “Response Time-out” is started (value of the Response time-out is application dependant). It prevents the Master from staying indefinitely in “Waiting for reply” state.
When a reply is received, the Master checks the reply before starting the data processing.

The checking may result in an error, for example a reply from an unexpected slave, or an error in the received frame. In case of a reply received from an unexpected slave, the Response time-out is kept running. In case of an error detected on the frame, a retry may be performed (this kind of error is named “covered error”).

If no reply is received, the Response time-out expires, and an error is generated. Then the Master goes into “Idle” state, enabling a retry of the request. The maximum number of retries depends on the master set-up (these kind of error are named „uncovered errors“).
When a “broadcast request” is sent on the serial bus, no response is returned from the slaves.

Nevertheless the Master respects a delay in order to allow any slave to process the current request before sending a new one. This delay is called “Turnaround delay”. Therefore the master goes into “Waiting Turnaround delay” state before going back in “idle” state and before being able to send another request.

In “unicast requests” the Response time out must be set long enough for any slave to process the request and return the response, in broadcast the Turnaround delay must be long enough for any slave to process only the request and be able to receive a new one. Therefore the Turnaround delay should be shorter than the Response time-out. Typically the Response time-out is from 1s to several second at 9600 bps; and the Turnaround delay is from 100 ms to 200ms.
Frame error consists of:

  1. Parity checking applied to each character;
  2. Redundancy checking applied to the entire frame.

The state diagram is intentionally very simple. It does not take into account access to the line, message framing, or retry following transmission error, etc.

State Diagram for Slave MODBUS

 State Diagram for Slave MODBUS

The slave element is in idle stage until he doesn’t receive any request. This is the initial state after power-up. When a request is received, the slave checks the packet before performing the action requested in the packet.

Different errors may occur: format error in the request, invalid action. In case of error, a reply must be sent to the master. Once the required action has been completed, a unicast message requires that a reply must be formatted and sent to the master. If the slave detects an error in the received frame, no respond is returned to the master. MODBUS diagnostics counters are defined and should be managed by any slave in order to provide diagnostic information.

In figure 5.7 we show an example for control a coil element included in the network:

MODBUS Write Single Coil

Animation 5.8 MODBUS Write Single Coil

MODBUS is used to monitor and program devices; to communicate intelligent devices with sensors and instruments; to monitor field devices using PCs and HMIs; MODBUS is also an ideal protocol for RTU applications where wireless communication is required.

Finally we give in the figure 5.4 the structure of a program written on PC that implements the main functions of MODBUS protocol from client side.
In order to assure an efficient implementation of code for

each request is dedicated a class, derivate from base class CModebus that manage all the information transferred through MODBUS protocol. This class implement the MODBUS application layer.

The CMBTransport and CMBAsciiTransport are the classes that treat the link layer, respectively assure the implementation of transmission mode: RTU or ASCII. The CRS232Port class is used for the implementation of communication at the level of serial port from PC.

Structure of classes and derivative of them that implement MODBUS protocol, implemented on PC

 Structure of classes and derivative of them that implement MODBUS protocol, implemented on PC


Practical Stuff Part-3


About HART — Part 3


Part 3:  Ponderous Stuff

Equation Describes CPFSK

    The HART signal is described mathematically as

where V = signal voltage, t = time, Vo = amplitude, Theta_sub_0 is an arbitrary starting phase, and Theta(t) is given by

wpeC.gif (2098 bytes)

where Bn(t) is a pulse that exists from 0 < t < T and has a value of   1 or -1, according to whether the nth bit is a 0 or 1.  T is one bit time.   If phase is plotted versus time it is a steadily increasing value that increases with two possible slopes.

Generating HART Signal With MATLAB

    The following “M” file listing is a program for generating HART modulation with MATLAB [3.1].  This is useful for testing or simulation.  The program uses random input bits and generates square, trapezoidal, and sinusoidal outputs.  The output ranges from -1 to +1.  Figure 3.1 is an example of the output.  The curves have been separated for clarity.  The bottom curve is the modulating signal.

%   hartgen.m
%   Generates HART signals.
%   Stephen D. Anderson --- November 29, 1999.
%   Arrays are identified by a capital letter.
%   comment out the following statement to get a different set of
%   random bits each time program is run.
%   Generate a random bit stream.
    numb_bits = 200;
    Bits = round(rand(numb_bits,1));
%   Convert bits to levels of +/- 1.
    Xmit = 2*Bits - 1;
%   Generate bit boundary times.
    H_time = (0:(length(Xmit)-1))*(1/1200);
%   Set sample rate to 50 kHz.
    sample_time = 1/50e3;
%   Sample the transmit bits.
    for j=1:length(H_time);
        while ((i-1)*sample_time <= H_time(j));
            Sample(i) = Xmit(j);
            i = i + 1;
%   Generate the accumulated phase at each sample.
    Accum_phase = zeros(1:length(Sample));
    Phase = 2*pi*Sample*500*sample_time;
    accum = 0;
    for i=1:length(Phase);
        accum = accum + Phase(i);
        Accum_phase(i) = accum;
%   Generate a time record.
    Time = sample_time*(0:length(Phase)-1);
%   Generate the sinusoidal wave.
    Sinout = cos(2*pi*1700*Time + Accum_phase);
%   Generate the square wave.
    Squareout = sign(sign(Sinout)+0.1);
%   Generate the trapezoidal wave by convolving the square wave
%   with a pulse.
    pulse_length = 160e-6;      %  Use 80 usec ramp.
    pulse_length = round(pulse_length/sample_time); % need integer.
    Pulse = ones(1:pulse_length);
    Trapout = (conv(Pulse',Squareout))/pulse_length;
    Trapout = Trapout(1:length(Time));
%   Write to file.
    fid = fopen('out.dat','w');
    fprintf(fid, '%10.8f  %10.8f  %10.8f  %10.8f  %10.8f\n',...
    [Time; Sample; Squareout; Sinout; Trapout]);

wpe42.gif (7529 bytes)

Figure 3.1 — Example of HART Signal Generation


OSI Model

    Although HART can be adequately understood without resort to the OSI Model, some of the OSI terminology exists in HART Standards.  Therefore, a brief description of the relationship is given here.  A mapping of HART hardware to the Model is also attempted.

    The Open Systems Interconnection (OSI) Model [3.7] is a standard model for communication systems.  The intent of the OSI Model is to provide requirements for being “open.”  The model consists of 7 layers, which are either physical or abstract entities within the communicating system (device).  The layers, listed in order from highest to lowest are:

7.  Application
6.  Presentation
5.  Session
4.  Transport
3.  Network
2.  Data Link
1.  Physical

A given layer of one system (device) communicates with its counterpart in the other system (device).  A given layer generally knows (or can find out) the capabilities of the next lower layer; and may request services of this lower layer.  The Physical Layer, which is the lowest layer, connects to a medium, which serves all of the communicating systems.  Sending a message consists of a series of requests by each layer to the next lower layer, with appropriate protocol and addressing information being added at each level.  A request to a lower level or receipt of information from a lower level is called a PDU (Protocol Data Unit).  The next lower level that received the request or provided the information calls it an SDU (Service Data Unit).   Sometimes the terms PDU and SDU are preceded by an indicator of the layer.   For example, a DLPDU would be a PDU sent or received by the Data Link Layer.

    As defined by the OSI Model, conventional HART uses “connectionless” communication.  That is, connections are not established and removed (as with public telephone network) in order for communication to occur.

    In virtually all implementations of HART, the functions of layers 3 through 6 either don’t exist or are performed as a single activity by one computer or embedded microcontroller.  Consequently, conventional HART is usually said to implement only layers 1 (Physical), 2 (Data Link), and 7 (Application).

    In addition to interfacing (voltages, impedances, etc.) to the network cable, the HART Physical Layer performs 4 basic functions:

    1.  Modulating an outgoing message.

    2.  Demodulating an incoming message.

    3.  Turning on carrier for an outgoing message.

    4.  Detecting carrier for an incoming message.

    In the jargon of OSI a message transmission occurs like this:   the Application Layer gives a PDU (request) to the Data Link Layer.  This request contains the destination address and the data (including command number) to be sent.  To the Data Link Layer, this information is an SDU.  The Data Link Layer then creates its own PDU by adding a preamble, delimiter, source address, and error check bits and arranging them all in the proper order.  The Data Link Layer then performs three functions to send its message:

    1.    It makes a PDU to the Physical Layer to turn on carrier.

    2.    It makes a 2nd PDU, which is the data to be transmitted.

    3.    It makes a PDU  to turn off carrier.

A similar series of events takes place in a receiving device.  One of the first steps is the Data Link Layer making a PDU to the Physical Layer to listen for carrier.

    HART hardware can be roughly related to the OSI layers 1, 2, and 7 as in figure 3.2.

Figure 3.2 — HART Transmitter Showing Approximate OSI Boundaries

There isn’t necessarily any correspondence between a given OSI layer and some identifiable hardware or software.  For example, the UART is responsible for creating the bit stream — a physical layer function.  But, at the same time, it adds parity bits for error control — a Data Link Layer function.

     The OSI Standard:  In our opinion the OSI standard is unnecessarily complex and obscure.  Communication systems can be made “open” by publishing a Plain English description of how they work.  We guess that virtually every open system that references the OSI Standard also has such a description.
      The OSI Standard can be roughly summarized as stating that a given layer requests services of the layer below it and doesn’t know or care how the lower layer accomplishes this.  But, in fact, communication systems tend to be driven from the bottom up instead of the top down; because they are usually built around the properties and limitations of the physical layer.  As evidence of this, consider the Internet and how slow it is.  Here, the application is clearly being controlled by the physical layer.

HART Network Circuit Models

    HART networks can be modeled as lumped circuits.  Using these models it is possible to predict the amount of attenuation and distortion that will occur in transmitting from one of the networked devices to another.  A progression of models is presented here, with some comparisons of different models and comparisons between simulated models and measurements.

    Every device connected to a HART network may be considered a lumped RLC (resistor, inductor, capacitor) circuit, with varying impedance over the HART signal band of 950 Hz to 2500 Hz.  Most devices don’t present any appreciable inductance or else the inductance is large enough that it appears to be an open circuit compared to impedance in parallel with it.  Consequently, the inductance can be removed from the model and a given device can nearly always be considered an RC (resistor, capacitor) combination.

    Cable is characterized by its R, C, L, and G (conductance) per unit length.  But, at HART frequencies and under the circumstances used in HART, only the R and C have a significant effect.  Thus, the cable can be modeled as a chain of RC sections.  One of these sections for a multi-pair cable is shown in figure 3.3.   In the figure R is the resistance of a conductor.  CXY is the capacitance from conductor X to conductor Y.  There will be a C for every combination of two conductors.  HART frequencies are low enough that skin effect may be neglected.   Thus R and C are often available as cable specifications or are based on DC or low-frequency (about 1 kHz) measurements.  R can also be determined from conductor diameter (gauge).  Increasing the number of sections increases the model accuracy.

Figure 3.3 — Cable Section Model

    A typical situation is a group of point-to-point networks, each using a pair of a multi-pair cable.  A case that has been studied quite a bit is a 4-pair #24 gauge cable with overall shield.  This cable is characterized by 3 different capacitance values per unit length, as listed in table 3.1.

Conductor Combination Capacitance per 1000 ft.
Conductor in one pair to conductor in same pair 9.90 nF
Conductor in one pair to conductor in another pair 1.97 nF
Any conductor to shield 27.04 nF

Table 3.1 — Cable Capacitances

A model of 4 point-to-point networks using this cable is given in figure 3.4, for the case where one of the Field Instruments is talking to its respective Master.  Each cable section is modeled as in figure 3.3.  Each of the Masters at the Controller end is modeled as a single resistor, Rm.  Each of the pairs at the Controller end has a common connection with the shield.  At the Field Instrument end the Field Instruments are all high-impedance devices and are modeled as open circuits.  The one talking Field Instrument is modeled as a current source.

Figure 3.4 — 4-Pair Circuit Model

SPICE simulations were used to find the voltage magnitude and phase at both ends of the driven pair.  The SPICE simulations used 5 sections of cable of length 1000 ft. per section.  The resistance of a cable conductor per 1000 ft. section is 26 ohm.   Rm was set to 100 ohm, 200 ohm, 500 ohm, and 1000 ohm.  If = current = 0.6 mA.

    The SPICE simulation results are not too remarkable except as a reference for a much simpler analytical approach.  Suppose that the model above is replaced by that of figure 3.5.  The simple model ignores cable resistance.  It also combines all of the various cable capacitances into one.  This single capacitance, the mutual capacitance, is what we would measure between the two conductors of any pair.  For the 4-pair cable used in the simulation the mutual capacitance is 48.6 pf/ft.

Figure 3.5 — Simple Model

The simple model is seen to be just a single-pole lowpass filter.   The output voltage is easily determined.  A comparison between the simple model voltage and the SPICE model voltage is given in table 3.2.  There is relatively good agreement, which suggests that the simple model is probably sufficient for most analyses of HART signaling.

Rm (ohm) Frequency (Hz) SPICE magnitude Simple magnitude SPICE phase Simple phase
100 900 0.0588 volt 0.0594 -13 degree -8
100 3193 0.0493 0.0539 -40 -26
200 900 0.1137 0.116 -20 -15
200 3193 0.0779 0.0859 -55 -44
500 900 0.2400 0.247 -38 -35
500 3193 0.1076 0.114 -75 -68
1000 900 0.3429 0.353 -56 -54
1000 3193 0.1179 0.121 -85 -78

Table 3.2 — Comparison Between SPICE Model and Simple Model

    In the above models, when the Master is transmitting to the Field Instrument, Rm is short-circuited by an ideal voltage source and the current source at the Field Instrument end is removed.  This results in even less attenuation and phase shift.  Thus, the situation analyzed is a worst-case.

    When a resistor-zener IS barrier is used, this places a resistance between Rm and the cable.  When the Field Instrument is talking, Rm just appears to be larger.  And the actual Rm forms a voltage divider with the barrier resistance.   When the Master is talking, the barrier resistance forms a single-pole lowpass filter with the cable capacitance. 

    Measurements were also made on a 1000 ft. section of the 4-pair cable.  A comparison of measured and calculated output voltage for the 4-pair cable with Field Instrument transmitting to Master is given in table 3.3.  The simple model was used for the calculations.  The current source was simulated by using a signal generator in series with 20 kohm.  The table shows very good agreement.

Rm (ohm) Frequency (Hz) Calc. magnitude Meas. magnitude Calc. phase Meas. phase
250 500 12.3 mV 12.3 -2 degree -2
250 1000 12.3 12.3 -4 -4
250 2000 12.2 12.3 -9 -8
250 5000 11.5 11.7 -21 -18
500 1000 24.0 23.9 -9 -7
500 2000 23.3 23.3 -17 -15
500 5000 19.3 20.1 -37 -32
1000 1000 45.4 44.9 -17 -14
1000 2000 40.5 41.1 -31 -27
1000 5000 26.0 28.7 -57 -50

Table 3.3 — Comparison of Measured and Calculated Output Voltage

    These results were used to set an upper limit for the product of Rm and C in an early draft of the HART Physical Layer specification.  The limit is 65 microsecond.  Later, however, there arose a need to use relatively low resistance values.  The simple model ignores the fact that, as Rm becomes small, the effect of cable resistance and other series resistances becomes greater and can eventually dominate the circuit behavior.  There is also a need to allow parallel resistance to be distributed among networked devices.  A reference voltage for deciding the presence or absence of carrier was also established and required more careful determination of various sources of attenuation.  Consequently, the simple model became inadequate and has been replaced by those of figure 3.6.

Figure 3.6 — Newer Network Circuit Models

The elements of figure 3.6 are as follows:

        Rp = combined parallel resistance of all devices.
        Rs = combined series resistance.
        Rsm = secondary master resistance.
        C = lumped parallel capacitance of devices and cable.
        If = Current source to model high-Z signaling device.
        Vin = Voltage source to model low-Z signaling device.

These models are still relatively simple and their elements have been arranged to produce a worst-case Vout. 

    The newer models of figure 3.6 have been used to generate a chart of acceptable capacitance versus Rp and Rs.  This chart (figure 17 of the Physical Layer Specification)  replaces the 65 microsecond rule for determining acceptable combinations of resistance and capacitance.  The chart shows that capacitance is maximized for Rp of about 240 to 250 ohm.  The chart applies to networks that have either process receivers or process transmitters or both.

HART Signal Power Spectral Density

    The power spectral density (psd) of a signal is often of interest, since it defines which frequency components are most important.   The psd tells us what we need in the way of frequency response of the communication channel, and whether there are any discrete spectral lines that might be used for synchronization.  It is also used to compare different modulation methods.  An expression for the psd of continuous phase FSK under conditions used in HART is [3.3]

wpe35.gif (2067 bytes)

where w1 = the lower shift frequency, w2 = upper shift frequency, A = amplitude, T = bit time,

wpe3A.gif (1895 bytes),    wpe3B.gif (1902 bytes) ,

wpe40.gif (1397 bytes),

  wpe3F.gif (1402 bytes) ,

wpe38.gif (1119 bytes),     and    wpe39.gif (1110 bytes).

The resulting power spectrum (in dB) is indicated in figure 3.7.     The amplitude has been deliberately adjusted so that the peaks of the main lobe are at about 0 dB.  The measured power spectrum is shown in figure 3.8, for comparison.

Figure 3.7 — HART Power Spectrum


Figure 3.8 — Measured HART Power Spectrum

The spectra show that there are no spectral lines.  (This is also evident from the equation, which would otherwise contain one or more delta functions.)  The power spectrum is symmetrical around 1700 Hz and has a peaks at about 1.1 kHz and 2.3 kHz — close to, but not at the shift frequencies.  The main lobe extends from about 1 kHz to 2.4 kHz.   The secondary lobes at 800 Hz and 2.6 kHz are about 20 dB below (100 times less power) than the main lobe peaks.  Since the main lobe contains nearly all of the signal power, the psd is sometimes said to extend from 1 kHz to 2.4 kHz.  Or, if we add a little margin to this as is done in some HART documents, it extends from about 900 Hz to 2.5 kHz.

    Note that these are spectra for random bits.  Any non-random features of HART data will alter the spectrum.  Since, HART data is transmitted as characters containing start and stop bits, this is one non-random feature.   The frequency of occurrence of a start (or stop) bit is 109 Hz.  Therefore, evidence of the 109 Hz should show up in the spectrum.  A simulation in which bits are random except that every 10th bit is set to zero and every 11th bit is set to 1 results in the power spectrum of figure 3.9.

Figure 3.9 — HART PSD With and Without StartStop Bits

The figure contains two plots.  One is the normal (completely random) spectrum.  The plots are artificially separated by 5 dB so that they are more easily observed.  The spectrum with start and stop bits shows a repeated pattern at intervals of 109 Hz.  From a circuit design or communications perspective the differences are insignificant.

    Another alteration of the spectrum is expected if we use a trapezoidally shaped transmit waveform instead of sinusoidal.  A trapezoid shape is often easier to generate that a sine wave and is commonly used.  The simulated spectra for sinusoidally (normal) and trapezoidally shaped HART signals are given in figure 3.10.

Figure 3.10 — HART PSD With Sinusoidal and Trapezoidal Shaping

The risetime for the trapezoidal shape used is a constant 177 microsecond from full negative amplitude to full positive amplitude.  The trapezoidal shaping tends to emphasize the low-frequency end of the power spectrum slightly.  In the region of the main lobe (1 kHz to 2.4 kHz), however, there isn’t much difference between the sinusoidal and trapezoidal spectra.

Cable Effects     

    HART frequency components exist primarily in a band from 900 Hz to 2500 Hz.  The wavelength corresponding to 2500 Hz is about 75 miles (120 km).   Even if we assume that distributed cable effects start to occur at 1/20 of a wavelength, this is still 3.8 miles.  Except in some special situations, this is far longer than the distance between most measurement/control points and the process control room.  Consequently, HART networks don’t act like transmission lines and can be modeled as collections of lumped elements.  From the user’s viewpoint, building a network of HART devices is virtually the same as building a network of analog-only devices.  There are no terminators or special cable.  The one possible problem is cable capacitance.

    The cable capacitance (device capacitance also contributes) forms a single-pole filter with the network resistance.    For long cable lengths (high capacitance) the filter cut-off can be close to 2500 Hz.  The result is that the signal can become distorted.  Since the network resistance is usually the current sense resistance, a lower current sense resistance helps to broadband the filter response.  However, there is a lower limit to this resistance.  HART specifications attempt to control the resistance and capacitance to limit distortion.   Practical cable lengths range up to about 4000 ft. (1200 meter).  Figure 3.11 below shows acceptable cable lengths for a variety of conditions, including different amounts of cable capacitance per unit length and varying numbers of Field Instruments.  Field Instruments are assumed to have 5000 pf of capacitance each.   (Note that this figure ignores series resistance, and that a newer, more accurate chart of acceptable capacitance versus series resistance and parallel resistance is now specified in HART documents.  See section entitled   HART Network Circuit Models  .)

Figure 3.11 —  HART Cable Length

    Instead of trying to insure that the -3 dB network corner frequency stays above 2.5 kHz by limiting cable lengths, another approach would have been to let it go below 2.5 kHz and correct for the pole using equalization.   However, since the pole frequency varies, adaptive equalization is needed.   Adaptive equalization is a relatively complex procedure and usually requires a long training period.  This training period is incompatible with the burst-type operation that HART uses.  A compromise equalizer is also possible.  This is a fixed equalizer that attempts to provide correction at a frequency midway between the extremes of possible pole frequencies.  This doesn’t need adaptation.  But it does complicate the modem.  Currently, we are not aware of any HART modems that try to extend cable lengths by using equalization.  The accepted method is either to use a repeater or else to use an alternate network, such as one of those described in the section entitled  HART Bridges and Alternative Networks.

    Another type of problem related to cable is crosstalk.   Crosstalk arises when a given multi-pair home-run cable contains several HART current loops (several networks).   The capacitance from one twisted-pair to another, along with the imbalance (single-ended connections) in HART networks causes unusually large crosstalk.   Balancing has never been an option in HART because of a desire to continue existing wiring practice.  The mechanism of crosstalk is illustrated in figure 3.12.  The figure shows two current loops and a signal path from a Field Instrument (F1) back to the wrong Master (Master 2).

Figure 3.12 — Crosstalk Path in Multi-Pair Cable

    In the early days of HART, crosstalk would sometimes program an unintended Field Instrument on an adjacent current loop.  This was corrected primarily through creation of more complex addressing in which a 38-bit address was added to the existing 4-bit address.  After this change, crosstalk was unlikely to mis-configure a Field Instrument.  But it could still cause bit errors when appearing as noise in the desired signal.  It was also a nuisance for a receiving device forced to listen to a message coming from another network.   These crosstalk effects have so far been mitigated through each of the following:

        1.    The choice of modulation and bit rate are such that the highest frequency
               component that needs to be transmitted is about 2500 Hz.  Higher frequency
               components are removed by requiring transmitted signals to have a slow risetime.

        2.    Transmit signal levels have been adjusted in various devices to make it difficult for
               one signal to overpower another.

        3.    An amplitude-based carrier detect is prescribed.  The signal must be above a
               minimum level before the associated message is considered valid by the

        4.    If there is a common ground among two or more networks, it must be located
                at the Controller (Master).  It is not permitted in the field area.

        5.    Various investigations of crosstalk have shown that the worst type is Master-to-Master.
                It occurs when one Master is talking on its respective network and another Master
                is trying to listen on an adjacent network.  The listening Master receives not only the
                desired transmission from a Field Instrument, but also some of the transmission from
                the talking Master.  Therefore, whenever possible, Masters connected to adjacent
                pairs should stagger their transactions so that messages don’t overlap.  The nature of
                HART is such that this is usually the case anyway.
    Studies of HART crosstalk have usually been done by dividing the cable into many small sections and using SPICE simulation on the resulting lumped circuits.   Agreement with measurement is usually good.

    Non-HART devices can also interfere with HART through the same crosstalk mechanism described here.  End-users and installers of HART should be careful about how they allocate the pairs in a multi-pair cable.  Especially troublesome are pairs that are used for any kind of ON-OFF or binary signaling (switches or relays) or supplying power to heavy loads in the field area.  Communication methods such as Honeywell DE that involve very large signal excursions are also a possible source of trouble.  We suspect that, in many cases where interference exists, the interference source remains dormant (OFF or in some unchanging state) for a long enough time that a HART transaction can be completed.  Thus, acceptable operation is still possible.

HART Message Errors

   All data communication systems, including HART, are subject to bit errors caused by noise and signal distortion.  The rules for constructing HART networks attempt to minimize signal distortion.  And most receive circuits include a bandpass filter to limit noise power.  Still, these measures only reduce the likelihood of bit errors and don’t eliminate them.

    In HART, if one or more bits are wrong, then the whole message is considered bad.  The Master-Slave nature of the HART Protocol means that Masters and Slaves behave differently in response to a bad message.  Normally a Master sends a command to a Slave and expects a reply from the Slave.  If a Master receives a bad message or no message, it must usually re-transmit its command to the Slave.  If a Slave receives a bad message, it must not act on this message.  But, depending on circumstances, it may still send back a reply.  The criterion to reply to a bad message is usually that everything appeared correct up to and including the command byte.   The reply includes a status bit indicating that the message was bad.

    HART uses vertical and longitudinal parity to catch bad bits.   Longitudinal parity is the exclusive OR of the 8 bits in each transmitted byte.   Vertical parity is a checksum byte that becomes the last byte of the message.     This form of error detection was chosen for HART because it is easily implemented in a smart process transmitter without special hardware.  The longitudinal parity is just the odd parity that is available in most UART implementations, including UARTs built into popular microcontrollers.  In most device implementations, the longitudinal parity is generated and checked automatically as part of the UART operation.  The checksum byte is generated and checked in software by exclusive ORing full bytes as they are transmitted or received.

    An error detection scheme can be fooled into thinking that a message is good when it isn’t or bad when it isn’t.  A bad message that appears good is an undetected message error or UME.  A UME is the cardinal sin of data communication.   Most communication schemes try to make it a very rare occurrence.  Numbers like once in 20 years are not uncommon.  A UME usually results from a few combinations of bit errors that are transparent to the detection scheme.  For example, suppose we look at just the longitudinal parity alone.  This is a relatively unsophisticated error detection scheme.  Any even number of bit errors in a given byte will fool the parity checker.

    For purposes of examining error detection, the full HART message may be thought of as a matrix of bits.  The matrix consists of 9 columns and N rows, where N is dependent on the size of the message.  Each row corresponds to one byte or character, including the longitudinal (UART) parity bit.  The Nth row is the checksum byte and its longitudinal parity bit.  This is illustrated in figure 3.13

Row 1 D D D D D D D D P
Row 2 D D D D D D D D P
Row N-1 D D D D D D D D P
Row N C C C C C C C C P

D = message bit, P = long. parity bit, C = checksum bit.

Figure 3.13 — HART Message as Bit Matrix

Each bit P in figure 3.13 is the exclusive OR of the 8 bits in its row.  And each bit C is the exclusive OR of all of the bits D in the column above it.  We see that, for this scheme to be fooled, we must have at least 4 bit errors and they must be located at the vertices of a rectangle.  An example is that of figure 3.14.

Row 1 D D D D D D D D P
Row 2 D E D D D D E D P
Row N-1 D E D D D D E D P
Row N C C C C C C C C P

E = bit that is in error.

Figure 3.14 — Bit Matrix That Will Cause UME

It is apparent that this is a much more sophisticated detection scheme than either longitudinal parity or vertical parity alone, because there must be more bad bits and they must be strategically located.

    A measure of how well the error detection scheme works is the frequency of UMEs or the probability of a UME.  The probability of UME depends on the probability of 4 bit errors and the probability that they are arranged to form a rectangle.  Clearly, there could also be 2 rectangles formed from 8 bad bits, or 3 rectangles, etc.  But, given that the probability of a bad bit is small, these multiple rectangle situations are improbable compared to a single rectangle and need not be included.  Then the probability of UME is approximately given by

where P1 is the probability that any two bits in any row will be in error, P2 is the probability that one of the corresponding column bits will be in error, P3 is the probability that the remaining row/column bit will be in error.  Let Pb be the probability of a bit error and N the number of rows (= number of message bytes).   Then

Then Pume becomes

As an example, suppose a message of 30 bytes, and Pb = 0.001.  Then Pume = 65e-9.  A 30 byte message takes 0.275 second.  So there can be only 3.6 of them per second.  Then the number of UME per year, with continuous signaling, is 7.5.   Most applications don’t require continuous communication.  Therefore, the UME rate is much less.  A Pb of 0.001 or less has generally been considered satisfactory.

    Another dimension to this problem is that there is actually more error detection occurring than is implied by just the parity and checksum.  Most HART software checks delimiters, addresses, status, commands, sizes of data fields, units, limits on process variable numbers, etc.  This adds another layer of relatively exhaustive error checking.  If we are even moderately satisfied with a UME rate based on parity and checksum alone, we should be entirely satisfied by the additional error checking.

    The bit error rate is a function of (energy per bit)/(noise density) = (Eb/No).  The relationship given in Proakis [3.4], is

This applies to orthogonal FSK, in which one shift frequency is an integer multiple of the other.  The FSK used in HART is not quite orthogonal (ratio of frequencies is 2200/1200 = 1.833), but is close enough that a more complex relationship is probably not warranted. 

    The above equation for Pb is based on a “bandwidth” that is the reciprocal of the bit rate.  It is generally found, however, that a bandwidth of at least twice the bit rate is desired for FSK.   Shanmuggam [3.5] uses this wider bandwidth and comes up with what is probably a better expression for Pb.  It is

where A = peak signal, T = bit time.  To get Pb = 0.001 requires (Eb/No) = 24.9.  Let S be the signal power.  Then Eb = ST = S/1200/second.  Then

The ratio of RMS signal voltage to voltage noise density is

The minimum received signal is generally thought to be about 130 mV p-p or 46 mV rms.  Then, for ideal reception, we can have Vn as high as 266 microvolt/(root Hz).  In a 9500 Hz bandwidth (HART Extended Band), the noise must be limited to about 26.1 mV RMS.  For Pb = 0.0001, the acceptable noise drops to 22.3 mV RMS.

    Simple HART receivers often do not limit received noise to a bandwidth of 2x bit rate.  The receive filter is often a single-pole lowpass with corner frequency in the range of 5 to 10 kHz.  A more general expression for Pb, that includes noise bandwidth, is

For a 10 kHz single-pole lowpass, B = 1.57(10 kHz) = 15.7 kHz.  And BT = 13.1.  To get Pb = 0.001 now requires (Eb/No) = 163 and

Using Vs = 46 mV RMS results in Vn = 104 microvolt/root Hz.  In the HART Extended Band the noise must be limited to 10.1 mV.

    Noise can come from “silent” HART devices and from external sources.  HART specifications require that devices produce no more than 2.2 mV RMS of noise in a 9500 Hz band.  For 17 devices, all producing this much noise, the noise would be 9.1 mV RMS.  Since this is below the 10.1 mV limit found above, this noise level is acceptable. 

    Information collected by Rosemount [3.6] suggests that induced (from DCS) noise densities can reach 174 microvolt/root Hz.   For the simple receiver using a 10 kHz receive filter, this corresponds to Pb of 0.314.  This would cause a large UME rate and wouldn’t work very well.  It suggests that such a large noise level is probably not often encountered or that it is not often encountered along with a minimum HART signal level.

    Another factor related to Pb that is not considered is that HART modems sometimes have a degree of built-in noise rejection in the form of logic circuits that will reject unusually short or unusually long intervals between zero crossings of the received signal.  That is, the demodulator is somewhat of a correlation receiver.  In effect, this reduces the noise bandwidth and improves Pb.

    If noise from silent devices is correlated (i.e., interference at one or more frequencies rather than random noise) then it is possible that combined devices could produce 2.2 mV RMS x 17 = 37.4 mV RMS.  However, this would require the interference sources to have the same frequency and phase.  This is very unlikely.

    Note that the UME number found earlier doesn’t say anything about the frequency of detected message errors.  If there are too many, software may flag this situation and declare that a device has malfunctioned.  Therefore, a “practical” error criterion is desired and has been proposed [3.7]:  If there are X consecutive message errors, this is considered a system failure (even though there is no UME).  And such failures must be limited in how often they occur.   For a given rate of occurrence, the required Pb will be derived. 

    Again, let the message length be N and assume that messages occur continuously.  The probability that a message is in error is given by the well known expression

where Nb = number of bits = 11*N.  Pb in terms of Pm is then

where Y = 1/Nb.

    The frequency criterion may be stated that there must be, on average, only one failure per time T; or that the probability of a failure is 1 if there are fT messages, where f is the frequency of messages.  The time of one message is Nb*(1 second)/1200.  Then f = 1200/(Nb second).  The probability that there are exactly X consecutive messages in error out of a total of fT depends on the number of ways that the X erroneous message can occur.  If fT is far larger than X, then the approximate number of ways is just fT.  That is, any message could be the start of the string of message errors.  There could also be X+1 consecutive errors and X+2, and so on.  But if the probability of a message being in error is small, then only the case of exactly X messages need be included.  The probability of X consecutive errors becomes


Setting Px = 1 gives

Substituting this into the above equation for Pb gives

    As an example, suppose that a Slave Device is in burst mode and repeatedly sending a single process variable.  Suppose that the Master receiving the information has been programmed to flag an operator  if there are 4 consecutive message errors.  Assume that 20 bytes per message are sent; and that the operator is to be flagged no more than once a week.  Then we have X = 4 and Nb = 11*20 = 220.  Continuous transmission implies that there are about 5 messages per second.  However, the protocol requires a delay between messages, so that a practical value is probably 3 per second.  Then f = 3/second, T = 1 week, and fT = 1.81e6 = messages/week.  Y = 1/Nb = 1/220 = 4.55e-3.  Then Pb = 0.00013.  We found earlier that we only needed Pb = 0.001 to get 7.5 UME per year.   This new condition will occur once a week, even at Pb = 0.00013.  Thus, the new error criterion is much more stringent than that for UME.

Experimental HART Error Rates

    In many communication systems there are multiple sources of crosstalk because multiple pairs of the same cable are all being used simultaneously.   A somewhat more realistic situation for HART is probably one in which there is only about one source of crosstalk.  This situation was examined experimentally.  The bit error rate for a typical HART modem was measured as a function of combined noise and crosstalk.  Instead of generating actual crosstalk on a multi-pair cable, the crosstalk, signal, and noise were combined in an opamp summer.   And, instead of an actual HART signal for the crosstalk, a sine wave at a frequency of 2.2 kHz was used.   The random noise is band-limited white noise limited to a 50 kHz band.  The result is plotted in figure 3.15.  To generate the “Signal-to-RMS …” axis, the noise and crosstalk are summed together in RMS fashion.  There are 11 curves ranging from all crosstalk (no noise) to no crosstalk.  S/C means signal-to-crosstalk.

Figure 3.15 — Plot of BER v. (Noise + Crosstalk)

    The figure shows some curious results.  One is that at higher levels of crosstalk (low S/C) the BER curves are almost vertical.  That is, the BER varies over many decades while the crosstalk power varies only about one dB or less.  This is almost a threshold effect.  Below the threshold there are no errors.  Above it there are many.  Another feature of the graph is that there are roughly 5 curves that are above the “no crosstalk” curve.  This means that some combinations of noise and crosstalk are worse (cause more errors) then either noise or crosstalk alone, even though the amount of interfering (noise + crosstalk) power remains constant.


How Fast?

    One interesting question is how fast could the HART Physical Layer be, given the existing constraints of signal size, bandwidth, and noise?   The Shannon-Hartley Theorem [3.4, 3.5] gives the channel capacity as

where C is the capacity in bits/second, B is bandwidth, and S/N is the signal-to-noise ratio.  There are no communication systems that actually operate at capacity.  The capacity limit is only useful in the sense that, as long as we don’t exceed it, the error rate can be made arbitrarily small.

    To calculate the capacity, assume that the maximum noise produced by a given device is 2.2 mV RMS in a 10 kHz band; and that this is measured across a 500 test load.  If there are 17 such devices, all producing the same amount of noise, then the total is 9.1 mV RMS.   The noise density is then 91 microvolt/root Hz.   Assume that the bandwidth is 3 kHz, then N = 5.0 mV RMS.  The minimum signal is probably 260 mV p-p at a test load of 500 ohm.  Then S = 92 mV RMS, S/N = 18, and C =  13 kbits/second.  If the bandwidth is taken to be 4 kHz, which seems reasonable under some circumstances, then C becomes 16 kbits/second.

Pracatical Stuff Part-2


Practical HART — Part 2


Part 2:  Practical Stuff

A Caveat:  HART and Current Consumption

    Adding HART to an analog 2-wire transmitter eats into the available current in two ways.  First, there is the current consumed by HART functions.  And, second, there is less current to start with because of the superposition of the HART signal.  If the analog output is 4 mA, then the instantaneous output during HART transmission can typically drop to 3.5 mA.   This often means that there is only 3.5 mA available to power circuitry.   Alarm conditions and guard bands can further erode this number, as illustrated in figure 2.1.   Energy storage methods can prevent the loss of 0.5 mA, but might be unsatisfactory in an intrinsically safe device.

wpe35.gif (5419 bytes)

Figure 2.1 — Available Operating Current With HART

Modem Sources

    When people talk about modems, it’s not always clear whether they mean an integrated circuit that can be designed into their product or a completed, network-ready unit (HART Master).  For information on HART modems of either type, see    Romilly Bowden.    The HART Communication Foundation is another source of information.  For just the integrated circuits, you might also want to check out our paper entitled   HART Chips:  Past, Present, Future.


HART Library Software For PC

    HART Device Drivers are available from   Borst Automation   .  This allows you to put buttons, etc. on your screen that read and write HART parameters, put them into spreadsheets, etc.  Also, see the section entitled   HART and PCs   .


HART and PCs

    The combination of a Personal Computer and Serial Port HART Modem is often used as a HART Master.  In the days of DOS this was easier because you could write software that would take over the whole computer and generate the proper timing.  Nowadays it isn’t so easy.  The very enhancements, namely Windows and buffered UARTs, that make PCs more useful for other applications have made them less useful for HART.  Windows 95 and 98 have no provision for real time activities, and delays of 20 to 100’s of milliseconds are reported [2.1].  Windows NT has provision for “Real-time Threads”.  But experiment shows [2.2] that it can still devote 100% of CPU time to a task and ignore I/O events completely.  Since one character time in HART is 9.2 millisecond, the delays involved can be several character times.  This is enough to destroy HART Master arbitration.  So-called RTOS extensions to Windows NT are available, that can make Windows NT appear to be more of a real-time operating system.  But this is extra software to buy, install, and understand.  Worse yet, the HART application software may depend on whose RTOS is being used, so that it becomes tied to the RTOS instead of the PC.

    In some applications, where it is known that there will be only one HART Master and where HART burst-mode is not used, a Windows-based PC and simple Modem can still be used.  The only timing consideration is how long to wait for a Slave to reply.  Such applications don’t follow HART Specifications and don’t allow Master arbitration.  Nevertheless, they are useful and probably represent a fairly large subset of HART software.  You can download source code (in C) that works in this manner and does a lot of general HART activities, such as extracting device information, calibration, etc.  It runs in a DOS window under Windows.  Click   here   to download.

    To address the real-time requirements of HART, some systems put another processor between the PC and the Modem.  This can take the form of either a single-board-computer or an embedded microcontroller that is part of the Modem.  The single-board-computer or embedded controller forms a buffer between the Modem and the PC and takes care of all of the HART timing.

    A recently introduced integrated circuit, the “P51”, from Cybernetic Micro Systems, Inc. addresses the timing problems of PCs.  It appears to have almost everything you need to make a full HART modem that plugs into a PC’s ISA bus.   It is based on an 8051 and contains a complete interface to a PC or PC104 bus, including dual-port RAM and interrupts.  In this case the 8051 does the HART communication and provides the timing.

    Even a newer computer running DOS won’t always perform as expected, because of the way that the UARTs work.  Most modern UARTs in PCs are usually equipped with built-in FIFOs, to avoid frequent interrupts of the CPU.  This is a swell idea, except that the UART doesn’t put error information into a FIFO.  If there is an error, such as a parity error, there is no way of knowing which byte in the FIFO had the parity error (or whether more than one byte was in error).  Consequently, there is no way of weeding out the initial HART preamble bytes that are in error because of carrier start-up.  (See the section entitled Start-Up Synchronization in HART for details.)  Fortunately, the UART can often be programmed so that the FIFO is disabled, allowing you to associate error status with each data byte.

    Commercially available software packages and libraries for data communication are another source of trouble for the would-be HART Master.  Most of them are geared toward telecom modems and have no concept of burst modems.  They invariably turn on RTS (request-to-send) and assume it should be ON forever.  (HART Modems require RTS to be on only during transmit.)  They also are good at losing error status, just like FIFOed UARTs.  They let you set up a receive buffer, for example.  But they don’t let you set up a corresponding buffer of error status.   You receive a notice telling you there’s a HART message in the buffer, and another notice saying that some of the bytes are in error.  But you don’t get to know which ones are in error.  Finally, one other nasty thing the software package will do is to make sure that your UART FIFO is turned ON.

    Another UART caveat is that if you read a PC-based UART status, the status is automatically cleared.  If you need to use the status word more than once, make sure that you store it after the first read.

Timing is Everything

    HART allows two Masters.  Arbitration is used to determine which one will use the network.  The arbitration is based on monitoring of network traffic and implementation of timers.  A Master that is aware of what has recently transpired is said to be synchronized.  An unsynchronized Master is one that has either lost synchronization or has recently been connected to the network and has yet to become synchronized.  Loss of synchronization occurs if the processor in the Master must temporarily stop monitoring network traffic to do other things, or if there is no network traffic, or if there are message errors that prevent it from knowing what’s happening.

    If two Masters are present and both are synchronized, then they will use the network alternately.  This assumes, of course, that both have something to say.  If one of them doesn’t it can give up its turn but still remain synchronized.   This is illustrated in figure 2.2.  The Slave Response in each case may be from a different Slave.

wpe38.gif (9509 bytes)

Figure 2.2 — Master Alternation

During this process a given Master knows that it is free to use the network when it sees the end of the Slave response to the other Master.  If a Master doesn’t take its turn, the other Master can have another turn, provided it waits a length of time called RT2.  The time interval RT2 is illustrated in figure 2.2.  The Master whose turn it is to use the network has this much time in which to start.  Otherwise the Master that last used the network may start.  This is how things role merrily along when there are no problems and when both Masters have almost continuous business to transact.   Although not explicitly shown in figure 2.2 and subsequent figures, both Masters start their timers at the end of any network activity.  Any fresh activity cancels the timers.  Also, it is implicit in these explanations that a Master will not begin talking if someone else is talking.

    Now suppose that, as a result of a message error, a Slave doesn’t respond to Master 1.  Master 2 must now wait a length of time called RT1 before it tries to use the network.  Master 1, while waiting for the Slave response, sees the Master 2 command instead.  It then waits until Master 2 is done and then it can retry.  This is illustrated in figure 2.3.

wpe39.gif (4991 bytes)

Figure 2.3 — Master Alternation with No Slave Response to Master 1

Here, Master 2 has lost synchronization because it did not see a Slave Response to Master 1.  It regains synchronization at the end of RT1.

    Suppose, in figure 2.3, that the Slave finally did respond to the Master 1 command before the end of RT1.  Then things would have proceeded normally.   RT1, which is longer than RT2, is approximately the length of time that a Slave is allowed to respond.  Actually, the Slave maximum response time, which is designated TT0, is slightly shorter than RT1.  This ensures that a Master and Slave will not start transmitting simultaneously.

    If a Master is new to the network, then it must wait a length of time RT1 before it tries to use the network.  At the end of RT1 it has become synchronized and may use the network.  Or else, if it sees and recognizes a transaction of the other Master before RT1, then it is immediately synchronized.

    In another scenario suppose that a Slave has responded to Master 1, but the response appeared garbled to Master 2.  Figure 2.4 shows what happens.

wpe3A.gif (4909 bytes)

Figure 2.4 — Alternating Masters with Master 2 Failing to Recognize Slave Response to Master 1

Since Master 2 didn’t see a good Slave Response, it begins waiting a length of time RT1 from the end of the Slave Response.  Master 1, which saw a good Slave Response and is still synchronized, starts RT2.  At the end of RT2, Master 1 sees that Master 2 isn’t using the network and decides to use it again.  Master 2 sees this new transmission by Master 1 and becomes resynchronized.  Had Master 1 not wanted to re-use the network again, then Master 2 would have become resynchronized at the end of RT1 and could have begun its transaction then.

    If neither of the Masters needs to talk, the two Masters become unsynchronized.  In effect, either Master knows it has waited a time RT1 and can begin again whenever it needs to.

    Suppose that both Masters are new to the network or are both unsynchronized and try to use the network at the same time (after waiting for RT1).  The respective commands will be garbled and there will be no response.  Both Masters will start RT1 again at about the same time.  And both will collide again at the end of RT1.  To prevent this from going on endlessly, the Primary and Secondary Masters have different values for RT1.  The Primary Master uses a value designated RT1(0).   The Secondary Master uses a value designated RT1(1).

    How do things work if there is a Slave in burst-mode?   Arbitration is simple if there is a Slave in burst-mode.  To see this, recall that the bursting Slave will be the only Slave on the network.  Following each burst it must wait a short time to allow a Master to use the network.  The Protocol requires that the bursting Slave alternate information in its bursts, making it appear that alternate bursts are Responses to alternate Masters.  Masters watching the network will see a burst that is a Response to Master 1, followed by a burst that is a Response to Master 2, followed by a burst that is a Response to Master 1, and so on.   A given Master knows it can use the network following a burst that is a Response to its opposite.  That is, if a given burst was a response to Master 2, then Master 1 knows that it may use the network at completion of the burst.  In this strange turn of events, the Slave gets to decide who is next.

    Values of the timers are given in table 2.1.

Timer Description Symbol Value (character times)
Master Wait Before Re-Using Network RT2 8
Primary Master Wait from Unsynched RT1(0) 33
Secondary Master Wait from Unsynched RT1(1) 41
Slave Max time to Respond TT0 28
Slave Time Between Bursts BT 8

Table 2.1 — Timer Values

TT0, the length of time in which a Slave must respond, is deliberately made quite large to accommodate less capable hardware and software that is likely to be found in a Slave.  RT1(0), in turn, has to be larger than TT0.  And RT1(1) has to be larger than RT1(0).    The various timer values have been carefully set to account for various hardware and software latencies.   It would probably have been possible to omit RT2 and just force Masters to resynchronize (using RT1) after every Master or Slave Response.  However, since RT2 is much smaller than RT1, the existence of an RT2 allows much faster arbitration.


The Beginning, End, Gaps, and Dribbles

    The previous section on arbitration shows the importance to a Master of knowing when a message ends.  In fact, both Masters and Slaves need to be aware of when a message starts, stops, or is present.  This is not entirely straightforward, and depends on a combination of (1) carrier detect, (2) UART status indications, and (3) monitoring message content.

    Carrier detect indicates that a carrier of acceptable amplitude is present.  It tells a device that it should be examining its UART output and UART status.  In the UART status, a “receive buffer full” (RBF) indication will occur once each character.  Whether a message is present is determined by the combination of carrier detect and the RBF indications.  Many devices don’t directly monitor carrier detect.  Instead, they use it to qualify (gate) the UART input.  This bypasses the additional step of having to look at an I/O line.

    The presence of RBFs indicate that a message is present.  But they don’t necessarily indicate the end of a message or the start of another.  Back-to-back messages can occur (see box below), which means that a new message starts simultaneously with the end of a previous message.   The transition from one message to another can only be detected by monitoring message content.  The start of a message is indicated by a 3-character start delimiter.  This delimiter is a sequence that isn’t likely to occur anywhere else in a message.  It is more completely described in the section entitled   Start-Up Synchronization in HART.   A device will normally be looking for this start delimiter sequence unless it has already seen the sequence and is simply parsing the rest of the message as it arrives.

    But, what if the start sequence does appear in “normal data”?  This is a weakness of HART, but probably not a very important one.   The reason is that Slaves are probably the only devices that do not fully parse each message.  Therefore, if a start sequence occurs in mid-message, only a Slave will be fooled into thinking that it sees the start of the next message.   This Slave will then look for its own address, a command, etc.  The chance that the rest of the byte sequence will contain the Slave’s 38 bit address is probably almost non-existent.  Therefore, the Slave will not see its own address and will resume the normal activity of looking for the start sequence.

Back-to-back Messages and Temporary Collisions:    A device will often parse the entire message and know, upon receipt of the checksum, where the message ends.  A Slave may do this, for example, if the message was addressed to it.  Masters do it as part of   arbitration.  The Slave that is supposed to respond may immediately assert its own carrier upon seeing the checksum.  Similarly, the Master may realize that it will have the next use of the network and assert its own carrier upon seeing the checksum.   The new carrier may be asserted before the previous one has been removed and before the incoming RBFs stop, leading to a temporary collision.  During this time carrier detect never drops.     A temporary collision may sound like something terrible, but it has the same effect and is no more of a problem than carrier start-up alone.  Carrier start-up is more completely described in the section entitled  Start-Up Synchronization in HART.

    If a message should become garbled, then devices that have been parsing it must revert to waiting for the RBFs or carrier detect to stop, or for a new start sequence to appear.

    Ideally, RBFs would occur at a constant rate of one every 9.17 millisecond and the last one would correspond to the checksum character.   But received messages can have two peculiarities called gaps and dribbles.  A gap can occur between two characters of the same message.  It is a delay from the end of the stop bit of one character until the start bit of the next character.  It will appear to be an extension of the stop bit (logic high at UART input).  A dribble is an extra character that appears at the end of a message, just after the checksum character.  A dribble isn’t transmitted and doesn’t appear on the network.  It is manufactured by the receive circuit/demodulator/UART, possibly as a result of the carrier shutting OFF.  It will be shown here that these really don’t affect anything, except to slow down communication.

    Gaps occur when a Slave is not able to keep up with the 1200 bits/second data rate.  In theory there could be a gap between every two characters of the received message.  During a gap the carrier is present but no information is being sent.  Most modern Slaves are probably able to transmit without gaps.  But we still must assume that they can occur.  The HART specifications seek to limit gaps to insure maximum throughput, but are ambiguous as to how large a gap can be.  One bit time and one character time are both specified.  The ambiguity probably reflects the fact that a gap size on the order of 1 character time or less doesn’t matter much.  In the following we assume a maximum of one character time.

    Normally, RBFs occur at a rate of one per character time throughout the message.  If there is a gap, then there could be up to two character times between RBFs.  A device that is trying to decide whether a message has ended will normally restart its timer on each RBF.  The timer must be at least two character times (18.33 millisec) to account for the possible gap.  Masters will start RT1 and RT2 timers, both of which are much longer than a gap time.  Therefore, arbitration will not be affected by a gap.  A Slave that is being addressed may also implement a timer, so that it can detect truncated messages.  This timer must also be longer than two character times.

    A dribble generates an extra RBF.  It occurs so soon after a preceding character that it simply restarts timers and does not affect arbitration.  A device that creates this extra RBF will have to read and discard the phantom character.  And, since it will not be able to tell the difference between the phantom and a real transmitted character, it may have to check the character to see whether it is part of a start sequence.

    To summarize, the presence of a message is indicated by the combination of carrier detect and RBFs.  Since back-to-back messages can occur, it is not acceptable to look for carrier detect drop-out as an end of message.   Devices must look for the 3-character start sequence.  Gaps and dribbles can also occur in a received message.  Provided that device timers are longer than 2 character times, gaps and dribbles have no effect except to slow down communication.


Start-Up Synchronization in HART

    HART is a type of data communication in which devices assert carrier only for the time it takes to send a message.  (The modems are also called “burst modems.”)  When it’s time to talk, a device starts up its carrier and begins modulating it with the desired data.  When it is finished talking the device drops its carrier.   Devices that are listening must determine where the data starts.  If a listener fails to locate the starting point, then the message will generally appear meaningless.

    The chosen protocol must, therefore, provide some way for listeners to reliably locate the start of the data.  A common way to do this is to send an initial pattern of bits or symbols — a preamble or start delimiter — that is known to all listeners.  A challenge is always to make the preamble and/or start delimiter short to keep overhead low.  Another challenge arises because of the start and stop of the carrier.  There is generally no way to insure that this happens in a “clean” fashion.  Initial bits will appear to change randomly as the carrier rises to full amplitude, filter circuits settle, etc.  There may also be “dribble” bits at the end.

    The originators of HART faced this problem:  If carrier start-up causes random bits to be applied to the UART, how do we create an unambiguous start of data?     The UART uses a start bit (logic zero) to synchronize reception of one character.  If it’s been sitting idle for a time or if it thinks that the last thing it got was a stop bit, then the UART must assume that the next zero bit or the next transition to zero, is a start bit.  Any initial random zero bit will be considered a start bit.  Then, after 10 more bit times the UART will take the next zero bit as the next start bit.  Data containing a normal mix of ones and zeros will confuse the UART by presenting it with zeros that it thinks are start bits.

    The solution in HART is to start the message with a string of characters whose only zero bits are start bits.  The UART may be confused at first.  But after one or two characters it becomes synchronized.   There is only one character that is all ones.  It is formed by adding odd parity to 0xff.  The start-up process is illustrated in figure 2.5.

about2_5.gif (5744 bytes)

Figure 2.5 — Start-Up Synchronization

Here the modems have caused a delay between the transmit and received UART signals.   At carrier start-up there are some garbage bits at the receiving UART’s input.   This causes the UART to begin assembling a character.  When it has finished it will present this garbage character to the processor.  Then it will wait for the next start bit.  It won’t find one until after the “gap” has passed.  Then it will begin assembling the first good character.  The processor looks for a 0xff byte (good character) and discards the initial non-0xff bytes.

    The receiving processor looks for a sequence of 3 contiguous bytes:   preamble, preamble, start delimiter.  Thus, at least two good preamble characters must be received and they must be those that immediately precede the start delimiter.  HART requires that a minimum of 5 preamble characters be transmitted.   This allows for the loss of up to 3 characters by the process just described.   Typically 1 or 2 characters are lost.

    Repeaters typically cause a loss of preamble character because they must listen for carrier at both ends and then “turn the line around.”  The fact that there is only about one character to spare means that a HART repeater must do this in under one character time.  Usually this is enough time.

    Another possible way around the start-up problem would have been to have transmitting devices turn on their carrier and force it to 1200 Hz (logic 1) and wait for a few character times before loading the UART to begin data transmission.  If the transmitting UART is simply left empty before transmission the output will be 1200 Hz, equivalent to a stop bit or idle condition.  This is the same as creating a deliberate gap of a few character times.  At the receivers the respective UARTs would all collect an initial garbage character, as in figure 2.5.  But then there would be a gap, followed by the start bit of the first transmitted character.  This method has the drawback of requiring transmitting devices to implement a gap timer at the start of the message.

    A weakness of HART is that message start sequence of (preamble, preamble, start delimiter) can occur in data.   A device looking for a start sequence must look at context to determine whether these 3 characters represent a delimiter or data.  This makes HART somewhat less robust than it could be if there were a non-data type of start sequence.

Slave Receive Algorithm

    Figure 2.6 below shows an example Slave Receive Algorithm.  If the receive data stops prematurely, then there must also be a branch to “dump message, no reply.”  To provide the quickest possible reply, the Slave usually has to parse the message as it arrives, instead of waiting until it’s done.   Note that the Slave has to read every incoming byte and possibly just toss it.   “Can I Do This?” generally means “is the parameter that I received within an acceptable range?”

about2_6.gif (12608 bytes)

Figure 2.6 — Slave Receive Algorithm

The software that performs these functions is sometimes called a “stack”.

Data Compression

    HART makes limited use of data compression in the form of Packed ASCII.  Normally, there are 256 possible ASCII characters, so that a full byte is needed to represent a character.  Packed ASCII is a subset of full ASCII and uses only 64 of the 256 possible characters.  These 64 characters are the capitalized alphabet, numbers 0 through 9, and a few punctuation marks.  Many HART parameters need only this limited ASCII set, which means that data can be compressed to 3/4 of normal.  This improves transmission speed, especially if the textual parameter being communicated is a large one.

    Since only full bytes can be transmitted, the 3/4 compression is fully realized only when the number of uncompressed bytes is a multiple of 4.  Any fractional part requires a whole byte.  Thus, if U is the number of uncompressed bytes, and T the number of transmitted bytes; find T = (3*U)/4 and increase any fractional part to 1.  As examples, U = 3, 7, 8, and 9 result in T = 3, 6, 6, and 7.

    The rule for converting from ASCII to Packed ASCII is just to remove bits 6 and 7 (two most significant).  An example is the character “M”.  The full binary code to represent this is 0100,1101.  The packed binary code is 00,1101.  The rules for conversion from packed ASCII back to ASCII are (1) set bit 7 = 0 and (2) set bit 6 = complement of packed ASCII bit 5.

    Note that, with some exceptions, HART Slaves don’t need to do the compression or know anything about the compression.  They simply store and re-transmit the already compressed data.  Again, this is an instance where the more difficult software is placed in the device (Master) that is more capable of dealing with it.


Device Description Language

    As stated earlier, a HART Slave device can have its own unique set of commands.  It can also have a unique sequence of commands to accomplish some goal, such as calibration.  A Master must know about these commands and sequences, if it is to use the Slave Device to the fullest extent.  One way that the Slave Device manufacturer has of disseminating the information would be as text in a manual for the Device.  Then software engineers and system integrators could write specific code for the Slave Devices used at each installation.  Another way is to write a Device Description for the Slave Device using the Device Description Language (DDL).  The Device Description is similar to the Electronic Data Sheet (EDS) used for DeviceNet.   The HART Communication Foundation provides a specification for DDL and also provides training in how to write the DDL files.

    The Device Description is a file that can be read by a compiler, and converted into an end-user interface.  A program running in a HART Master reads the output of the compiler and is able to produce a complete sequence of menus and help screens that guide the plant engineer through whatever procedures the Slave Device can do.   In principle, using the DDL avoids writing code to talk to a given Slave Device.   Writing the DDL also forces the Slave Device manufacturer to critically examine how his device is supposed to work.

    So far it seems as though DDL hasn’t seen widespread usage, except in hand-held communicators made by Rosemount Inc.  Unfortunately, most of the software associated with DDL is apparently centered around the hand-held communicator.   In effect, the HART Communication Foundation and Rosemount Inc. still jointly distribute software needed to use DDLs.  There do not appear to be any 3rd party vendors of DDL compilers or the Master software that uses the compiler output.  We would suggest, as a remedy to this situation, that the HART Communication Foundation start giving away the DDL specification and that manufacturers of Slave Devices publish the actual DDL files via the Internet.

    The device description, using the HCF device description language, is a text file with an extension “.DDL”.  It is a series of compound statements that start with an identifying word and a name.  It looks something like this:

        VARIABLE variable_name_1
        {     structured info about variable_name_1    }

        VARIABLE variable_name_2
        {    structured info about variable_name_2    }

        COMMAND command_1
        {    structured info about command_1    }

        MENU menu_1
        {    structured info about menu_1    }

        METHOD method_1
        {    structured info about method_1    }



These do not imply any flow control and can appear in any order.  Each VARIABLE, COMMAND, etc. has its own structured information that must be included.  A VARIABLE is any quantity or index that is contained in the device or is used by a host to interact with the device.  In a device such as a pressure transmitter, one of the VARIABLEs (and probably the most important one) would be the pressure.  Others might be upper and lower range limits.  Another would be the device tag.  The structured information for a VARIABLE might include, for example, a format specification that tells how the VARIABLE is to be displayed to the end user.

    A COMMAND is a HART command.  The DDL has one of these statements for every HART command recognized by the device.  The structured information for a COMMAND is essentially everything related to the command including its number, request bytes, response bytes, and the returned response codes.

    A MENU is a presentation to the end user.  It can be used to present VARIABLEs or other MENUs or general information to the end user.

    A METHOD is a sequence of operations that the host is to perform on the device.  Examples would be installation or calibration.  METHODs are the least similar to the other example entities because they contain C-language statements.   When a METHOD is invoked, usually through some MENU choice that appears on the host display, the statements are executed in the order they appear.  “For” and “while” and “do”, etc. can all be used to perform looping operations.   The DDL language provides a large number of built-in functions that are essential for METHODs.  An example is “send(command_number)”, which sends a HART command.  There are also a large number of built-in functions related to aborting the METHOD.  This is essential to allow the end user to understand what is happening with the device and the host when things don’t go as planned.

    In addition to VARIABLEs, COMMANDs, MENUs, and METHODs, there are about 5 or 6 other possible entities.  These are described in HCF documents.   IMPORT is one of them that deserves special mention.  IMPORT is a means by which an existing DDL can be re-used without having to enter its entire text.  This allows, for example, the HART Universal COMMANDs, VARIABLEs, and tables, to be used by any device without having to enter them all.  IMPORT provides a mechanism for re-defining any entity in the imported DDL.  If, for example, a new field device does not use one of the Universal VARIABLEs, this can be indicated in one or two lines of code after importing all of the Universal VARIABLEs.  Perhaps the most important use of IMPORT is fixing an existing DDL.  The revised DDL is simply an IMPORT of the existing one with one or more entities re-defined.

    Among the various available HCF and Fisher-Rosemount hand-held documents, one that is seriously lacking is a document to explain how the DDL relates to what is displayed on the hand-held communicator.  In other words there is nothing that says that if I write code ‘ABC’ I will see ‘XYZ’ in the hand-held display.   Similarly, there is no way of knowing what hand-held functions (soft-keys at the bottom of  the display) become available in a given situation.  We strongly encourage Fisher-Rosemount to come up with an app note that covers this.  But until then DDL writers are probably stuck with trial-and-error.  A few general guidelines or caveats are as follows.  Keep in mind that this applies to an existing version of the hand-held and that a future version might be different.

    1.    The display is very small.  Almost all text, except for help messages, must be abbreviated.

    2.    Help messages can be quite long because the hand-held allows ‘page-up’ and ‘page-down’.

    3.    Help messages and labels are defined in the called METHOD or VARIABLE; not in the
           calling entity.  In other words, help messages associated with a given MENU are not
           defined in that MENU.

    4.    Help for a MENU is not allowed.  Thus, an end-user cannot know ahead of time whether he
           wants or needs the next MENU.

    5.    In the DDL source there is no way to define long messages on multiple lines.  To print the
           source code, it is necessary to invoke some printing method that has automatic wrap-around.

    6.    You cannot define any of the hand-held soft keys.  Everything you do must occur through
            numbered or ordered lists that you program into the display.

    7.    Format specifications in a METHOD over-ride those in a VARIABLE.

    8.    A HART communication defined in a METHOD occurs automatically.  Others often require
           the end-user to push a button labeled ‘send’.

    9.    During execution of a METHOD, there is no convenient way of having the hand-held
           repeatedly execute a loop in response to a key being held down or even repeatedly pressed.

    10.    During execution of a METHOD, an ‘abort’ will automatically be available via soft-key.
           There is no need to program this.

    11.    It is possible to define a MENU named “hot_key”.  This MENU becomes available when
            the user presses the hand-held hot key, which is one of the available function keys.  There
            are two problems associated with the hot key.  First, there does not appear to be any way
            of informing the user that the hot key is available and what it does.  Second, the hot key
    MENU is unavailable during execution of a METHOD.

    12.    Most “pre-” and “post-read” METHODS that you might want to associate with a
            VARIABLE won’t work.   You will get a “non-scaling” error message.  Apparently
            everyone has seen these and nobody knows why they happen or what can be done
            about it.

    13.    METHODs are generally not checked for errors during compiling of the DDL.  They
             don’t show up until you run the hand-held simulator.

Slave Development Steps

    Suppose you make smart (microcontroller-based) analog X-meters (where X = flow, temperature, etc.) and now you want to make a HART version of the X-meter.  Here are the steps to take.  You might also consider joining the HART Communication Foundation as a first step, since you will eventually have need of them anyway.

        1.    Make a list of things your customers do with the existing X-meters.

        2.    Of these things make a smaller list of things that are difficult to do because someone
                has to be sent to the X-meter site.  Determine whether one or a series of HART
                transactions with an X-meter could reduce or eliminate this activity.

        3.    Determine whether any existing HART Universal or Common Practice commands
                could be used to implement or partially implement these transactions.  If not, define
                one or more new commands (Device-Specific commands) that will be needed.
                Writing a DDL may help at this point by obviating missing commands.  If there are
                more than a few new commands, write a specification that spells out in detail
                (down to the individual bits) what each one does.

        4.    Determine whether the HART communication will place too much demand on existing
                X-meter resources (memory, etc.) and what kind of resources will need to be added.
                You will need EEPROM to store things like the Slave’s address.

        5.    Start hardware and software design of new HART X-meter.  Devise or otherwise
                obtain a HART Master that can be loaded with your new HART commands.  Begin
                assembling equipment for HART Conformance verification if it’s not already available.
                Or else locate an outside company that is set up to run the tests.

        6.    Decide how your customers will talk to the X-meter (DDL and hand-held master, info in
                User Manual, Complete Software package that runs on PC).  If software must be written,
                start now.

        7.    Complete the design, set up some HART networks in your own manufacturing area and
                start banging away on prototypes.  The HART Communication Foundation has code to
                help you run tests.   For example, it can send your device a message with a bit error to
                see if you catch it.

        8.    With HART X-meter apparently functioning as intended, run HART Slave Conformance
                tests.  Or have tests run by outside company.  Note:  Some tests such as bit error rate are
                of questionable value if you have followed a relatively standard design spelled out in
                application notes and have not seen any reason to suspect non-conformance.  Bit error
                rate tests are also difficult to do and are not adequately addressed in the HART
                Conformance document [2.3].

        9.    Contact HART Communication Foundation for assignment of (and payment for) a Slave
                Manufacturer’s code.   This is a byte that becomes part of the long frame address of
                every HART Slave that you manufacture.   You may not legally be able to claim HART
                compliance or use the HART trademark without this step.

        10.    Obtain other product approvals, do EMI tests, etc.

        11.    Sell more X-meters.

    If this all seems obvious, that’s great!  It means your halfway there.

Addressing Problems, Slave Commissioning, and Device Database

    The existing HART addressing scheme has several potential problems that are examined here.  Only modern (rev 5 or later) Field Instruments (using 38-bit address) are considered.  First, a Field Instrument can have any of about 275,000,000,000 possible addresses, which makes it impossible to determine the long addresses of Field Instruments after the network has been built and the Field Instruments installed.   Even if there are only 2 Field Instruments on the network and Universal Command 0 is used to try to read the long address, the procedure can still fail because short addresses might be duplicated.  This makes it almost a necessity, in all but point-to-point applications, to commission a Field Instrument prior to installation and to maintain a database of long addresses.

    Commissioning means powering up the new Slave on a bench network where it is the only Slave, and asking it for its long frame address.  (Commissioning usually includes other things as well, such as assignment of a tag.)  The long frame address is then added to a database of devices.  The database will later be used when the Slave is put into service.  Eventually, most such databases probably expand to include virtually all the Slave characteristics available through HART Universal Commands.  Initially, however, they need only contain the address or the tag for each Slave.  In most end-user applications commissioning and building the device database is probably done anyway.  Therefore, the need to do it to satisfy HART is probably not much of a burden.

    Another problem involves the unique identifier.  The first byte of the unique identifier is the manufacturer’s ID.  Since only one byte is allowed for this ID, it means that only 256 manufacturers can be so identified.  Undoubtedly, if the number goes higher than this, some change to the protocol will be devised.   Another possibility is that vendors will share an ID number and devise a serial number (last 3 bytes of unique identifier) scheme such that neither will ever duplicate the other’s unique identifiers.

    Another problem, also involving the manufacturer’s ID, is that only the lower 6 bits of this byte are used in the long address.  This means that, even though each Field Instrument can have a unique identifier, it can’t have a unique long address.  If device vendors were to begin numbering their product lines at 0 or 1 and their serial numbers at 0 or 1 (which seems entirely reasonable), then there is a pretty good chance that the long addresses might be duplicated.  The HART standards attempt to reduce this likelihood by requiring the product line byte (the second byte of the unique identifier) to be numbered in a specific way — from higher to lower numbers for half of the possible manufacturer’s IDs (first byte of unique identifier) and from lower to higher numbers for the other half.  There are also 4 ranges of product line numbers and 4 ranges of manufacturer’s IDs.  Each range of manufacturer’s ID numbers has a specific range of product line numbers.  This is illustrated in Table 2-2 below.

Manufacturer ID Range Range Of Acceptable Product IDs
0 to 63 (decimal) Start at 0 and increase
64 to 127 Start at 239 and decrease
128 to 191 Start at 127 and decrease
192 to 255 Start at 128 and increase

Table 2-2  —  Allowed combinations of MFR IDs and product line numbers

    Finally, the addressing scheme creates a need for device vendors to register their devices with a registration body — the HART Communication Foundation.   This is a costly bookkeeping adventure that could just as well be done by end-users.  The end-user already decides which vendor’s device to buy, maintains an address database, and assigns a tag to each device.  He could as easily assign the address and determine which DDL he needed, based on the device vendor and serial number.

Bell-202:  Bad News in Europe

    Telecommunication systems (phone utilities) use certain well-defined tones for administrative purposes.  These tones fall within the voice band but are only effective if there is no energy present at other frequencies.   The tones used in Europe are different from those of the United States.  Unfortunately, one of those used in Europe falls into the range of 2130 Hz to 2430 Hz (see [2.4] for example).  The Bell-202 frequency of 2200 Hz could appear as a pure tone within this forbidden band.  Consequently, if Bell-202 equipment were to find its way onto a European phone grid, it could cause problems.   Normally, European telecommunication regulations prevent the sale and distribution of incompatible equipment, so that this doesn’t happen.

    So what does this have to do with HART?  If HART communication is confined to private industrial networks, as is usually the case, then there is no association between HART and telecommunications.  HART should be just as acceptable in Europe as anywhere else.  It should, but it isn’t always.   We have experienced problems when using the term “modem” in instruction manuals, etc.  Apparently this term has become almost universally associated with telecommunications.  And in some instances this has led to seizure of HART equipment by authorities who did not understand its purpose.  We found that we had to remove the term “modem” from some literature.

    Under certain circumstances it is possible to do HART communication over European phone lines.  This is further discussed in the section entitled HART Bridges and Alternative Networks.


Grounding and Interference

    An industrial environment can produce a variety of powerful electric and magnetic fields, as well as significant voltages between different “grounds”.  Most often they are at 50 Hz or 60 Hz and don’t pose much of a threat to HART.  However, sometimes they or their harmonics fall into the HART band (about 900 Hz to 2500 Hz).  Since HART signals have a rather small amplitude, there is a possibility that these higher-frequency fields will disrupt signaling.   Interference that would have no effect on an analog 4-20 mA signal (because of lowpass filtering in the controller) might be enough to destroy HART messages.  Here we look at how to protect against the interfering fields and how ground potential differences can still manage to cause trouble.

    The circuit of a HART Field Instrument is typically contained inside of a metal case that is at earth ground.  The circuit is isolated from the case, except for feedthrough EMI filters and an inevitable small capacitance from the circuit to the surrounding case.  There is no single wiring scheme that is best at reducing interference in all circumstances.  But for Field Instruments of the type described, the following is usually recommended:  The Field Instrument and Controller (Master) are connected by a shielded twisted-pair cable.  The shield is grounded at the Controller end and left open at the Field Instrument end.  The shield prevents electric fields from coupling into the signal conductors, while the twisting attempts to reduce the effects of magnetic coupling by forcing equal coupling into both sides of the pair.  The shield is left open at the Field Instrument end to avoid the conduction of ground currents.  A ground current on the shield couples magnetically to the conductors of the twisted pair.  These ideas are more thoroughly explained in [2.5].

    A ground current can result from making a connection between two “grounds” that are at different potentials.  The different potentials can arise from huge currents (amps) flowing through cables that separate the grounds.  A ground current also arises when a conductive loop is formed in the presence of a strong (varying) magnetic field.

    Even when the wiring rules are followed, this difference in ground potentials can cause interference.  To see this, consider the circuit of figure 2.7.   The cable shield is connected at the Controller ground, according to recommended practice.  A voltage Vin exists between the Controller ground and Field Instrument ground.  The circumstances that create Vin usually also cause a relatively large impedance in series with it.  This is represented by Zs.

wpe8.gif (6074 bytes)

Figure 2.7 — HART Circuit Showing Ground Potential Difference

At HART frequencies we can make the following assumptions:

1.    The cable can be considered a lumped circuit consisting mainly of capacitance.

2.    The Circuit-to-case Capacitance inside the Field Instrument is negligible.

3.    The impedance of the box labeled “Circuit” across the Field Instrument terminals is practically infinite.

Note that one side of the twisted pair is grounded at the Controller.  Then the equivalent circuit is as in figure 2.8.

about2_8.gif (3981 bytes)

Figure 2.8 — Equivalent Circuit for Effect of Ground Potential Difference

The interference is the voltage Vout developed across the Field Instrument terminals.  It is related to Vin by

If we assume that the EMI feedthrough filters have nearly equal capacitance so that C1 = C2, this becomes

Quite often Zs is large (small capacitance, large resistance).  Then sC2Zs >> 1 at HART frequencies and the expression becomes approximately

In a properly constructed HART network the pole frequency in this latest expression will be above the HART band so that within the HART band the expression reduces to

As an example, suppose that Zs is due primarily to a capacitance with a value of 1000 pf.  And let Vin = 100 volt at 2 kHz, R = 250 ohm.  Then the magnitude of Vout = 0.31 volt.  This would certainly destroy the HART signal. 

    One way to remove the effect of Vin is to connect the cable shield to the instrument case at the instrument end.  This gets rid of or reduces the effect of Vin, but may cause other problems.  Some experimenting may be necessary.  A better way is to use a separate ground conductor between the controller and instrument grounds.  This new ground conductor can be separate from the network cable.  Or it can be built into the network cable.  Special cables, having both an inner and outer shield, are made for this purpose.

HART and Intrinsic Safety

    HART was always intended to be retrofitted to existing process loops, including those that are intrinsically safe (IS).  The relatively low HART signal level and superposition of the HART and analog signals are the result.  Also, an individual HART Field Instrument is not too different from a non-HART Field Instrument in terms of power consumption and equivalent capacitance and inductance.   If we look only at signaling and Field Instrument design, we might conclude that combining HART with IS is not a problem.  But when we look at HART in its broader context, there are problems.  They are, or result from, (1) the need to transmit HART through IS barriers, (2) topology differences between HART networks and conventional current loops, and (3) the existence of a new device — the hand-held communicator.  The implications of combining HART and IS and their effect on each other will be considered next.

    The simplest form of  IS HART network is one with just a single 2-wire Field Instrument (a Point-to-Point HART network).  The Field Instrument and cable are located in the hazardous area and a barrier separates the safe and hazardous areas.  This is illustrated in figure 2.9.

about2_9.gif (3037 bytes)

Figure 2.9 — Simplest IS Arrangement

We assume for the moment that nothing else will ever be connected to the network at the hazardous side.  However, there may be a HART Master at the safe side.  There are two things to consider here:

    First, the barrier, Field Instrument, and cable must represent a compatible combination.  That is, the Field Instrument must consume less voltage and current than allowed by the barrier and the cable+Field Instrument must represent less C and L than allowed by the barrier.  A HART Field Instrument consumes about the same voltage and current as a non-HART Field Instrument.  And the addition of HART components (such as receive filter, etc.) don’t add much C or L.  Thus, the single HART Field Instrument is comparable to a conventional process instrument and presents no unusual difficulties in achieving IS or in compatibility with other IS components.

    (Note:  We will neglect heating effects on small components, even though this can be an important consideration in the design of the Field Instrument.  We assume that the added components needed for HART affect IS only through added C or L or changes in circuit topology.)

    Second, the barrier must pass the HART signal with a minimum of attenuation and distortion.  Barriers can affect the HART signal in a variety of ways, depending on the type of barrier and on associated components.  The HART Physical Layer Specification prescribes several tests that barriers must satisfy.   These tests are all related to insuring that there is sufficient signal passed in each direction through the barrier; and that the signal is not distorted by the barrier.

    In a conventional resistor-zener diode barrier, it is theoretically possible to operate too near the zener clamp voltage so that the HART signal excursions are clipped.   Usually, however, the peak HART voltage is on the order of 0.25 volt; and barrier ratings are conservative enough that clipping doesn’t occur.  (Note that if the barrier working voltage is too near the clamp voltage, there would be too much leakage current.  Analog signaling would become inaccurate.)  Another effect of a resistor-zener barrier is a flat attenuation of a voltage signal.  A barrier with a 300 ohm resistance, used with a 250 ohm current sense resistor, creates a divider that will attenuate by 0.45.  The Controller will see a HART signal voltage that is 0.45 of the voltage across the network.  Yet another effect of the standard resistor-zener barrier is a lowpass filtering caused by junction capacitance of the zener diodes.  Capacitances of several thousand pf are possible.  However, this often just adds to a much larger cable capacitance and doesn’t need to be taken into account.

    An important consideration for active or repeater barriers is that they do not remove the HART signal with a lowpass filter designed primarily to pass the analog 4-20 mA signal.  Another is that they do not chop (to create AC) at a frequency that is in or near the HART band.  These special barriers must often be specifically designed to work with HART.

    The next step up in complexity is an IS HART network identical to that described previously, except that it contains two or more multi-dropped Field Instruments, as illustrated in figure 2.10.

abou2_10.gif (3217 bytes)

Figure 2.10 — More complex IS Arrangement

Again, the barrier, cable, and Field Instruments must be a compatible combination.  Since more L and C is being added with each Field Instrument, the likelihood of a viable combination becomes less as their number increases.  In fact, we’ve not heard of any instances of two or more Field Instruments being used in this way.   But this may simply reflect the facts that (1) most HART applications are point-to-point (one Field Instrument) instead of multi-drop; and (2) most applications are not IS.  If the parked current of each of the Field Instruments is 4 mA, and if equivalent L and C are kept sufficiently low, it should be possible to operate about 4 or 5 Field Instruments from a single conventional barrier.

    Finally, the most complex situation results when a hand-held communicator (HHC) is connected to the hazardous area network, as illustrated in figure 2.11.  (In theory there could still be more than one Field Instrument, as in figure 2.10.   However, the presence of the HHC multiplies the IS difficulties such that the prospect of multiple Field Instruments becomes less likely.)

abou2_11.gif (3743 bytes)

Figure 2.11 — Most complex IS Arrangement

Instead of a HHC, the added device might instead be a second Field Instrument capable of actively generating its own voltage or current signal (such as might occur in a 4-wire Field Instrument).  Either type of device presents the same kind of problems with respect to IS.

    The HHC (or active Field Instrument) signal is AC-coupled to the network and is infallibly clamped so that peak voltage can’t exceed about 1 or 2 volt.   Using the HHC means that the instantaneous network voltage under fault conditions can now equal the sum of the barrier clamp voltage and the HHC clamp voltage.   For a 28 volt barrier, the total voltage then becomes 29 to 30 volt.  (The reason that the maximum voltage isn’t still identical to the barrier clamp voltage is that there is resistance between the barrier zener diodes and the HHC.   This resistance is the combination of the barrier resistance and cable resistance.)   There is also an increase in current that could conceivably be drawn from the combined barrier and HHC.  The barrier and HHC may be thought of as two power sources and two barriers, both supplying power to the network.  Since the HHC signal is an AC voltage and current with average value of zero, and since its peak value is quite small compared to a 28 volt-rated barrier, some safety agencies ignore it.  Others don’t.

    Suppose that we are stuck dealing with a safety agency that assumes the extra voltage and current.  What are the ramifications?  Then even if the same barrier is used in figures 2.9 and 2.11, a Field Instrument that was acceptable in figure 2.9 might not be in figure 2.11; because of (1) the higher voltage and current and (2) the extra capacitance introduced by the HHC.  Not only might the Field Instrument be unacceptable, but the “entity” concept of constructing the IS system no longer works.  The barrier ratings no longer mean anything and the combination of barrier, Field Instrument, and HHC may have to be certified as a unit.   This is not a trivial consideration, since it means that a prospective customer may be locked into a combination of devices from a single vendor.

      NOTE:    The IS design of the HHC itself is a technical tour-de-force.  The HHC is generally battery-operated and isolated from the network by an infallible transformer.  The circuitry on the HHC side of the transformer includes the battery.  Without appropriate IS design, there would be ample opportunity for gas ignition, irrespective of any connections to the outside world.  The network side of the transformer is subject to the full current allowed by the barrier and must be sized and clamped appropriately.  And, as indicated earlier, the output must be clamped so that only 1 or 2 volts can be produced at the terminals.  And on top of all of this, there’s that pesky expectation that the HHC still provide HART communication!       Currently we know of only two manufacturers of Intrinsically Safe HHCs:  Rosemount Inc. and MTL.

    One way around the situation just described is to have the HHC interface be similar to that of a passive 2-wire Field Instrument; so that the combination of the Field Instrument and HHC appear to be just two Field Instruments as in figure 2.10.  But this requires that the HHC draw current from the network — an unacceptable approach when analog signaling is present.

    The entity approach to IS and the use of HHCs in hazardous locations are both such important concepts, that we probably have not heard the last of this apparent clash.  It seems likely that some kind of compromise can be worked out so that both concepts are available world-wide.

    In conclusion, HART was originally conceived to be IS-compatible and is generally well suited to use in IS environments.  Multi-dropped Field Instruments in an IS environment are possible but not often used.  An HHC in the hazardous area is possible, but presents special problems.

HART and CE Mark

    In 1996 the CE Mark became mandatory for electrical/electronic products sold in Europe.  The CE Mark means, among other things, that the product satisfies specific requirements for ESD immunity, EMI immunity, and EMI generation.  For instrument makers EMI immunity usually surfaces as the major concern.  The specification for EMI immunity that usually applies to HART devices is [2.6].  This, in turn, refers to [2.7].  The test signal ranges from 150 kHz to 80 MHz and is modulated with 1 kHz.

    A HART Field Instrument can be affected by EMI in two ways:  (1) Analog Signaling may become inaccurate and (2) HART Signaling may suffer an increased error rate.  The instrument vendor is allowed to state what constitutes a failure of the device in the presence of EMI.  For analog signaling this usually isn’t difficult.  For example, the vendor can state that the accuracy remains within X % of span during exposure to EMI.  For HART signaling, however, we are not aware that any widely accepted criterion has been established.  The likely affect of EMI on HART communication would be to interfere with it and increase the bit error rate.  This, in turn, increases the message error rate.  The increase in message error rate could be so small as to go unnoticed by an user; or so large as to completely stop the HART communication.  Here we will examine how EMI can affect the HART Field Instrument and look at some possible tests and failure criteria.

    A typical 2-wire process instrument has its circuit contained in a metal case that is connected to earth ground.  The circuit is isolated from the case and is connected to an external cable through EMI feedthrough filters, as illustrated in figure 2.12.  The cable shield or one of its leads is grounded at the end opposite the process instrument.

abou2_12.gif (5985 bytes)

Figure 2.12 — RF Circulating Current In Process Instrument

When this arrangement is exposed to EMI, a circulating current is established.  Its path is shown in the figure.  For the purpose of looking at the RF current path, all of the cable conductors are lumped together as though they just one single conductor.  The process instrument circuit is also just one single piece of conducting material, with a small capacitance to the case.  Ideally, most of the circulating RF current will go through the EMI filters and instrument case, bypassing the circuit.  But some of the current will go through the circuit and couple into the case.  The latter current takes various paths through anything it can find on the circuit board or boards.  It can be amplified if it encounters an active circuit with a high enough bandwidth.  But it usually encounters some nonlinearity (transistor junction, for example).  This demodulates it and brings it down into the low frequency range, where it may cause offsets and amplifier saturation.  The ENV50141 test is particularly bad because it uses a 1 kHz modulating signal — a frequency within the HART band.

    Another effect that can be equally bad results from the EMI filters being unmatched.  That is, one of the EMI filters is slightly different from the other.  Or, even if the EMI filters are matched, the impedance of the circuit to earth ground might be different at one terminal than at the other.   The circulating RF current then causes a normal-mode RF voltage to appear across the input terminals.  Depending on frequency, this voltage may be amplified by circuits or may be subjected to nonlinearities as previously discussed.  Ways of keeping the RF out of the circuit are discussed in [2.5].  But we still need a test criterion.

  A possible test — one that we have used —  is to have a known message sent back and forth repeatedly between two devices, one of which is exposed to the EMI.  Message errors at both ends are counted and if a threshold is exceeded, the device has failed.  The problem with this is that devices aren’t necessarily designed to operate in this manner.  Modifying them or tapping into their hardware in some way negates the test, since the device tested in this way isn’t the same as the device to be sold.  Modifying just the software might be OK.  If there is enough code space available, then a test mode that works as described might be possible.

    A test that can be done on a Field Instrument is to repeatedly send it a Universal Command (such as command 0) and get its reply; with the Field Instrument located in the EMI Field and the Master located outside of the Field.   If the message received by the Field Instrument is in error, then either it won’t send a response or it will send a response with an error status indication.  Either way, the Master knows something went wrong.  This testing assumes that messages reaching the Master are OK and is a test primarily of the ability of the Field Instrument to receive in the presence of EMI.  The cable between Master and Field Instrument should be passed through the EMI containment wall using EMI feedthrough filters so that the EMI doesn’t reach the Master.

    Assuming that the command-reply type of test is used, then what should be the criterion for failure?  It might be nice to know the number of bit errors, because this relates to the probability of an undetected message error (UME).  But the HART Master doing the error monitoring can only count transaction errors.  That is, if it sends a command and gets a good response back, then everything’s fine.  But if it gets no response or a bad response, there is no way of knowing how many bit errors may have contributed.  Consequently, we have to look at some less informative but more practical criterion.  Real devices will probably show one of the following 3 behaviors, with the first two being the most likely:

            1.     There are no transaction errors logged.

            2.     There are massive numbers of transaction errors as the interfering frequency
                    is swept through specific regions.

            3.     There are a few transaction errors that aren’t always repeated on subsequent
                    frequency sweeps.

Most of us would agree that if (2) happens then its back to the drawing board.  But either (1) or (3) would mean that we still have an usable HART system.   Therefore, we suggest as the criterion that there be no interfering frequencies or frequency bands in which the number of transaction errors is observed to steadily increase at a rapid rate.  That is, there can be no interfering frequencies or bands in which there is essentially no HART communication.

    As a practical matter, when there are few or no communication errors, the examining technician must be convinced that the devices really are communicating and that the errors, if any, will be logged.  A convenient way to do this is to loosen the connections to a device and wiggle the wires enough to cause momentary disconnections.

    In the standards cited above, “RF” starts at 150 kHz.  Unfortunately, this is low enough that it will pass through conventional EMI feedthrough filters, most of which are designed to start having an effect at 10 MHz or more.  Not only does the test start at a relatively low frequency of 150 kHz, but the ENV50141 specification seems particularly unfair and unrealistic in requiring the RF source to be connected directly to the HART network during the test.  That is, instead of the network being an antenna for the RF, as would happen in reality, the network becomes part of a lumped circuit that contains the RF generator.  The consequence is that a very large common-mode signal at 150 kHz and modulated with 1 kHz gets applied to HART receive circuits.  We are not aware of any HART Field Instruments that pass this test.  It seems likely that a future revision of the standards will provide a more realistic test that does not call for any actual connection of the generator to the HART circuits; and will reflect the difficulty of RF coupling at such a low frequency.


Electrical Measurement of a HART Network

   Suppose you want to see the HART signal as in figure 1.3.  You can do this with an oscilloscope.  But if you plan to connect it across the twisted pair, you may want to use differential probes instead of a conventional probe.  The ground connection of the conventional probe may create an undesired circuit path.  For example, if the network circuit is that of figure 1.2, the conventional probe may either short-circuit the power supply or the current-sense resistor.  Using large capacitors between the twisted-pair conductors and the conventional probe leads doesn’t help.  It provides DC isolation, but you may still be short-circuiting the signal that you’re trying to view.  Using a conventional probe with a floating, battery-operated scope is OK.


Isolating A Non-Isolated Modem

    A need sometimes arises to galvanically isolate a HART Master from the HART Network using components that are easily obtained.  This can be done as in figure 2.13.

wpe41.gif (3904 bytes)

Figure 2.13 — Isolating HART Master

Choose an electrolytic capacitor that has low leakage current and avoid using it high temperatures.


Troubleshooting:   What To Do When “It Just Won’t Talk”

    Whether you’re an end-user, a systems integrator, a programmer, or a hardware person; you’ve probably had occasion to use a few choice words when a HART device just won’t talk.  Often you can get somebody else to figure out why.  But in case you’re elected, here are some things to look for.  We will assume the common situation in which we are trying to talk to a HART Slave Device that is currently in production and whose health is not suspect.

Easier Things to Try

1.    First, is the wiring correct?  Is the Slave powered?  If it is 2-wire, does it have sufficient DC operating voltage and current?   Is the Slave connected across the combined power supply and current sense resistor (this works); or across only the power supply (this doesn’t work)?

2.    Is it the only Slave on the network?  If there are two or more, do they have different polling addresses?  (Two Slaves with the same polling address can result in a collision and the appearance that neither exists.)

3.    If the Master is a personal computer + modem, are you sure that you have the correct COM port selected?  If you’re using a multi-tasking operating system, is it capable of sending out the bytes without significant gaps?  (See section entitled   HART and PCs.)

Less Easy Things

4.    If possible connect an oscilloscope (a differential connection is usually best, if possible) across the network.  Set it to AC-coupled and band-limit to 20 MHz or less.  When the network is supposed to be silent (nobody talking) you should see just a noise level of something like 0 to 20 mV p-p.  A larger amount of interference at 50 Hz or 60 Hz is probably still OK.   If there is interference greater than 20 mV p-p in the region of 900 Hz to 2.5 kHz, this could be the problem.  You may need to find and eliminate it.

5.    With the oscilloscope across the network, can you see bursts of carrier each time you take action to look for or talk to the Slave?  A Master will usually try several times so that you see the carrier burst repeated about once or twice per second until the Master gives up.  If you don’t see these bursts at all, then the Master is suspect.  If you are developing the Master software, are you writing to the correct port?  Are you turning on RTS (request-to-send) during the transmission?  Is the bit rate set correctly?

6.    If you do see the bursts, examine a burst carefully.  It should consist of two parts:  the Master transmission followed by the Slave transmission.  These will usually have different amplitudes.  There may be a gap between them.  The Slave transmission will usually last longer.  If you see only one part, it is the Master transmission and the Slave transmission is missing.  Examine the Master transmission in greater detail.  One of the nice things about HART is that you can read the transmitted bits from the waveform.  Are there at least 5 preamble characters being generated?  If not, then are you turning ON RTS too late?  If there are enough preamble characters; check the start delimiter, address, and so on through the checksum.  The sequence of characters for sending Universal Command 0 to a normal (unparked) Slave is

        FF FF FF FF FF 02 80 00 00 82

The bit sequence is START, LSB, …., MSB, PARITY, STOP.  If part of the checksum is missing, are you leaving RTS ON long enough?  If the Slave is an older type of device, and you can specify the number of FFs, then increase them from 5 to 20.  Is the parity correct?  For each FF it should be a ONE.  Make sure it’s not ZERO or missing.  Check the length of the Master’s message.  For the 10-byte sequence shown above, it should be 91.67 millisecond.  If it’s off by about 833 microsecond, or a multiple of 833 microsecond, then there are extra or missing bits.   Is the amplitude of the Master transmission large enough?  It must be at least 120 mV p-p to insure proper carrier detect operation in the Slave.  Amplitudes of 300 mV p-p to 500 mV p-p are more typical.

7.    If there are two distinct parts to each burst, it means that the Slave is replying but the Master is not seeing the reply.  Do the same thing for the reply portion of the burst as described in (6).  That is, try to identify the sequence of bytes that the Slave has generated.  Is there a distinct preamble with at least 4 identifiable FFs?  If not, are you turning OFF the Master’s RTS too late?  Is the Slave signal amplitude too small?  It must be at least 120 mV p-p and is usually more like 250 mV p-p.



HART Repeater

    A repeater may be necessary when the desired cable length exceeds limits set by the HART Standards or when there are more than 15 devices.  It is a two-port device placed between two network segments.   From a Protocol viewpoint it makes the two segments look like one network.   Although the repeater might also be equipped to repeat the analog 4-20 mA signal, our discussion here is limited to a device that repeats only HART signals.

    To preserve the HART timing, a repeater must repeat in real time.  That is, it cannot store messages for later forwarding.  Delays must be limited to a few bit times if various timers are to work reliably.  Another limitation is noise.  A repeater cannot simply amplify and re-transmit the FSK signal, since this would also amplify and re-transmit noise on the network segment.   This narrows the choice of repeater architecture to one in which the incoming signal is demodulated and then re-modulated.  In addition, we must re-modulate with a “clean” signal.   The output of a demodulator will contain jitter due to noise and to the demodulation process.  This jittery signal should not be applied directly to the re-modulator, since this would result in a degraded signal to one or more receiving devices.  Instead, the demodulator output should be detected in UART fashion (i.e., sample at mid-bit).  Some logic is also needed to determine at start-up which bit is a start bit and to count out each 11 bits that have passed and identify the next start bit.  A block diagram of the repeater is shown in figure 2.14.

wpe42.gif (5280 bytes)

Figure 2.14 — Repeater Block Diagram

    Notice that, except for the line interface circuits and carrier detects, there is just a single signal path that is turned around as needed.   The direction can be determined by a relatively simple state machine as illustrated in figure 2.15.

wpe41.gif (4866 bytes)

CA = Carrier Detect on Network A
CB = Carrier Detect on Network B

Figure 2.15 — Direction State Machine

    There are 3 states:  idle, B>A (Network B to Network A), and A>B (Network A to Network B).  Idle means that both ends are listening and the driver switch is not connected to either network.  CA, CB = 1,0 means that there is carrier at network A and not at network B.  And so on.  If both carriers are present, the last state is retained.

    A problem with all interface or bridge devices is the time it takes to turn the line around (or to turn on a signal path).  This is usually related to carrier detect and can often be done in less than one character time.   However, the loss of a character increases the number of preamble characters that may be lost from 2 to 3 (see also Part 2:  Startup Synchronization in HART).   If only 5 preamble characters were sent, as is often the case, this leaves only 2 as valid preamble.  Thus, the margin against missing the preamble is reduced.   If another device, such as a 2nd repeater were to be included somewhere in the network, there would likely be frequent failures to recognize the start of a message.  The change to a HART Slave to force it to require more than 5 preamble characters is usually minor.  Therefore, the vendor of the Slave device may be willing to increase the preamble size for the device in the interest of satisfying a customer.  At the Master end the software can be changed so that it always uses a preamble of greater than five characters, ignoring whatever number the HART Slave says it should use.


HART Gateways and Alternative Networks

    Conventional HART, operating at 1200 bits/second and using a process loop as a network, has been the focus throughout most of this book.  However, the desires of HART process equipment customers are seldom so limited.  The need arises to connect
HART devices in unconventional ways, which is the subject of this section.  These unconventional methods can be divided roughly into two categories:  those that still use HART protocol or some of it, and those that connect HART with networks using entirely different protocols.  An interface between networks having different protocols is called a Gateway [2.8].  Examples would be HART to Devicenet [2.9], HART to Ethernet, HART to Modbus, etc.  Some of these unconventional methods are presented here, in no particular order.


    PC as Gateway

    About the easiest way to form a Gateway is with a personal computer.  This is sometimes done by systems integrators who need something up and running in the shortest possible time.  As personal computers become less expensive and more reliable, this
becomes more of an option.  Small, inexpensive, single-board computers that implement DOS or Windows CE can also make this a reasonable approach.

    As an example, suppose you need an Ethernet-to-HART gateway.  This is done as in figure 2.16.

Figure 2.16 — Using PC As Gateway

You buy the 3 pieces of hardware and write the software.  For applications that are more cost-sensitive or that require greater reliability, a dedicated piece of hardware may be needed.  Some of these are examined as follows.


   DeviceNet to HART

    DeviceNet is becoming the de facto standard for high speed on-off sensing and control.  HART and DeviceNet have little in common, as indicated in the following table.  We wouldn’t expect many similarities, since the two protocols are intended for different purposes.

Network Type HART DeviceNet
Modulation Method FSK Baseband with Bit Stuffing
Data Rate 1200 BPS 125 kBPS and up
Application Transmit text and floating pt. numbers Transmit discrete I/O (on-off, open-closed)
Power and Signal on Same Pair? Yes (2-wire is possible) No (uses 4 wires)
Number Addressees per network 15 or 275,000,000,000(*) 63
Equality of Devices Master and Slave Devices equal but prioritized
Message Frame HART (UART-based) CAN
Possible Message Length Long Short but can be continued
Device Power Available Milliwatts to Watts Watts

(*) HART allows only 15 devices on a conventional current loop-type of network. 
But there are 275e9 possible addresses.

Table 2.3 — HART and DeviceNet Comparison

Suppose, however, that someone implementing DeviceNet needed to read the process variable of a HART flow meter?  A dedicated gateway between the two networks might be a possible way.  It might work like this:  At the DeviceNet side, the gateway looks like a DeviceNet Server (produces response) with Cyclic I/O Messaging at perhaps about once per second.  At the HART side it appears to the flowmeter as a HART Master.  Once each second it queries the flowmeter to get the process variable at the HART side and then transmits this variable to all consumers at the DeviceNet side.  At power up, the gateway device would go through the DeviceNet configuration, receive its assigned DeviceNet address, and become a publisher of information.  Then it would determine the address of the HART flowmeter in preparation to read the process variable.

    A dedicated gateway would probably be designed to work with more than one HART Field Instrument and would publish the process variable corresponding to each Field Instrument.


    HART Over RS485/RS232

    Conventional HART uses FSK modulation to translate the frequency spectrum to a region that is compatible with 4-20 mA.  In some applications where there is no current loop, the modulator and demodulator are simply removed and HART is transmitted as a baseband signal.  This is illustrated in figure 2.17 for RS232 and RS485 line drivers and receivers.  RS232 is more suited to communication between just two devices, while RS485 allows the construction of a network of several devices.  RS232 is limited to a distance of 50 feet (15 meter), per the standard.  RS485 allows up to several thousand feet (one or two km).

Figure 2.17 — Baseband HART Using RS232/RS485

    In both of these arrangements the message generated by the HART device is the same series of 11-bit characters that would normally be sent to a HART modem.  The bit rate can be 1200 bits/second as in conventional HART.  Or it may be higher.


    Combined Baseband and Conventional HART 

    A combination of baseband RS232/RS485 and conventional HART signaling is also possible.  When RS485 is used, it is possible to build a super HART network as illustrated in figure 2.18.

abou3_20.gif (6929 bytes)

Figure 2.18 — Super HART Network Using RS485

This super network can have 31 bridge devices (the limit for RS485) and 15 HART Field Instruments per bridge device, for a total of 465 Field Instruments.   Except for line turn-around time in the Bridge, all HART timing is preserved.  The considerations for the bridge device are similar to those for a repeater.

Telecom HART

    Since the HART signal band is essentially the same as the band available to voice signals in telephone networks, a telephone network can be used to transmit HART.  In the United States and Canada the HART FSK signal frequencies are OK as is.  In Europe or other countries that use CCITT standards, HART can still be used except that the frequencies must be changed to 1300 Hz (logic 1) and 2100 Hz (logic 0).  These frequencies are acceptable in the U.S. and Canada.   And, fortunately, most HART and Bell-202 modems will accept these two frequencies.   This leads to some simplification in an interface device. 

    A typical HART-over-phone-lines application is shown in figure 2.19.

abou3_21.gif (4157 bytes)

Figure 2.19 — Illustration of Using Telephone Network for HART

The computer and office modem constitute the HART Master.  The office modem is a standard Bell-202 or CCITT V.23 telecom modem.  There is no point in trying to adapt a HART modem at the office end, since commercially available telecom modems already have the desired certification and are directly compatible with the telephone network.  They just need to be set up to work with HART.  This is explained in more detail in a HART Application Note.

    When used with the Public Switched Telephone Network (PSTN) the computer and office modem can “call up” any number of Field Instruments.  The size of this network is virtually unlimited.  And, of course, there can still be up to 15 HART Field Instruments served by each Telecom-HART Interface, so that there can be up to 15 Field Instruments at each phone number.

    The “Telecom-HART Interface” is a necessary part of the scheme, since a process instrument isn’t directly compatible with the telephone network.  Even when a leased line is purchased from the phone company, direct connection of a process instrument isn’t advised because signal levels and impedances will not be correct.  If the process instrument is a 2-wire device, there is also the question of how to power it.  The Telecom-HART Interface provides the functions of figure 2.20.

abou3_22.gif (6621 bytes)

Figure 2.20 — Block Diagram of Telecom/HART Interface

The Interface consists of two signal paths (toward and away from the Process Instrument) and some logic (or microcontroller) to decide which path is active.   Deciding which path should be active is more than just sensing carrier detect.   Once a path is closed carrier appears at both ends.  Therefore, some form of state machine is desired.  One possibility is that both paths are normally turned OFF.  When both carriers are absent, the device goes to this (both paths OFF) first state.   If a telco carrier should become present and HART carrier is absent, the upper path is switched ON (second state).  If a HART carrier appears and the telco carrier is absent, the lower path is switched ON (third state).  If both carriers are present, the device simply maintains the last state (either second or third).

    At the start of a transaction the telco carrier will come ON and the upper path will become active.  As soon as the path becomes active, both carrier detects will be on and the upper path will remain active.  The Master will finish its transmission so that the telco carrier goes away.  At this point, the carrier at the HART side might also go away if there is no immediate reply by a HART Slave.  Then both paths would become inactive.  When the Slave finally replies, there will be a HART carrier and no telco carrier so that the bottom path will become active.  Another possibility is that after the telco carrier stops, the HART side carrier stays active because the HART Slave has already begun to reply.  Then the bottom path will be made active at the same time that the upper path becomes inactive.

    At the telephone end, the interface device provides a data access arrangement (DAA), so that the device may be legally connected.  Limiters in both paths control the amplitude of signals that are applied to the respective networks.   An entire modem is added if the device is to be used in Europe.  This modem accepts the HART signal frequencies of 1200 Hz and 2200 Hz and converts them to CCITT-compatible frequencies of 1300 Hz and 2100 Hz.

    A potential problem with trying to use conventional Master software in this telephone application is the delays in the telephone network.   When the Master sends out its command, it arrives at the interface device some time later.  The return trip is similarly delayed, so that Master software may time out, thinking that the Slave didn’t reply.  As much as half a second is possible, though not typical.  The Master software should be designed to take this into account.   Clearly, burst-mode, Master arbitration, and other conventional HART activities dependent on timing are probably impossible in this application.

    In this application (and probably others), the possibility of inadvertently turning on burst mode in a device must be carefully considered.  It is easy to turn burst mode on.  But because the network doesn’t support conventional HART timing, it may be impossible to turn burst mode off without a trip to the site of the bursting Field Instrument.  If this is a great concern, then it may be necessary to incorporate a micro-controller into the Interface and screen (filter) the HART commands.  But this greatly complicates the Interface and discards the convenience of a modulation method that is already compatible with phone lines.   A more reasonable approach is probably to control the Master software so that it never issues commands that would activate burst mode.


   Fiber Optic HART

    By combining inexpensive and powerful laser diodes (emitter) with efficient photodiodes (detector), enough power (about 4 mA at 12 volt) is produced to operate a parked HART Field Instrument.  The result is a point-to-point HART network with only optical fibers connecting the Field Instrument.  The scheme is illustrated in figure 2.21.

abou3_23.gif (2700 bytes)

Figure 2.21 — Fiber Optic HART Network

Everything except the Optical Fiber and Field Instrument are located in the control area.   A special interface built into the Field Instrument converts a conventional 2-wire HART Field Instrument to an optical Field Instrument.  This equipment and the services to retrofit Field Instruments are available from NT International [2.10].


    Single Modem/Multiple Point-to-Point

    A common situation is that of a HART user who has only point-to-point networks (one Field Instrument per network or per current loop) and wants to use one computer to talk to all of them.  The solution that comes to mind most quickly is to use multiple modems.  In fact, this is probably the only solution that is able to maintain the full protocol, including arbitration.   But, if we know that there will not be a need for the full protocol, another possibility is to switch a modem from one network (process loop) to the next.    The problem with this is how to do the switching.  Electromechanical relays probably aren’t the answer.  Semiconductor switches might create too much leakage current.  Another problem with switching is the need for the Master device to maintain a table of network  and device addresses.  That is, the Master must remember not only the Field Instrument address, but the network of that particular Field Instrument.  A possible solution that doesn’t involve switching and maintains the reliability and integrity of each process loop is that of figure 2.22.

wpe44.gif (9186 bytes)

Figure 2.22 — Single Modem Coupled To Multiple Point-to-Point Networks

Here, the individual networks are transformer-coupled to a single modem.  The modem is specially designed to have an impedance of zero or nearly zero, whether transmitting or receiving.  Zero impedance during receive serves two purposes:  (1)  It allows the modem to collect all of the signal from one of the Field Instruments instead of having the signal distributed (lost) to other networks.   (2) It relaxes transformer requirements by increasing the associated L/R time constant.   The coupler device is entirely passive and galvanically isolates the network from the modem.  The schematic of a single coupler is shown in figure 2.23.

wpe42.gif (2948 bytes)

Figure 2.23 — Coupler

The coupler is a 3-port device that can easily be designed for DIN-rail mounting.   Its resistance from controller port to Field Instrument port is very low, so that very little voltage drop is introduced into the loop.  There is also complete galvanic isolation of the current loop from the modem.

    Using the scheme of figure 2.22 one modem communicates with up to 15 networks (15 Field Instruments).  When the modem transmits, the transmission is seen by all of the Field Instruments and only one replies.  When the modem is receiving it must sense the current flow through its terminals.

    Some of the considerations in applying this method are:

    1.    The drive capability of the modem must be quite high, since it is sees the combined loads represented by
            up to 15 networks.

    2.    The modem must maintain a low impedance up to frequencies of about 5 kHz.  This becomes difficult in
            a trans-impedance type of amplifier arrangement.  A very wide-band amplifier may be needed.

    3.    The transformer is a critical component that must satisfy competing requirements of low resistance, high
            inductance, maintenance of inductance at DC of 20 mA, and small size and cost.  Most off-the-shelf
            transformers are not satisfactory in this application.  We have been able to get custom transformers
            from Midcom [reference] that fit this application.

    4.    Equalization is generally necessary in the modem to mitigate the combined effects of the transformer and
            networks (current loops).  The equalization may need to vary  to account for the possibility of
            from 1 to 15 current loops.  Using practical values for other circuit elements, the combination of these
            elements with the transformer creates a high-pass filter with corner frequency at or close to 1 kHz
            (low end of HART band).


    Wireless HART

    It seems lately that just about every form of communication is becoming wireless or has wireless as an option.  And, undoubtedly, HART or HART-like information is now being transferred by wireless.  But this is the result of gateways to HART and the use of non-HART protocols.  A wireless version of HART Protocol does not exist and probably won’t ever exist.  The reason is that HART Field Instruments would have to be equipped with radio transmitters.  (Or there might be one transmitter serving several Field Instruments.)  This, in turn, implies a relatively large expenditure of power — much more than is currently used in HART Field Instruments.  And, since the power must be made available anyway, one might as well opt for an existing wireless protocol instead of creating a new one.  In other words, once we depart significantly from the conditions that led to the creation of HART in the first place, then other solutions become more viable.  This applies not only to wireless, but to any of the proposed alternate versions of HART described above.

    A market for transmission of process variables via wireless apparently exists.  But, based on information from potential customers, the requirement is for distances on the order of 15 miles (24 km).  This immediately excludes virtually all of the recently developed spread-spectrum unlicensed techniques, which are limited to about 1 or 2 miles of reliable transmission.


Practical Stuff Part-I


Practical  HART — Part 1


Overview:   HART and The Conventional Process Loop

    HART is sometimes best understood by looking at how it evolved from a conventional process loop.  Figure 1.1 is a simplified diagram of the familiar analog current loop.  The process transmitter signals by varying the amount of current flowing through itself.  The controller detects this current variation by measuring the voltage across the current sense resistor.  The loop current varies from 4 to 20 mA at frequencies usually under 10 Hz.

Figure 1.1 — Conventional Process Loop

Figure 1.2 is the same thing with HART added.  Both ends of the loop now include a modem and a “receive amplifier.”   The receive amplifier has a relatively high input impedance so that it doesn’t load the current loop.  The process transmitter also has an AC-coupled current source, and the controller an AC-coupled voltage source.  The switch in series with the voltage source (Xmit Volt Source) in the HART controller is normally open.  In the HART Controller the added components can be connected either across the current loop conductors, as shown, or across the current sense resistor.  From an AC standpoint, the result is the same, since the Pwr Supply is effectively a short circuit.  Notice that all of the added components are AC-coupled, so that they do not affect the analog signal.  The receive amplifier is often considered part of the modem and would usually not be shown separately.  We did it this way to indicate how (across which nodes) the receive signal voltage is derived.  In either the Controller or the Transmitter, the receive signal voltage is just the AC voltage across the current loop conductors.

Figure 1.2 — Process Loop With HART Added

    To send a HART message, the process transmitter turns ON its AC-coupled current source.  This superimposes a high-frequency carrier current of about 1 mA p-p onto the normal transmitter output current.  The current sense resistor at the controller converts this variation into a voltage that appears across the two loop conductors.   The voltage is sensed by the controller’s receive amplifier and fed to the controller’s demodulator (in block labeled “modem”).  In practice the two current sources in the HART process transmitter are usually implemented as a single current regulator; and the analog and digital (HART) signals are combined ahead of the regulator.

    To send a HART message in the other direction (to the process transmitter), the HART Controller closes its transmit switch.  This effectively connects the “Xmit Volt Source” across the current loop conductors, superimposing a voltage of about 500 mV p-p across the loop conductors.  This is seen at the process transmitter terminals and is sent to its receive amplifier and demodulator.

    Figure 1.2 implies that a Master transmits as voltage source, while a Slave transmits as a current source.  This is historically true.  It is also historically true that the lowest impedance in the network — the one that dominates the current-to-voltage conversion — was the current sense resistor.   Now, with some restrictions, either device can have either a low or high impedance.  And the current sense resistor doesn’t necessarily dominate.

    Regardless of which device is sending the HART message, the voltage across the loop conductors will look something like that of figure 1.3; with a tiny burst of carrier voltage superimposed on a relatively large DC voltage.  The superimposed carrier voltage will have a range of values at the receiving device, depending on the size of the current sense resistor, the amount of capacitive loading, and losses caused by other loop elements.  Of course the DC voltage will also vary; depending on controller supply voltage, loop resistance, where in the loop the measurement is made, etc.

Figure 1.3 — HART Carrier Burst

    HART  communication is FSK (frequency-shift-keying), with a frequency of 1200 Hz representing a binary one and a frequency of 2200 Hz representing a binary zero.  These frequencies are well above the analog signaling frequency range of 0 to 10 Hz, so that the HART and analog signals are separated in frequency and ideally do not interfere with each other.  The HART signal is typically isolated with a high-pass filter having a cut-off frequency in the range of 400 Hz to 800 Hz.  The analog signal is similarly isolated with a low-pass filter.  This is illustrated in figure 1.4.

wpe35.gif (4165 bytes)

Figure 1.4 — Separation of Analog and HART (Digital) Signals

The separation in frequency between HART and analog signaling means that they can coexist on the same current loop.  This feature is essential for HART to augment traditional analog signaling.   Further information on the frequencies involved in HART transmission is given in the section entitled   HART Signal Power Spectral Density.     For a description of FSK and other forms of data/digital communication, see [3.5].

    For convenience, Figure 1.4 shows the Analog and HART Signals to be the same level.  Generally, this isn’t true.  The Analog Signal can vary from 4 to 20 mA or 16 mA p-p (unusual, but possible), which is vastly larger than the HART Signal.  This, in turn, can lead to some difficulties in separating them.

    HART is intended to retrofit to existing applications and wiring.   This means that there must be 2-wire HART devices.  It also means that devices must be capable of being intrinsically safe.    These requirements imply relatively low power and the ability to transmit through intrinsic safety barriers.  This is accomplished through a relatively low data rate, low signal amplitude, and superposition of the HART and analog signals.  Power consumption is further reduced through the half-duplex nature of HART.  That is, a device does not simultaneously transmit and receive.  Therefore, some receive circuits can be shut down during transmit and vice-versa.

    Intrinsic Safety and retrofitting to existing applications and wiring also explain why HART was developed at all, despite other advanced communication systems and techniques that existed at the time.  None of them would have met the low power requirements needed in a 2-wire 4-20 mA device.  Further information on intrinsically safe HART devices is given in the section entitled    HART and Intrinsic Safety    .

    In HART literature the process transmitter is called a Field Instrument or HART Slave Device.  (These terms will be used interchangeably throughout our presentation.)  And the current loop is a network.    The controller is a HART Master.  A hand-held communicator can also be placed across the network temporarily.  It is used in place of, or in addition to, the fixed controller-based HART Master.  When both types of Masters are present, the controller is the Primary Master and the hand-held unit is the Secondary Master.  (Note:  It becomes difficult to describe process devices in a data communication setting, because the terms transmitter and receiver have more than one meaning.  For example, a process transmitter both receives and transmits data bits.   We hope we’ve avoided confusion by providing sufficient context whenever these words are used.)

    HART now includes process receivers.  These are also called Field Instruments or HART Slaves and are discussed in the section entitled   Process Receiver.

Overview:  Signaling

    The HART signal path from the the processor in a sending device to the processor in a receiving device is shown in figure 1.5.  Amplifiers, filters, etc. have been omitted for simplicity.    At this level the diagram is the same, regardless of whether a Master or Slave is transmitting.   Notice that, if the signal starts out as a current, the “Network” converts it to a voltage.  But if it starts out a voltage it stays a voltage.

wpe39.gif (6397 bytes)

Figure 1.5 — HART Signal Path

    The transmitting device begins by turning ON its carrier and loading the first byte to be transmitted into its UART.  It waits for the byte to be transmitted and then loads the next one.  This is repeated until all the bytes of the message are exhausted.  The transmitter then waits for the last byte to be serialized and finally turns off its carrier.  With minor exceptions, the transmitting device does not allow a gap to occur in the serial stream.

   The UART converts each transmitted byte into an 11 bit serial character, as in figure 1.6.  The original byte becomes the part labeled “Data Byte (8 bits)”.  The start and stop bits are used for synchronization.  The parity bit is part of the HART error detection.  These 3 added bits contribute to “overhead” in HART communication.

Figure 1.6 — HART Character Structure

The serial character stream is applied to the Modulator of the sending modem.  The Modulator operates such that a logic 1 applied to the input produces a 1200 Hz periodic signal at the Modulator output.  A logic 0 produces 2200 Hz.   The type of modulation used is called Continuous Phase Frequency Shift Keying (CPFSK).  “Continuous Phase” means that there is no discontinuity in the Modulator output when the frequency changes.  A magnified view of what happens is illustrated in figure 1.7 for the stop bit to start bit transition.  When the UART output (modulator input) switches from logic 1 to logic 0, the frequency changes from 1200 Hz to 2200 Hz with just a change in slope of the transmitted waveform.  A moment’s thought reveals that the phase doesn’t change through this transition.  Given the chosen shift frequencies and the bit rate, a transition can occur at any phase.


wpe3A.gif (3912 bytes)

Figure 1.7 — Illustration of Continuous Phase FSK

A mathematical description of continuous phase FSK is given in the section entitled  Equation Describes CPFSK.

    The form of modulation used in HART is the same as that used in the “forward channel” of Bell-202.  However, there are enough differences between HART and Bell-202 that several modems have been designed specifically for HART.  Further information on Bell-202 is given in the section entitled    What’s In a Bell-202 Standard?

    At the receiving end, the demodulator section of a modem converts FSK back into a serial bit stream at 1200 bps.  Each 11-bit character is converted back into an 8-bit byte and parity is checked.  The receiving processor reads the incoming UART bytes and checks parity for each one until there are no more or until parsing of the data stream indicates that this is the last byte of the message.   The receiving processor accepts the incoming message only if it’s amplitude is high enough to cause carrier detect to be asserted.  In some cases the receiving processor will have to test an I/O line to make this determination.  In others the carrier detect signal gates the receive data so that nothing (no transitions) reaches the receiving UART unless carrier detect is asserted.


Overview:   HART Process Transmitter Block Diagram

    A block diagram of a typical HART Process Transmitter is given in figure 1.8.

wpe1E.gif (3782 bytes)

Figure 1.8 — Typical HART Process Transmitter Block Diagram

The “network interface” in this case is the current regulator.   The current regulator implements the two current sources shown in the “process transmitter” of figure 1.2.  The block labeled “modem”, and possibly the block labeled “EEPROM”, are about the only parts that would not otherwise be present in a conventional analog transmitter.  The EEPROM is necessary in a HART transmitter to store fundamental HART parameters.  The UART, used to convert between serial and parallel data, is often built into the micro-controller and does not have to be added as a separate item.

    The diagram illustrates part of the appeal of HART:  its simplicity and the relative ease with which HART field instruments can be designed.  HART is essentially an add-on to existing analog communication circuitry.  The added hardware often consists of only one extra integrated circuit of any significance, plus a few passive components.  In smart field instruments the ROM and EEPROM to hold HART software and HART parameters will usually already exist.


Overview:  Building Networks

    The type of network thus far described, with a single Field Instrument that does both HART and analog signaling, is probably the most common type of HART network and is called a point-to-point network.   In some cases the point-to-point network might have a HART Field Instrument but no permanent HART Master.   This might occur, for example, if the User intends primarily analog communication and Field Instrument parameters are set prior to installation.  A HART User might also set up this type of network and then later communicate with the Field Instrument using a hand-held communicator (HART Secondary Master).  This is a device that clips onto device terminals (or other points in the network) for temporary HART communication with the Field Instrument. 

    A HART Field Instrument is sometimes configured so that it has no analog signal — only HART.  Several such Field Instruments can be connected together (electrically in parallel) on the same network, as in figure 1.9.

wpe3B.gif (3729 bytes)

Figure 1.9 — HART Network with Multi-dropped Field Instruments

These Field Instruments are said to be multi-dropped.   The Master is able to talk to and configure each one, in turn.  When Field Instruments are multi-dropped there can’t be any analog signaling.  The term “current loop” ceases to have any meaning.  Multi-dropped Field Instruments that are powered from the network draw a small, fixed current (usually 4 mA); so that the number of devices can be maximized.  A Field Instrument that has been configured to draw a fixed analog current is said to be “parked.”  Parking is accomplished by setting the short-form address of the Field Instrument to some number other than 0.  A hand-held communicator might also be connected to the network of figure 1.9.

     There are few restrictions on building networks.  The topology may be loosely described as a bus, with drop attachments forming secondary busses as desired.  This is illustrated in figure 1.10.  The whole collection is considered a single network.  Except for the intervening lengths of cable, all of the devices are electrically in parallel.  The Hand-Held Communicator (HHC) may also be connected virtually anywhere.   As a practical matter, however, most of the cable is inaccessible and the HHC has to be connected at the Field Instrument, in junction boxes, or in controllers or marshalling panels.

wpe3C.gif (4301 bytes)

Figure 1.10 — HART Network Showing Free Arrangement of Devices

In intrinsically safe (IS) installations there will likely be an IS barrier separating the Control and Field areas.

    A Field Instrument may be added or removed or wiring changes made while the network is live (powered).  This may interrupt an on-going transaction.   Or , if the network is inadvertently short-circuited, this could reset all devices.   The network will recover from the loss of a transaction by re-trying a previous communication.  If Field Instruments are reset, they will eventually come back to the state they were in prior to the reset.  No reprogramming of HART parameters is needed.

    The common arrangement of a home run cable, junction box, and branch cables to Field Instruments is acceptable.   Different twisted pairs of the same cable can be used as separate HART networks powered from a single supply, as in figure 1.11.   Notice that in this example the 2nd network has two multi-dropped Field Instruments, while each of the other two networks shown has only one.

wpe3E.gif (6995 bytes)

Figure 1.11 — Single Cable With Multiple HART Networks

Circuit 1 in the diagram is connected to A/D converter 1 and Modem 1.  Circuit 2 is connected to A/D converter 2, Modem 2.  And so on.  Or else a multiplexor may be used to switch a single A/D converter or single Modem sequentially from Circuit 1 through Circuit N.  If a single Modem is used, it is either a conventional Modem that is switched in between HART transactions; or it could be a special sampled-data type of Modem that is able to operate on all networks simultaneously.

    HART networks use shielded twisted pair cable.     Many different cables with different characteristics are used.  Although twisted pair cable is used, the signaling is single-ended.  (One side of each pair is at AC ground.)   HART needs a minimum bandwidth (-3 dB) of about 2.5 kHz.  This limits the total length of cable that can be used in a network.   The cable capacitance (and capacitance of devices) forms a pole with a critical resistance called the network resistance.  In most cases the network resistance is the same as the current sense resistance in figures 1.1 and 1.2.  To insure a pole frequency of greater than 2.5 kHz, the RC time constant must be less than 65 microsecond.   For a network resistance of 250 ohm, C is a maximum of 0.26 microfarad.  Thus, the capacitance due to cable and other devices is limited to 0.26 microfarad.   Further information on cable effects is given in the section entitled  Cable Effects.

    Digital signaling brings with it a variety of other possible devices and modes of operation.  For example, some Field Instruments are HART only and have no analog signaling.  Others draw no power from the network.  In still other cases the network may not be powered (no DC).  There also exist other types of HART networks that depart from the conventional one described here.  These are covered in the section entitled  HART Gateways and Alternative Networks   .

Overview: Protocol

    Normally, one HART device talks while others listen.  A Master typically sends a command and then expects a reply. A Slave waits for a command and then sends a reply.  The command and associated reply are called a transaction.  There are typically periods of silence (nobody talking) between transactions.  The two bursts of carrier during a transaction are illustrated in figure 1.12.

wpe3F.gif (3370 bytes)

Figure 1.12 — Carrier Bursts During HART Transaction

    There can be one or two Masters (called Primary and Secondary Masters) per network.  There can be (from a protocol viewpoint) almost an unlimited number of Slaves.   (To limit noise on a given network, the number of Slaves is limited to 15.  If the network is part of a super network involving   repeaters, then more Slaves are possible because the repeater re-constitutes the digital signal so that noise does not pass through it.)

    A Slave accesses the network as quickly as possible in response to a Master.  Network access by Masters requires arbitration.   Masters arbitrate by observing who sent the last transmission (a Slave or the other Master) and by using timers to delay their own transmissions. Thus, a Master allows time for the other Master to start a transmission.  The timers constitute dead time when no device is communicating and therefore contribute to “overhead” in HART communication.  Further information on Master arbitration is available in the section entitled  Timing is Everything.

    A Slave (normally) has a unique address to distinguish it from other Slaves.  This address is incorporated into the command message sent by a Master and is echoed back in the reply by the Slave.  Addresses are either 4 bits or 38 bits and are called short and long or “short frame” and “long frame” addresses, respectively.  A Slave can also be addressed through its tag (an identifier assigned by the user).  HART Slave addressing and the reason for two different address sizes is discussed in more detail in the next section.

    Each command or reply is a message, varying in length from 10 or 12 bytes to typically 20 or 30 bytes.  The message consists of the elements or fields listed in table 1.1, starting with the preamble and ending with the checksum.

Part of Message Length in Bytes Purpose
Preamble 5 to 20 Synchronization & Carrier Detect
Start Delimiter 1 Synchronization & Shows Which Master
Address 1 or 5 Choose Slave, Indicate Which Master, and Indicate Burst Mode
Command 1 Tell Slave What to Do
Number Data Bytes 1 Indicates Number Bytes Between Here and Checksum
Status 0 (if Master)
2 (if Slave)
Slave Indicates Its Health and Whether it did As Master Intended
Data 0 to 253 Argument Associated with Command (Process Variable, For Example)
Checksum 1 Error Control

Table 1.1 — Parts of HART Message

    The preamble is allowed to vary in length, depending on the Slave’s requirements.  A Master will use the longest possible preamble when talking to a Slave for the first time.  Once the Master reads the Slave’s preamble length requirement (a stored HART parameter), it will subsequently use this new length when talking to that Slave.  Different Slaves can have different preamble length requirements, so that a Master might need to maintain a table of these values.

    A longer preamble means slower communication.  Slave devices are now routinely designed so that they need only a 5 byte preamble; and the requirement for a variable preamble length may  now be largely historical.

    The status field (2 bytes) occurs only in replies by HART Slave devices.  If a Slave does not execute a command, the status shows this and usually indicates why.  Several possible reasons are:

        1.    The Slave received the message in error.  (This can also result in no reply.)

        2.    The Slave doesn’t implement this command.

        3.    The Slave is busy.

        4.    The Slave was told to do something outside of its capability
                (range number too large or small, for example).

        5.    The Slave is write-protected and was told to change a protected parameter.

   A Slave Device will often be equipped with write-protect capability.  This is often implemented with a two-position shorting block on the device’s circuit board.  With the shorting block in the write-protect position, parameters can’t be changed.  A Slave that is commanded to change a protected parameter will not act on the command and will reply that it is write protected.

    Commands are one of 3 types:  Universal, Common Practice, and Device Specific (Proprietary).  Universal and Common Practice commands implement functions that were either part of an original set or are needed often enough to be specified as part of the Protocol.   Among the Universal commands are commands to read and write the device’s serial number, tag, descriptor, date; read and write a scratch memory area; read the device’s revision levels; and so on.  These parameters are semi-permanent and are examples of data that is stored in EEPROM.

    A Device Specific command is one that the device manufacturer creates.   It can have any number from 128 to 253.  Different manufacturers may use the same command number for entirely different functions.  Therefore, the Master must know the properties of the devices it expects to talk to.   The HART   Device Description Language   is helpful in imparting this information to a Master.   The command value 255 is not allowed, to avoid possible confusion with the preamble character.  The value 254 is reserved — probably to allow for a second command byte in future devices that may require a very large number of device-specific commands.

    The checksum at the end of the message is used for error control.  It is the exclusive-or of all of the preceding bytes, starting with the start delimiter.  The checksum, along with the parity bit in each character, create a message matrix having so-called vertical and longitudinal parity.  If a message is in error, this usually necessitates a retry.   Further information on HART error control is given below in the section   HART Message Errors.

    One more feature, available in some Field Instruments, is burst mode.  A Field Instrument that is burst-mode capable can repeatedly send a HART reply without a repeated command.  This is useful in getting the fastest possible updates (about 2 to 3 times per second) of process variables.  If burst-mode is to be used, there can be only one bursting Field Instrument on the network.

    A Field Instrument remembers its mode of operation during power down and returns to this mode on power up.  Thus, a Field Instrument that has been parked will remain so through power down.  Similarly, a Field Instrument in burst-mode will begin bursting again on power up.

    HART Protocol puts most of the responsibility (such as timing and arbitration) into the Masters.  This eases the Field Instrument software development and puts the complexity into the device that’s more suited to deal with it.

    A large amount of Protocol information, including message structure and examples, is given in [1.6].

Overview:  Addressing

   Each HART field instrument must have a unique address.  Each command sent by a Master contains the address of the desired Field Instrument.  All Field Instruments examine the command.  The one that recognizes its own address sends back a response.  For various reasons HART addressing has been changed a few times.  Each change had to be done in such a way as to maintain backward compatibility.  This has led to some confusion over addressing.   Hopefully, this somewhat chronological presentation will not add to the confusion.

    Early HART protocol used only a 4 bit address.  This meant there could be 16 field instruments per network.  In any Field Instrument the 4-bit address could be set to any value from 0 to 15 using HART commands.  If a Master changed the address of a Field Instrument, it would have to use the new address from then on when talking to that particular Field Instrument.

    Later, HART was modified to use a combination of the 4-bit address and a new 38 bit address.  In these modern devices, the 4-bit address is identical to the 4-bit address used exclusively in earlier devices, and is also known as a polling address or short address.  The 38 bit address is also known as the long address, and is permanently set by the Field Instrument manufacturer.  A 38-bit address allows virtually an unlimited number of Field Instruments per network.   Older devices that use only a 4-bit address are also known as “rev 4” Field Instruments.   Modern devices, that use the combined addresses, are also known as “rev 5” instruments.  These designations correspond to the revision levels of the HART Protocol documents.  Revision 4 devices are now considered obsolete.  Their sale or use or design is discouraged and most available software is probably not compatible with revision 4.

    So, why the two forms of address in modern Field Instruments?   The reason is that we need a way of quickly determining the long address.  We can’t just try every possible combination (2 to the 38th power).  This would take years.  So, instead, we put the old 4-bit address to work.  We use it to get the Field Instrument to divulge its long address.  The protocol rules state that HART Command 0 may be sent using the short address.  All other commands require the long address.  Command 0, not surprisingly, commands a Field Instrument to tell us its long address.  In effect the short address is used only once, to tell us how to talk to the Field Instrument using its long address.

    The long address consists of the lower (least significant) 38 bits of a 40-bit unique identifier.  This is illustrated in figure 1.13.  The first byte of the unique identifier is the manufacturer’s ID number.  The second is the manufacturer’s device type code.  The 3rd, 4th, and 5th are a serial number.  It is intended that no two Field Instruments in existence have the same 40-bit identifier.

wpe44.gif (5086 bytes)

Figure 1.13 — Unique Identifier and Long Address

    There is an another way to get a Field Instrument to divulge its long address:  By using its tag.  A tag is a 6-byte identification code that an end-user may assign to a Field Instrument.  Once this assignment is made, Command 11 will provide the same information as command 0.  But command 11 is one of those that require a long address.  This seems to present a chicken-and-egg dilemma:  We want to use command 11 to learn the long address.  But we need to know the long address to use command 11.  Obviously, there is a way around this.  It is to use a broadcast address.  The broadcast address has all 38 bits equal to zero and is a way of addressing all Field Instruments at once.  When a Field Instrument sees this address and command 11, it compares its tag against the one included in the command.   If they match, then the Field Instrument sends a reply.  Since there should be only one Field Instrument with a matching tag, only one should reply.

    The short address in either the older or modern Field Instruments has one other purpose:  to allow parking.  A parked Field Instrument has its analog output current fixed.  Usually it is fixed at some low value such as 4 mA.   Parking is necessary for multi-dropped instruments to avoid a large and meaningless current consumption.  A Field Instrument is parked by setting its short address to a value other than 0.  In other words, the short address of the parked Field Instrument can be any value from 1 through 15.

    Some HART-only Field Instruments have no Analog Signal and are effectively parked for any short address from 0 through 15.

    There are potential problems with the HART addressing scheme.   These are discussed in the section entitled  Addressing Problems, Slave Commissioning, and Device Database.

Overview:  Conclusion

    Although some of the details and variations are left out, this is basically how HART works.  The complete topology rules and device requirements are given in HART specifications, which are sold by the HART Communication Foundation [1.5].  The information presented here should not be considered a substitute for the actual specifications.  A current list of the specifications and their HCF designations is given in the section entitled   Table of Current HART Publications   .  Some circuit designs and more detail on selected HART topics are covered in the   HART Application Note.

Why So Slow?

    A common question or complaint about HART is its relatively low speed of 1200 bps.  In an age of DSL, HART is clearly a snail.   One has to keep in mind the time period in which HART was developed (early 1980’s) as well as the relatively small amount of available power in 4-20 mA analog instruments.  In the early 1980s, a 300 bps modem for a personal computer was considered pretty good.  And when 1200 bps modems came out, they sold for $500 to $600 each.  The power to run personal computer modems has always been watts.  The power to run a HART modem is often only 2 mW.

    Not only is there very little power available in analog instruments, but it keeps shrinking!  Demands for greater functionality keep shifting the available current into more powerful processors, etc.

    Some of the issues/problems involved in a higher speed HART are:

1.     Many of the protocol functions must be moved into hardware.  A single low-power
        microcontroller in a Slave device would otherwise be hard-pressed to keep up.

2.     Backward compatibility with devices/networks that run at the current speed and
        and use the existing bandwidth.  If the bit rate is to be higher than the existing
        bandwidth of 3 or 4 kHz, this generally means that spectrally efficient techniques
        are needed.  This loosely translates into complicated modulation methods and
        digital signal processing.   Thus, there is a quantum leap in current consumption.

3.     The cost of a larger and more complex HART chip.

4.    Burst type operation, which is used in HART becomes difficult to achieve at higher bit
        rates, because of the need for long equalization periods and other receiver start-up

The HART Communication Foundation has actively sought and invested in the development of a higher speed HART.  But so far the hardware has not materialized.

    For information on the theoretical upper speed limit for a HART network, see the section entitled   How Fast?

    Too see our proposal for a higher speed HART, click   here.


What’s In A Bell-202 Standard?

    If you’ve searched through the various Bell-202 Standards and wondered where the FSK modulation and the shift frequencies appear, the answer is they don’t.  Not even the bit rate of 1200 bps is stated, although it is the recommended upper limit for PSTN (dial-up lines).  The bit rate (1200 bps), type of modulation (CPFSK), and the shift frequencies (1200 Hz and 2200 Hz) are all de facto values used in Bell-202 modems.  Apparently, just as J.S. Bach never put dynamic markings in his music, believing that it would never be performed other than under his direction; Ma Bell never put in this vital information, thinking that she would forever have a monopoly on modems.


Process Receiver

    HART was originally conceived to augment process transmitters.  However, specifications were later revised to cover process receivers (typically valve positioners), as well.  Here, we will briefly examine the electrical characteristics of a HART process receiver.

    In a conventional process receiver loop, the controller generates a 4-20 mA current that is applied to (passed through) the process receiver.  The desired characteristic of the receiver is that it have an impedance of almost zero.   This is the opposite of the process transmitter, which ideally has infinite impedance.  Thus, the two types of Field Instruments are electrical opposites.

    To add HART communication to the process receiver loop, we could perpetuate the existing impedance situation and require high-impedance Masters and low-impedance Field Instruments.  This would require a new set of HART Masters that would transmit using a current source instead of a voltage source.  In fact there would be a duplication of most of the HART elements that already exist for process transmitter loops; and possibly a separate specification and separate products for process receiverdom.

    Another approach — a more practical one  — is to devise a process receiver with nearly zero impedance at DC and a high impedance at HART frequencies.  Using this approach, a single type of HART Master is able to talk to either a process transmitter or a process receiver.  It is easier to make such a HART process receiver if the “high impedance” doesn’t have to be too high.   About 300 to 400 ohm is about as high as it can easily go.  Since this is still relatively low, the HART specifications permit this device to set the network resistance.  That is, the impedance of this device at HART frequencies replaces the current sense resistor.  Note that a current sense resistor wouldn’t normally be present, anyway, in a process receiver loop.  The complete process receiver loop with HART components is shown in figure 1.14.  The frequency-dependent impedance in the process receiver is represented by the small graph of |Z| versus frequency.

Figure 1.14 — Process Receiver Loop Circuitry

Although the figure shows the transmit source in the process receiver as a current source, this could probably also be implemented as a switched voltage source.

    There are actually two types of process receivers.  The second type is electrically the same as a process transmitter, except that it draws a fixed current and the position is set by writing a setpoint with a HART command.  This allows the process receiver to be multi-dropped with other similar receivers or other HART devices.  There are also smart positioners that incorporate both types of HART interface for maximum versatility.

Other Books About HART?

    As far as we know there aren’t any.  A search of (on-line bookstore) turned up nothing.  The Instrument Society of America (ISA) publishes a variety of books on process control, but has nothing with “HART” in the title.   The  Virtual HART Book  is a catalog of HART products.

    The entire field of data communication in process plants and on the factory floor began in the 1980s.  There is a book entitled “Industrial Data Communications: Fundamentals and Applications” – Second Edition, 1997; that appears to deal with several different networks, including HART.  Undoubtedly, there will be others of a general nature that examine and compare the various types of communication that have become available.

Alternatives To HART

    There is no exact alternative to HART in the sense of a competing open standard that augments analog signaling in an industrial process control setting.  There are, however, similar proprietary methods that have been developed by companies such as Honeywell, Foxboro, and Elsag-Bailey.  There are also many process control devices advertised that have RS232 and/or RS485 ports built-in, along with proprietary protocols, for the purpose of configuration, calibration, etc.

    The H1 Physical Layer (Voltage Mode Low Speed) of Foundation Fieldbus [1.7] is an open standard for process control instruments that supports only digital signaling.  It is similar to HART in its support of 2-wire Field Instruments and its superposition of signal onto the DC instrument power.  Its raw data rate at the Physical Layer is 31.25 kbits/second — much higher than HART.   However, it also has much higher overhead so that a full 26X increase in transaction rate is not realized.  A much higher level of circuit integration and far more software are generally needed to support it.  At present Foundation Fieldbus devices typically use 3 to 5 times as much power as HART devices.  The network topology of Foundation Fieldbus is similar to HART but more restricted.


Table of Current HART Publications

Document Number Title
HCF-SPEC-11 HART – Smart Communications Protocol Specification
HCF-SPEC-54 FSK Physical Layer Specification
HCF-SPEC-81 Data Link Layer Specification
HCF-SPEC-99 Command Summary Information
HCF-SPEC-127 Universal Command Specification
HCF-SPEC-151 Common Practice Command Specification
HCF-SPEC-183 Common Tables
HCF-SPEC-307 Command Specific Response Code Definitions
HCF-SPEC-500 HART Device Description Language Specification
HCF-SPEC-501 Device Description Language Methods Builtins Library
HCF-SPEC-502 Device Description Language Binary File Format Specification
HCF-TEST-1 HART Slave Data Link Layer Test Specification
HCF-TEST-2 HART Physical Layer Test Procedure
HCF-TEST-3 HART Universal Application Layer Conformance Tests
HCF-PROC-1 HCF Entity Control Procedures
HCF-PROC-12 HCF Quality Assurance Program
HCF-LIT-1 Application Layer Guideline on Building HART Commands
HCF-LIT-2 NCR 20C12 Modem Application Note:  A HART Master Demonstration Circuit
HCF-LIT-3 NCR 20C12 Modem Application Note:  A HART Slave Demonstration Circuit
HCF-LIT-5 Application Layer Guideline on HART Status Information
HCF-LIT-8 Data Link Layer Slave, Structured Analysis
HCF-LIT-9 Data Link Layer Master, Structured Analysis
HCF-LIT-11 HART Slave Library Software Design
HCF-LIT-14 NCR20C15 Modem Application Note:  A HART Master Demonstration Circuit
HCF-LIT-15 NCR20C15 Modem Application Note:  A HART Slave Demonstration Circuit
HCF-LIT-17 HTEST Application Manual, HART Master Simulator
HCF-LIT-18 Field Device Specific Specification Template
HCF-LIT-21 HART Communication Foundation Tokenizer User Guide
HCF-LIT-24 HART Telecommunications Guideline

Table 1.2 — HCF Publications


What is HART?

HART (“Highway Addressable Remote Transducer”) is a popular digital communication protocol designed for industrial process measurement applications. The original and still most widely used version is the frequency shift keyed (“FSK”) version. The special feature of this is that it uses a low-level modulation superimposed on the standard 4-to-20 mA current loop which has been widely used for such measurements. Because the HART signal is small, and composed of sine waves, its average value is zero and does not significantly affect the accuracy of the analogue current signal, which can therefore still be used. This provides compatibility with existing systems, while allowing simultaneous digital communication for device configuration, status checking, diagnostics and so forth.

Later specifications cover a higher-speed 9600 bps option, and HART rev. 7 includes WirelessHART™, which offers high-speed short-range radio network functions using the 2.4GHz ISM band.

The signal of FSK HART looks like this:

HART signal

The HART message structure

The structure of the FSK HART message is shown below:

HART message structureThe preamble, of between 5 and 20 bytes of hex FF (all 1’s), helps the receiver to synchronise to the character stream.

The start character may have one of several values, indicating the type of message: master to slave, slave to master, or burst message from slave; also the address format: short frame or long frame. Since HART rev. 6, it also indicates the number of bytes in the “expansion” field (see below).

The address field includes both the master address (a single bit: 1 for a primary master, 0 for a secondary master) and the slave address. In the short frame format, the slave address is 4 bits containing the “polling address” (0 to 15). In the long frame format, it is 38 bits containing a “unique identifier” for that particular device. (One bit is also used to indicate if a slave is in burst mode.)

The expansion field allows for up to 3 additional bytes to be inserted between the address and command fields. The number of bytes present will be indicated by bits 6 and 5 in the start delimiter. Use of this feature, introduced in HART rev. 6, is as yet undefined.

The command byte contains the HART command for this message. Universal commands are in the range 0 to 30; common practice commands are in the range 32 to 126; device-specific commands are in the range 128 to 253. HART rev. 6 introduced 16-bit “extended commands” for device family commands. These put 31 (hex 1f) in this byte, and the 2-byte command number as the first 2 bytes in the “data” field.

The byte count byte contains the number of bytes to follow in the status and data bytes. The receiver uses this to know when the message is complete. (There is no special “end of message” character.)

The status field (also known as the “response code”) is two bytes, only present in the response message from a slave. It contains information about communication errors in the outgoing message, the status of the received command, and the status of the device itself.

The data field may or may not be present, depending on the particular command. Universal and common-practice commands use up to 33 bytes of data, keeping the overall message duration reasonable. (But some devices have device-specific commands using longer data fields.) See also the HART data field.

Finally, the checksum byte contains an “exclusive-or” or “longitudinal parity” of all previous bytes (from the start character onwards). Together with the parity bit attached to each byte, this is used to detect communication errors.

Uses of HART

Using HART digital communication, up to four measurements (or more) can be transmitted in a single message. Multivariable instruments have been developed to take advantage of this. In addition, when using only digital communication, several instruments can be connected in parallel “multidrop” on a single pair of wires (with their analogue currents each set to a minimum value, usually 4 mA). Each device has its own address, so a host can communicate with each one in turn.

HART was developed by Rosemount Inc in the mid-1980’s, but has been made completely open, and all rights now belong to the independent HART Communication Foundation, which supports the protocol and oversees further development.

There are now upward of 200 member companies in the HCF, most of whom have HART products on the market. Virtually all measurement types are available, also valve positioners. A number of DCSs and PLCs provide HART-compatible inputs, so they can check device status, and read multiple measurements from a single field instrument.

Revisions of the HART protocol

The current revision of the HART protocol specification is 7.1. All new field devices and hosts should follow this revision. But what came earlier? And what should you do about it?


In the mid-1980s, Rosemount Inc. developed a proprietary digital communication protocol for their smart field instruments. This soon evolved into HART, and was made an open protocol with Revision 2.1 in 1986. Since then, the capabilities of the protocol have been enhanced by successive revisions to the specification, including new commands, additional manufacturer and engineering units codes, protection against cross-reception of messages and improved reporting of command errors.

This note summarises the major changes that have been made, and suggests how instrument and host designers should treat them. Users may also be interested to ensure that the host equipment they use can operate properly with the field devices they have. As always, refer to the full specifications from the HART Communication Foundation, for more details.

Major revisions

The main changes were:

Revision Date introduced Features



First public specification. Commands #0 to #6, #33 to #48.



New command #49.



Improved support for multiple variables. Write-protect status. Optional type-code expansion. New commands #50 to #56.



Long frame format, unique identifier. Burst mode. Block commands #4 and #5 replaced by new commands #12 to #18. New commands #11 to #19, #57 to #59, #108 to #112. Improved data link and physical layer specifications.



Support for multiple analogue outputs and non-current analogue outputs. New commands #60 to #70, #107.



Physical layer specification revision 7.2



Major enhancements … Long tag (32 characters). Better support for multivariable devices and actuators. More device and variable status information. Device families, with commands in the range #1024 to #33791. Block data transfer. New commands #7, #8, #20 to #22, #71 to #75, #79 to #83, #106, #111, #112. Many other commands extended. C8PSK physical layer option. Most specs re-written for clarity.



16-bit manufacturer ID.



Major enhancements … WirelessHART™. New general-use commands #77, #84 to #104, #512, #513. New WirelessHART commands in the range #768 to #1023. Many commands extended. Trend data. New data type: time. Publishing on exception. Command aggregation. More status information. Commands #38 and #48 become Universal.



Extensive document corrections and clarifications.

With each revision, many of the common tables were extended, for example to accommodate more codes for manufacturers, units and materials. Revisions 5.0, 5.1 and 5.2 included better specifications for the HART physical layer, to assure better reliability and compatibility.

From Revision 5.0 onwards, changes have maintained compatibility with older devices. New commands have been added (never removed) and data fields of existing commands have been extended (never shortened). But this was not always so. In particular, Revision 4 introduced the manufacturer identification code, and the step from Revision 4 to Revision 5 brought significant changes in device addressing. Revision 7 brings WirelessHART networking and many other enhancements. Some of these changes are described below.

Expanded device type code

In HART Revision 4, an option was introduced to allow manufacturer and device type to be coded separately, instead of as a combined 8-bit number. To indicate that this expanded form is used, a field device inserts “254” (hex FE) as the first data byte in its response to command #0. Then the next two bytes contain the manufacturer and device type codes. The expanded form continues in HART Revisions 5 and 6.

In HART Revision 7, the popularity of HART has resulted in further modification to this scheme. The manufacturer ID is now 16 bits instead of 8 (and is reported in an extension of the Command #0 data) and the “expanded device type code” remains at 16 bits but no longer includes the manufacturer ID as an identifiable part. This code is now allocated by the HCF for each new field device (starting at hex E080). Pre-HART 7 devices are unaffected by this change, retaining their existing 16-bit expanded device type codes. (The “254” indicator is still required.)

The long frame address format

HART Revision 5 introduced the long frame format, including a “Unique Identifier” (Unique ID) as part of the device address in each message. This Unique ID is formed from a concatenation of the expanded device type code and a device ID number. The device manufacturer must ensure that the device ID number is unique, for each device having a particular device type code. It is rather like a serial number, but doesn’t have to be the same as the serial number on the label. The complete Unique ID is (almost) world-wide unique for every HART device.

The advantage of this address format is that the wrong device never accepts a communication (even if signals are coupled between different HART loops due to poor installation).

Since security is now assured by the Unique ID, the previous requirement, that any device-specific command must include the device type code as its first data byte (in both command and response), is cancelled as from HART Revision 5. In moving from Revision 4 to Revision 5, existing field devices must drop that first byte from their data field specifications.

Command #0

For new devices, the only exception to the use of the long address form is Command #0. In Revision 5 (and above) a field device must support both short and long frame address forms of this command, so that a host can start communication with a field device without knowing its Unique ID. The response to command #0 includes the necessary data items for the host to construct the Unique ID.

Commands #4 and #5

In HART Revision 4 and earlier, commands #4 and #5 were used to read and write certain device data (called “common static data”) including tag, descriptor, date, message, and device range and transfer function information. These commands used a “block number”, 0 to 3, to select particular sets of data. In HART Revision 5, these are replaced by commands #12 to #18, abandoning the rather clumsy “data block” paradigm.


HART Revision 7 introduces WirelessHART, a low-power wireless technology providing a mesh network operating in the unlicensed 2.4GHz ISM band with ranges up to around 200m between devices. The mesh structure means that communication paths from a field device to a Gateway can be redundant, and self-healing in the event of a communication problem or fault.

The required network management functions are provided by additional Network and Transport protocol layers, and use a new TDMA (Time Division Multiple Access) Data Link Layer to replace the Token Passing of FSK HART. Many of the new commands in HART 7 are primarily designed for the wireless network, but can also improve the flexibility and performance of wired FSK HART.

Battery or solar power are potentially valuable options, allowing field devices to be placed in locations where cabling is difficult or impossible.

What must you do to be compatible?

Field device designers

Field device designers must implement HART Revision 5 (or later), using the long frame address format. The device must also support Command #0 in both short and long frame forms.

Host designers

Host designers should fully support HART Revision 5 or later. But you also have a decision to make: will you support older devices?

If you intend your host only to be used with new field instruments, then there is no need to support anything before HART Revision 5. But if you want to attach to existing field devices, or your user may have older devices as spares, you should consider supporting Revisions 3 and 4. There are quite a lot of pre-1989 instruments out in the world. At the very least, you should detect that you have connected to a Revision 3 or 4 device, and report this in a friendly manner to your user. Otherwise there may be a long and pointless argument about why communication isn’t working.

Host software: how to begin communication

The procedure when first connecting to a field device can be as follows:

  • Send command #0, with short frame format and 20 preambles. Start with polling address 0, then if multidrop operation is a possibility, try addresses 1 to 15 in turn.
  • Look at the data in the reply. Check for “254” in the first byte (byte 0); if it is there, the reply is using the expanded device type scheme, with one byte each for manufacturer and device type. (This affects the location of subsequent bytes in the data field.)
  • Look at the “number of preambles required” in byte 1 (un-expanded) or byte 3 (expanded). Use at least this many preambles in future outgoing messages.
  • Look for the HART Revision (“universal command revision”) in byte 2 (un-expanded) or byte 4 (expanded).
  • If the HART Revision is 5 or above, pick out the expanded device type code and device ID number, and build the complete 38-bit Unique Identifier. (Remember that the most-significant 2 bits of the expanded device type code (that is, the manufacturer code in revisions 5 and 6) are not used; you mustmask them off.) Then use the long-frame format and Revision 5 commands for future transactions.
  • If the HART Revision is 4 or below, continue communication using the short-frame format and Revision 4 commands. (Use commands #4 and #5, if you need them, instead of #12 to #18). Or, if you do not support HART Revision 4, report the fact to your operator. (Don’t just say “Device not found” or “Communication failed”!)


Hosts are recommended to try three times before giving up, if communication is expected but fails. It may be helpful to use 20 preambles for retries.

Other compatibility issues

Future extensions

In future revisions of the protocol, it is always possible that the HART Communication Foundation may add further items to the data field of any universal or common practice command. And in later revisions of a field device, the device manufacturer may add further items to the data field of an existing device-specific command. (Removing a data item, or changing its meaning, is not allowed.) To allow for such extensions, a field device or host should always take note of the “byte count” field in every message received, and expect to receive that many bytes of data before the checksum byte. It is then quite in order to ignore any bytes beyond those that you understand.

The HART common tables (unit codes, etc.) are also liable to extension in future revisions, but nothing is ever deleted. If a host uses the latest versions, it is quite possible that an older field device may reject a code value sent to it; the host should accept this and show a helpful message to the operator. Conversely, a new field device may report a code value that an older host does not recognise; the best thing to do is to display the un-decoded value with a polite message.

Refer to the HCF-SPEC-99 for the full compatibility rules.

HART Revision 2, 3 and 4 field devices

Early Rosemount and Micro Motion instruments using HART revisions 2, 3 or 4 include:

Instrument Rev 2 Rev 3 Rev 4 Rev 5
1151S Y Y Y Y
3001C     Y Y
3001L Y     (obsolete)
3044     Y (obsolete)
3051 Y Y   (obsolete)
3051C     Y Y
8712   Y Y Y
9712     Y Y

(If anybody knows of others, please let me know.)

Users! The model 268 and 275 handheld communicators support these older revisions. But some host software doesn’t. (If in doubt, ask your host supplier.) If you want to find out the HART revision of your instruments, to be sure you won’t have a problem:

  • Connect your 268 or 275 HART Communicator (you dohave one, don’t you?).
  • Scan down the Review menu (a dedicated button on the 268, or Online/Device Setup/Review on the 275).
  • With the 268, find “Software rev. x.y.z. “x” is the HART Universal Command Revision.
  • With the 275, find “Universal rev.”

HART measurement variables, ranges and status

The primary variable (PV) of a HART measurement device is available both as a digital value, by HART communication, and as an analogue (usually 4-to-20 mA) signal. In fact, there are two representations of the PV in digital form: in engineering units (by Command #1 or Command #3 and others); and as a percent of range (by Command #2). In addition, the actual analogue output current in milliamps can be read by HART Command #3. Every HART message from the field device includes status information, in the form of 8 bits with pre-defined meanings, including two which describe the present state of these various representations of the measurement.

This note attempts to clarify the way in which these representations work when the measurement is out of range, and how this is indicated by the status bits. The preferred effect of a detected device failure on the analogue output is also described (though this is not part of the HART specification). The diagram below gives an overall picture.

Variable ranges and statusFirst, let’s make clear the meanings of the various HART range parameters :

LRV and URV are the Lower Range Value and Upper Range Value, the two values of the PV which are to be represented by 4 mA and 20 mA respectively. You might have called these the “zero” and “full scale” (or possibly “span”) of a conventional analogue transmitter (though “span” should really mean the difference between the two). In general terms, this is the “range” of the instrument.

LSL and USL are the Lower Sensor Limit and Upper Sensor Limit. These describe the range over which the sensor works properly. Outside this range, the measurement may be unreliable.

A HART instrument digitises the sensor output over at least the range from the LSL to the USL. (If it doesn’t cover the full possible possible range of the sensor, then the range it does cover becomes the LSL and USL for the instrument as a whole.) This digitised value, once it has been converted, corrected, linearised or whatever, becomes the digital form of the PV. That is to say, the digital PV accurately represents the physical measurement over this range: LSL to USL.

Of course, the analogue signal cannot cover this whole range. It accurately represents only the range between the LRV and URV, with a small linear over-range allowance (typically from -0.6% to +105% of range).

It is common practice to indicate a detected device failure by forcing the analogue current value to a value outside the normal range, high or low by user choice, so that a control system can both respond safely, and (if set up with suitable alarm thresholds) can indicate the event to the operator. (This is not part of the HART specification, but is obviously a good idea, even for HART devices, since many hosts only use the analogue signal and do not make use of the HART status information.) For a discussion of this, see “Fault indication in Smart transmitters”.

So, looking at the diagram …

First, notice that the PV in engineering units can be read by commands #1 and #3, and is valid over the whole sensor range, irrespective of the analogue output range. The PV may also give useful (though maybe inaccurate) values beyond this range, or may indicate “not-a-number”.

Second, notice that the PV in “percent”, read by command #2, is also valid over the whole sensor range, although this may take its value far outside the range 0 to 100%. As a floating point variable, this is no problem. Beyond the sensor range (as for the PV in engineering units), the percent value may continue to be given or may be replaced by “not-a-number”.

However, the analogue output itself, and its digital value in milliamps read by command #3, is restricted to the configured analogue output range, plus the small allowable linear over-range from say 3.9 to 20.8 mA. In the event of a device malfunction, both analogue and digital values will be set outside this range, typically at 3.75 or 21.6 mA (depending on the configured choice of down-scale or up-scale fault indication). These are typical values used by a well-known transmitter supplier. NAMUR has recommended slightly different values (see “Fault indication” below).

Now, consider the status indicator bits …

If the measurement is outside the sensor limits, the “PV out of sensor limits” bit is set.

If the measurement is outside the linear analogue output range (LRV – 0.6% to URV + 5%), the “analogue output saturated” bit is set.

If a failure has been detected, the “device malfunction” bit is set.

Incidentally, it is not usually permitted to set the LRV or URV analogue output range values outside the LSL and USL sensor limits. The LRV can, however, often be set above the URV, to configure a reverse-acting analogue output.

Fault indication in Smart transmitters

One of the features of smart field devices is their ability to detect faults, either in the device electronics or in an associated sensor. Using HART, such faults are reported in the device status byte in every message (assuming that communication is still possible!). But, for the benefit of systems not using HART communication, it is still useful to follow the convention of indicating fault conditions by setting the analogue output current to a value which is recognisably beyond the normal operating range (including the small amount of linear over-range commonly allowed). If it is still alive, the microprocessor program should set the current output value to an appropriate value. Otherwise, a watchdog timer circuit may be able to do this, even if the microprocessor itself has failed. The intention is that a host system should be able to set alarm thresholds just outside the normal 4 mA to 20 mA range, to indicate measurement out-of-range, and to set further alarm thresholds to indicate a fault condition.

NAMUR Recommendation NE43 (18.01.1994) suggests the following:

  • Measurement valid from 3.8 mA to 20.5 mA.
  • Fault indicated by <=3.6 mA or >=21.0 mA.

However, not all instrument manufacturers follow the NAMUR recommendation. In particular, the 3.6 mA downscale fault indication value is regarded as difficult to implement in a smart transmitter, where every microamp of current consumption is carefully accounted for to support the demands of the microprocessor and sensor circuitry. One well-known supplier typically uses the values:

  • Measurement valid from 3.9 mA to 20.8 mA.
  • Fault indicated by <=3.75 mA or >=21.6 mA.

Fortunately, alarm threshold levels can be chosen which accommodate both these sets of values. A host system can set out-of-range alarm thresholds at 3.95 mA and 20.3 mA, and can differentiate between an out-of-range measurement and a fault, by further alarm thresholds at 3.78 mA and 20.9 mA.

In percent of range terms, these thresholds are -0.3% and +101.9% for out-of-range, and -1.4% and +105.6% for a fault. But remember to check that the values you use match the values actually used by your instrument supplier, if they don’t follow NAMUR.

HART cable lengths: H-Sim

The HART protocol is designed to work over existing analogue signal cables. But there are limits to how far it can go. The length of cable which can be used reliably depends on several factors. The main ones are:

  • Loop load resistance
  • Cable resistance
  • Cable capacitance
  • Number and capacitance of field devices
  • Resistance and position of other devices in the loop.

Essentially, the requirement is that the network should pass the HART signal frequencies (1200 and 2200 Hz) without too much loss or distortion. The two main causes of loss are resistance (causing loss at all frequencies) and capacitance (causing loss at higher frequencies).

HART signal levels and receiver thresholds are specified in such a way as to allow for some loss, down to 0.66 of the current signal from a field device to a minimum-load master, or down to 0.3 of the voltage signal from the master to a field device.

As well as having sufficient signal amplitude, it is important that the two different frequencies making up the HART signal should be passed more or less equally well, to avoid phase distortion which could make the signal hard to decode. To assure this, the bandwidth of the network should be at least 2500Hz. This is the basis of the “65-microsecond rule”, which says that the product of the network resistance and capacitance should be less than 65 microseconds.

To determine the signal loss in a real network is easy enough, using an oscilloscope to inspect the actual signal levels. But to predict it in advance is not so easy. H-Sim is a Windows (3.0 or higher) program which solves a set of equations, representing a simplified model of a HART communication network. You may therefore find H-Sim useful in helping you design HART networks. However, you must ensure that the representation is adequate for your application. The User Manual gives full information about the equations and the circuit model.

You can use H-Sim to predict the signal level for a particular cable type and length, or to calculate the possible cable length which will still give a desired signal level. You should also apply the 65-microsecond rule to ensure that the network bandwidth is adequate. (A future version of H-Sim may include this check.)

H-Sim takes account of shunt diode (“zener”) barriers used in intrinsic safety (IS) applications, but does not deal with IS networks using active isolators or repeaters.

H-Sim is copyright, but the current version, H-Sim 0.5, is offered here free of charge.

When it’s running, the main screen looks like this:

H-Sim 0.5 main screenBefore

Now …

  • Download HSIM05.EXE now into an empty directory.
  • Check the file size. It should be 294,468 bytes. If it’s wrong, the download failed; try again.
  • Run it, which expands it into the full H-Sim file set, in the same directory.
  • Then run SETUP.EXE, which installs H-Sim and its associated files into another directory of your choice (C:\HSIM is the default, but you can choose something else).

The README.TXT file gives further information about installation. (The README file assumes you have H-Sim on a floppy disk, but you can just as well install it from its download directory on a hard disk, to another directory on the same or another hard disk.) After you have installed H-Sim successfully, you could well delete the download directory and all its contents.

The User Manual is included, as a Write document. You are strongly encouraged to print it out and read it!

By all means return the full registration form in the User Manual eventually, as well, and let me know how you find the product. E-mail is fine for that too, of course.

If you have any difficulty with downloading or installing H-Sim, please e-mail me.

New revisions of H-Sim will also appear here from time to time.

The HART data field

There has been some confusion about the length of the HART data field. An old version of the Data Link specification gave a 25-byte limit, but that document was withdrawn, and the current specifications apparently do not specify a maximum length.

The first and second editions of my “Technical Overview” booklet mention a 25-byte limit in several places, but this is wrong. As it says in the Preface, you should never regard the booklet as definitive!

Up until HART Revision 5, the Universal and Common-Practice commands have conformed to this limit, and most device designers have restricted themselves to 25 bytes or less for their Device-Specific commands. However, there do exist devices with Device-Specific commands using much longer messages for special purposes. The design of a general-purpose host may need to take account of this possibility.

HART Revision 6 includes new Universal Commands 20, 21 and 22 (using the new 32-character Long Tag) with data fields of 32 bytes (plus the two status bytes in a response). Also, remember that it is quite legal for the data field of any command to be extended in future revisions. Although slave devices are not required to understand any additional data bytes, they should either allow spare message buffer space, or use the byte count to track incoming data bytes, up to the check byte, so as to accept and check a message with an extended data field properly.

The protocol itself is unable to support more than 255 bytes in the data field, since the byte count has to be stated as a one-byte number (and this includes the two status bytes in a “response” message).


URL Destination The HART Communication Foundation: the not-for-profit support organisation which owns the registered trademark “HART”, and all rights to the protocol itself. Provides information and support for vendors and users. You can download an “Application Guide”. The HART Book – the web version of the printed magazine “The HART Book”. An extensive list of available products and suppliers. Also a reference section including an interesting and useful article on calibrating HART field instruments Rosemount Measurement Division: the originator of the HART protocol. Probably still offers the widest range of HART products Analog Services have a large Technical Library section, including a 3-part article About HART and a useful Application Note on the design of HART devices Smar have information on HART, FOUNDATION Fieldbus and Profibus, including a general 6-page HART tutorial, downloadable as a PDF file Pittsburgh Supercomputing Center has a good explanation of the IEEE754 floating point data format