• State Resolved
  • Replies 4 replies
  • Subscribers 46 subscribers
  • Views 103 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

Original question:

DAC161S997: about loop error detection

DAC161S997: Loop Error Reporting with Excessive IAUX

Seth Jackson
Expert 2010 points
Part Number: DAC161S997

Tool/software:

Can I just get a confirmation that this device will not report any loop errors in the STATUS register if the companion devices in the circuit (IAUX) pull excessive current? From the linked question and a few others, it appears that the loop errors only show in the STATUS register if the DAC161 determines that the output transistor is being driven to saturation, but not if it's effectively driven to cut-off.

As a theoretical example, DACCODE is set to a value of 0x2AAA which is expected to be ~4mA. However, due to excessive IAUX, the output is actually ~4.3mA. With an ERR_CONFIG value of 0x011E in this condition, ERRB is never asserted (driven low) nor are there any loop errors signaled in the STATUS register. Is this expected?

  • +1
    TI__Guru* 96195 points

    Seth,

    Is the IAUX high because there are other devices in the transmitter that are using current from the LDO (or from the loop itself)?

    I'm not entirely positive, but I don't think the loop error detects when the current is higher than expected. The loop error is described as "when the device is unable to sustain the required output current at OUT pin, typically caused by a drop in loop supply, or an increase in load impedance. (data sheet page 8)" In both those cases, the loop tries to pull more and more current to satisfy the loop control. For example, if the loop is broken, The DAC161S997 would pull up on the BASE pin to drive the NPN to pull more loop current. At some point, the BASE cannot go any higher, and yet the current would not be satisfied. I think this is how the device detects the loop error.

    In your case, the loop current is already satisfied. The DAC161S997 doesn't need to pull any more current to set the loop and BASE goes to 0V because all the current is already being pulled by the devices in the transmitter.

    To check the operation, I would set the DAC code to higher and higher values (0x2000, 0x4000, 0x6000,..., 0xC000, and 0xFFFF) just to see if the loop is set to the current you expect. Then you can set the DAC code to a mid value, and check to see if the loop error occurs (with the error current) when the loop resistance is incrementally increased. If you just break the loop, you may need to increase the L_RETRY_TIME just to see the error current.


    Joseph Wu

  • 0 in reply to Joseph Wu
    Expert 2010 points

    Joseph, thanks for the reply. In my example, the IAUX is high due to other devices using excessive current from the LDO. However, I was also hoping the DAC161 could report an error if there was a ground loop induced by other components.

    Your explanation makes sense and was what I assumed. The datasheet was a little ambiguous in how it described when the errors were asserted. Again, thank you for the reply!

    Joseph Wu said:
    If you just break the loop, you may need to increase the L_RETRY_TIME just to see the error current.

    I was wondering about this too. In my application, the DACCODE is updated every 125 msec. If the case of a loop error, it appears the output current essentially toggles between the commanded DACCODE and the ERROR_LOW value if I don't stop sending a DACCODE update until the loop error is resolved. For example, every 125 msec I send DACCODE 0xD555, but due to a loop error the device is trying to signal ERROR_LOW. From what I've seen the measured current is somewhere between DACCODE and ERROR_LOW due to PWM essentially.

  • +1 in reply to Seth Jackson
    TI__Guru* 96195 points

    Seth,

    I'll find an EVM and see if I can test this. I wasn't exactly sure of the mechanics of the error setting and recovery. However, I had thought that once the error is asserted, the error current value could be seen in the loop until the next time the device is able to retry the original DAC code. Because of this, you would need extend out the retry time to accurately measure it.

    Joseph Wu

  • 0 in reply to Joseph Wu
    Expert 2010 points

    I believe your understanding is correct. When I extended the retry time to maximum (400 msec), it would stay longer at ERROR_LOW but it still attempted to put my updated DACCODE onto the wire and quickly reverted back to the ERROR_LOW value until DACCODE was updated again.

    In my application, I think I'll just disable automatic loop retry and periodically query STATUS manually. In this mode, receiving an updated DACCODE from my application every 125 msec during a loop error won't affect the output until the STATUS register is read. This gives more time for an end-user to possibly see the error current without any glitches.

    Thanks for your insight, Joseph!