We have a Loop Powered Transmitter with an AD5451 and AD5700 combination
(HART), driven by a small microcontroller.
All works nearly fine, the DAC (AD5451) has no problem, and also the AD5700 can
send and receive. We testing with a HART-Commubox FXA195 from Endress&Hauser.
Only on the receiving side we have a problem. Receiving one byte, the AD5700
delivers 'two' bytes instead of one. That means, the first byte is correct, and
the seconds bytes consists of one to three pulse (not even a half bit long).
The CD-signal is still high in this case.
Of course, the UART of the processor interprets this as a second byte (with a
Recording and watching the HART-IN signal, the signal seems to stop correctly,
that means, two or three oscillations after the last (correct) bit. The
disturbing pulses appear some 'bits' later (~1ms), when the oscillation has
allready stopped for at least a millisecond. So as far, all looks fine except
those annoying short pulses, we don't find any reason for.
Belonging to the HART-protocoll: I tested very simply only on the
physical layer, no protokoll. I’m sending just ASCII-characters via a terminal
programm and each is character is immediately echoed, so you see, what you
send. That means, after each character, the modem has to change from receiving
to sending. That might be a problem for the modem, but should actually not
(with every other driver as RS485, this works fine). But of course, that mode
doesn’t follow any HART-protokoll. It is just a simple test.
From the plots provided and also the textual description, it sounds like the
messages being sent/received are not following the HART protocol – i.e. no
preamble synchronization information? 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.
Here is a link (http://www.analogservices.com/about_part2.htm#Start-Up
Synchronization in HART) to a better explanation of the HART preamble
synchronization technique, which is a fundamental part of the use of the HART
protocol. I hope this will be useful in clearing up the issue of the HART
interface versus the
ASCII-character echo test that you are trying to implement. The main idea is
the use of 0xFF with odd parity to identify the start of a message as
illustrated by the diagram below. Basically, 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 described in the tutorial page.