• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 47 subscribers
  • Views 544 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

DAC8740H: Question about an alternative device.

DAC8740H: Can we let CD pin pull down a little later

Severi Zhou
Intellectual 2410 points
Part Number: DAC8740H

Hi team,

I’m an analog FAE from east China and I’m supporting SUPCON.

Customer are testing DAC8740H to replace AD5700, and meet a question.

 

Test background:

Customer use the upper computer to send Hart signal, through DAC8740H modulate, use the MCU to read UART result. Their software logic is that enable UART while catching the rising edge of CD pin, disable UART while catching the falling edge of CD pin.

 

Question:

With DAC8740H, the UART signal is easy to lose the last bit. After debug, the root cause is CD pin pulled down too early, so UART was disabled and the last data transfer wasn’t complete. By checking the datasheet, DAC8740H has 3ms carrier detect off time while AD5700 has 5ms, can we extend Tcdetoff1? Or is there other methods to let CD pull down a little later?

 

DAC8740H Timing:

AD5700 Timing:

Pls kindly help me to resolve this time issue. BTW, I have also sent email to Joseph so that we can communicate more details by mail.

Thanks,

Severi Zhou

  • +1
    TI__Guru* 97415 points

    Severi,


    The carrier detect (CD) is an output pin that determines whether the FSK signal is detected on MOD_IN/MOD_INF. When the device stops detecting the signal, then the CD returns low. As you mention, when the DAC8740H stops detecting the signal CD returns low within 3ms, while the AD5700 returns low within 5ms.

    This timing is not adjustable within the DAC8740H. We simply indicate when the device stops receiving the FSK signal. The AD5700 takes a little longer to stop indicating the CD signal.

    In implementing the HART stack, you would need to add a small change to firmware. The firmware would take the CD signal and add an extra 2ms delay to match the AD5700. This may be used to give extra time to read the signal from the DAC8740H so no characters are missed.


    Joseph Wu

  • 0 in reply to Joseph Wu
    TI__Intellectual 2410 points

    Hi Joseph,

    Thanks for your suggestion, I have convinced customer to add 2ms delay in the MCU software.

    There is another question. DAC8740H works with the internal filter, and as shown in the below waveform, the yellow line is CD pin signal, the green line is HART_IN signal. CD pulled down 1.54ms after no effective HART signal, not 3ms. Is 3ms the max limit? Or did I test Tcdetoff1 in wrong way?

    Thanks,

    Severi

  • 0 in reply to Severi Zhou
    TI__Mastermind 41353 points

    Hi Severi,

    Joe will review your second question and get back to you shortly.

    Best,

    Katlynne Jones

  • 0 in reply to Severi Zhou
    TI__Guru* 97415 points

    Severi,


    The oscilloscope plot you have shown is correct. Here, the carrier detect (CD) goes low 1.5ms after the carrier stops transmission. This is Tcdetoff1 from the table. As shown in the datasheet on page 11, this is specified as 3 ms maximum.

    In HART protocol test specifications, there is a table for carrier detect start and stop times. For the limits, the carrier start and stop are both 6 bit times maximum. With a baud rate of 1200 Hz, this is the equivalent of 5 ms maximum. For the DAC8740H, our stop time is shorter than the maximum (and shorter than the AD5700).


    Joseph Wu

  • 0 in reply to Joseph Wu
    TI__Intellectual 2410 points

    Hi Joseph,

    As mentioned above, for the logic that enable or disable UART by CD pin, maybe shorter carrier detect off time is a shortage.

    Could you kindly share me other customers application logic with HART modem and MCU-UART?

    Thanks,

    Severi

  • 0 in reply to Severi Zhou
    TI__Guru* 97415 points

    Severi,

    We don't really have anything available to share with on that. This is generally programmed into the HART stack firmware. Even in our own example demos for firmware, we have used a third party to develop the HART stack.

    Joseph Wu 

  • 0 in reply to Joseph Wu
    TI__Intellectual 2410 points

    Hi Joseph,

    OK, thanks for all your reply, it's really helpful.

    Severi