Group Actions
Engagement
  • Author Author: Jan Cumps
  • Date Created: Date Created
  • Views 3870 views
  • Likes 8 likes
  • Comments 21 comments
Related
Recommended

DAC8775 Quad-Channel DAC EVM - part 5: HART Interface

Jan Cumps

For the Instrumentation, Automation and Industrial Application fanboys.

And for anyone interested in communication protocols that are widely used but not commonly known.

 

I'm checking the Highway Addressable Remote Transducer Protocol interface on the DAC8775.

image

 

 

HART Protocol

 

The HART protocol communicates info on a current loop by adding a small AC component to the current loop.

The frequency of that component defines that you're sending a mark (1200 Hz) or space (2200 Hz).

That's all I'll tell about the protocol. The blog is not about how it works, but how to use it with the DAC8775.

Secretly I hope this gets you interested in a widely used industrial communication protocol,

 

DAC8775 and HART

 

From the DAC8775 datasheet:

DAC8775 is also implemented with a Highway Addressable Remote Transducer (HART) Signal Interface to superimpose an external HART signal on the current output.

 

The HART peripheral is only useful in current mode. The HART signal is a communication component added to the current output that DAC is set to.

The DAC8775 implements the physical layer. It doesn't know HART protocol or data handling, but can generate the compliant signal on its output.

In essence, it accepts a sinusoidal signal of 0.5 Vpp, either 1200 or 2200 Hz, and translates that in an AC current component on the output of 1 mA

image

The image above, from the DAC8775 datasheet, shows how the DAC, when set to a  6 mA DC output current, mixes a HART signal of 0.5 mApp to it.

 

EVM Board Modification

 

The evaluation kit used in the element14 Road Test has no breakout point for the HART inputs. On each of the 4 DAC channels, that pin is coupled to ground via a capacitor.

image

I'm using channel A, so I have removed the capacitor for that module's HART input - C58, and soldered a patch wire to the PCB.

imageimage
imageimage

 

 

The HART input signal has to be capactive coupled. The HART pins on the DAC8775 have a DC bias. I used a 0.470 µF capacitor.

According to the data sheet, a value between 10 and 20 nF is recommended. I wasn't in the mood to go look for one.

 

 

Testing the HART Interface

 

There are two things you have to do:

  • enable the HART interface on the DAC in your firmware
  • provide the HART input signal. A sinus of 0.5Vpp, with 1200 or 2200 Hz frequency.

 

To enable the HART interface, you need to set bit 13 of the DAC Config register 0x04.

 

image

In our initial example, we were setting the bit 12 high, because we enabled the DAC output.

So we only have to change that part of the code, and instead of sending 00010000b (0x10), we send 00110000b (0x30).

 

    TX_Data_Master[0] = 0x04;
//    TX_Data_Master[1] = 0x10; // output on, default slew rate without HART
    TX_Data_Master[1] = 0x30; // output on, default slew rate with HART
    TX_Data_Master[2] = 0x05; // slew rate off, 0 - 20 mA mode
    /* Initiate SPI3 Transmit and Receive through Polling Mode */
    spiTransmitAndReceiveData(spiREG3, &dataconfig1_t, 3, TX_Data_Master, RX_Data_Master);

 

We're setting an output current of 10 mA. Or range is from 0 to 20 mA, so we need to set the half of 0xffff: 0x07ff.

 

    TX_Data_Master[0] = 0x05;
    TX_Data_Master[1] = 0x7f;
    TX_Data_Master[2] = 0xff;
    /* Initiate SPI3 Transmit and Receive through Polling Mode */
    spiTransmitAndReceiveData(spiREG3, &dataconfig1_t, 3, TX_Data_Master, RX_Data_Master);

 

That's all for the firmware. If you run it, the HART intrface for Channel A is enabled.

 

I simulate the HART signals with a generic function generator. I set it to sinus 1200 and 2200 Hz. I used my oscilloscope to set up a 500 mVpp output after the coupling capacitor of 0.470 µF.

Then I inserted the signal into the DAC and checked the output. Just like in the previous blog, I used an EEVBlog µCurrent as a load. It translates the DAC's output current into a voltage.

I attached channel 2 of my oscilloscope to the output of the µCurrent.

 

 

image

 

The yellow signal is the HART input, generated by the function generator. It's 500 mV, 1.2 kHz.

The blue signal represents the DAC's output current. Each mA is a mV on the Oscilloscope display.

You see the DC component of 10 mA, and the 0.5 mVpp AC component superposed by the HART interface.

 

For the reader, this isn't spectacular. But in industrial installations, this can be used (and is regularly used) as a digital communication path over the commonly used analog instrumentation current loops.

 

 

 

Related Blog
DAC8775 Quad-Channel DAC EVM - unlicensed roadtest part 1: Raw SPI
DAC8775 Quad-Channel DAC EVM - part 2: Firmware
DAC8775 Quad-Channel DAC EVM - part 3: Slew Rate Control
DAC8775 Quad-Channel DAC EVM - part 4: Current Mode
DAC8775 Quad-Channel DAC EVM - part 5: HART Interface
Parents

  • This HART stuff is interesting. Wonder why they chose a modem standard from 1960-something?

     

    Just like in the previous blog, I used an EEVBlog µCurrent as a load. It translates the DAC's output current into a voltage.

    Why not just use a resistor to convert the current to a voltage?

     

    If you used a 500R resistor (quarter watt or better - a pair of 1k resistors in parallel, maybe?), you could use a voltage probe and you'd see a voltage signal the same size as the one you're feeding in.

     

    I'm presuming here that the output is floating and the current is sourced rather than sunk, so it doesn't matter if you have the grounds on both the input side and the current output side connected to your 'scope ground (but you're now the expert on this chip, so you decide if that's correct or not).

     

    That way you'll probably see a better signal and can properly measure the current amplitude (if you have a reasonably accurate resistor); you'll be able to measure the delay; and, if your generator has a sweep capability, you can see what the frequency response is like (not essential, but what kind of engineer are you if you're not curious about these kind of things?)

     

    Forgot, we're meant to be doing [+] as well as [-]. Really good 'not a Road Test' you're doing here. Keep up the good work. Have a star.

  • in reply to jc2048

      wrote:

     

    This HART stuff is interesting. Wonder why they chose a modem standard from 1960-something?

    ...

    I can only guess. The 1200 - 2200 Hz standard (imposed on a current) has proven to be reliable, and can be implemented at source and destination side fairly easily.

    The modulation is easy, the detection is easy. Even with discrete components, both sides can be built with not-too-heavy-on-tolerance components and work good.

    Mix that with the tendency in industry application to go for solutions that show proven long-life reliability, and don't require infrastructure changes.

    (edit: current loops work easier in installations  with long wires than voltage driven solutions. In current driven circuits, wire resistance is a nuisance, not a player in the signal integrity. It can be handled by hardware that has enough oooomph. Wire voltage loss is a thing, but no current gets lost in a serial circuit)

     

    This may not be ground-breaking technology. On the other hand, it works together with investments that industries have done to their installations. And it serves the purpose.

    Factories aren't the playground for bleeding edge technology I guess*.

     

    * I put the star here because I've witnessed ground-breaking solutions change the way things are done on a production floor. But it requires heroes on all decision levels ...

  • in reply to jc2048

      wrote:

     

    ...

    The data recovery is interesting to think abot. Surely you can't use frequency-selective filtering or PLL techniques (can you?), because there isn't time with just a single cycle of the lower frequency. Having less than two cycles of 2200Hz, rather than exactly two cycles of 2400Hz, messes up zero-crossing detection and then measuring the intervals. But that 2200Hz (rather than 2400Hz) wasn't an accident, there was an engineering reason for it; just wish I was clever enough to guess what it was and how it worked.

    ...

     

    ... yes, I also wonder how this works out in practice, having just a single cycle for the 1200 and almost 2 for 2200. On the positive news for me: this is not a worry for this DAC. It merely provides the physical OSI layer, together with some wiring.

    But the HART protocol caught my interest. I'd like to use some ICs or devices that actually speak the language ...

     

    edit: I agree that the approach seems vicious:

    image

     

    There must be a reliable and cheap way to decode this. Otherwise some PhD  chap in 1976 would not have gotten away with it.

     

    edit edit: although when you know that the cell time is 833 µs, you can count  the number of high or low hits. They have a distinct maximum for both 1200 and 2200 Hz ...?)

    (if it's high more than one time, it's 2200 - or am I too sloppy?)

     

     

     

    edit edit edit: maybe also a  filter can give the info after all. With a well chosen low pass filter, the DC-ish level coming out of a 1200 Hz block is higher than the DC coming out of a 2200 block?

  • in reply to jc2048

      wrote:

     

    .... Maybe that doesn't matter if it's mostly slow-moving sensor data like temperatures and whatnot.

    The business case is calibration data and settings. It's not intended for exchanging measurements or messages ...

  • in reply to mp2100

    You may just have summed up the business cases for HART. Both for why it was embraced and for why it's still around ...

  • in reply to Jan Cumps

    We differ on that one. The input is made for that range, whatever falls outside of it can't be compared to a spec. .... Then again -- this might be fun. Hang on ...

    But the spec may stipulate levels for the out-of-band signals and might even give a filter template to work to. (I don't know - I'm just guessing - I can't afford to join their club and get my 'free' specification. If I had that much money to spare I'd buy a spectrum analyser instead.)

     

    It certainly looks from your results further down that TI are filtering the higher frequencies, though that might just be the way the current-loop driver response rolls off anyway and not necessarily specific to the HART signal.

  • in reply to jc2048

    The spec is very low on info for this pin:

     

    image

    ...

    image

    image

     

    ...

    image

     

    image

Comment Children
No Data