• State
  • Replies 3 replies
  • Subscribers 46 subscribers
  • Views 95 views
  • Users 0 members are here
Support feedback
Options
Options
Related

DAC8740H: HART demodulation to UART has framing errors

Nico Hoppe
Prodigy 10 points
Part Number: DAC8740H

Tool/software:

Hello,

I'm building a HART field device (DUT) using the DAC8740H with UART. The Hardware is similar to the reference design Figure 34 in the datasheet (page 33).

I'm using a certified USB HART modem as a host which transmits HART FSK signals to the DUT. The Signal contains UART8O1 data. The error occurs on the last bytes 4 UART8O1 packages (last 4 bytes: 0xa3d70ac2).
However the UART signal on the DUT from the DAC8740H to the MCU has a lot of framing errors. Measuring the FSK signal with an oscilloscope shows me a correct signal:

C1 is the UART from the DAC8740H, M4 is the FSK measured between DAC8740H and C7 from the reference design. However M4 is delayed so that it is synchrone with the UART.

C2 is the FSK modulated on the 24V before the C7 and C4 is the FSK between DAC8740H and C7 without the delay.

When you look at the stop bit you can see a 1.2kHz FSK signal wich would translate to a high signal. Is this a problem with the modem? Has anyone else this problem?

Kind regards,

Nico

  • 0
    TI__Guru* 97805 points

    Nico,

    I looked at the plot, and it does look like the stop bit is misinterpreted. It looks like this is the 0xd7 byte transmission of the last four 0xa3d70ac2 that you had mentioned. Admittedly, I don't know what this yet. 

    Can you provide a schematic of your setup? I think just the DAC8740H part of it would be fine. Just to be clear, this is an error in the HART reception, so that this is the HART signal coming into MOD_IN and coming out of UART_OUT? How long is the total transmission that you're receiving? Are you only getting errors in the last four bytes? Is there any extra space between the byte communications? Are you using an external oscillator or using the DAC8740H internal clock?

    Again, I'm not sure what this is, but I wanted to ask some questions about your setup to help me understand this problem.


    Joseph Wu

  • 0 in reply to Joseph Wu
    Prodigy 10 points

    Hi Joseph Wu,

    here is my schematic of the DAC8740H:

    I'm using the internal clock and the internal filters. However, I use the 1V5REF2 also for the 4-20mA interface as Vref (Figure 35 in datasheet). The measured voltage is 1.48V. After removing it from the 4-20mA interface, the framing errors still exists. In a new design it will be removed as it is bad practice.

    The measurements are taken at the UART_OUT (HART_RX) and MOD_IN (TP4). This is an error in the hart reception. The total transmission contains 19 bytes: 0xff ff ff ff ff 82 80 00 00 00 00 83 05 03 3b a3 d7 0a c2

    Errors can appear everywhere but are more common in the last 4 bytes. There is no extra space. Here is a snapshot of a full transmission (UART green, Carrier Detect red) with an error:

    The corresponding UART table from the oscilloscope is as followed:

    UART Time Data DataLength Bit Rate Status
    1 0,00137119 0xff 8 1229
    2 0,01029511 0xff 8 1223
    3 0,01926916 0xff 8 1225
    4 0,02822701 0xff 8 1198
    5 0,03741116 0xff 8 1225
    6 0,04636719 0x82 8 1200
    7 0,05553302 0x80 8 1200
    8 0,06463106 0x00 8 1221
    9 0,07348395 0x00 8 1204
    10 0,08259699 0x00 8 1203
    11 0,09171101 0x00 8 1204
    12 0,10080915 0x83 8 1200
    13 0,10973115 0x05 8 1199
    14 0,1189131 0x03 8 1216
    15 0,12783712 0x3b 8 1200
    16 0,13717708 0xa3 8 1150 Framing Error
    17 0,14924114 0x3d 8 1202 Framing Error
    18 0,15922316 0x98 8 1233 Framing Error
    19 0,17147903 0xff 8 1214

    Noticeable is the bit rate which is generally above the expected 1.200 kbit/s. Also, I rotated the data to determine weither the package length or the characters were the error factor: 0xff ff ff ff ff 05 03 3b a3 d7 0a c2 82 80 00 00 00 00 83. The errors occurred still the most with the 3ba3d7 data.

    With further measurements I found, that the transmitted frame length of the FSK signal is typically at 8.9ms which is way lower than the expected 9.17ms+-1% from the HART protocol:

    This was measured at the external certified HART modem and a shunt resistance of 400R. It shows the frame of 0x01 with a start bit, little endian data, parity bit and stop bit. The complete frame takes only 8.854ms. I will get in contact with the manufacturer of the external HART modem too. Could the HART modem on the DUT get out of sync?

    If you have any more questions about my setup or if I can aid with measurements, feel free to ask.

    Kind regards,

    Nico

  • 0 in reply to Nico Hoppe
    TI__Guru* 97805 points

    Nico,


    Sorry, I didn't get back to you earlier.

    It does look like the HART signal is a little fast. If the transmitted frame length is 8.854ms, that is about 3.4% faster than expected. I do expect that the DAC8740H would be able to keep up with some mismatch in the frame speed. However, that's a bit much.

    Just to be sure, can you check the transmission of the DAC8740H to see the timing of the signal? You may just be able to set /RTS and turn on the DAC8740H modulator. When that happens, the device should send out a 1200Hz sinusoid. With that, you can check to see that the device is at the correct frequency as well (is this 1200Hz output too fast or slow also?).

    I would have expected that any given frame could potentially be misread, so I wouldn't have expected the problems all at the end of the frame. However, I think that the faster frames could really be the problem.


    Joseph Wu