Post Go back to editing

LTC4120 Thermal Fault status handling

I have a question regarding the handling of the LTC4120's THERMAL FAULT status. 

We are wirelessly charging a battery using the LTC4125 in an open loop mode.  We cannot close the loop using feedback because our distance can be too great (up to 25mm).  We are getting a THERMAL FAULT status from the LTC4120 when charging at elevated ambient temperatures.  However, when this occurs, our temperatures rise even more because the 4120 pauses the charging and the transmitter is still transmitting power. This is actually the worst case condition for generating heat in our device, so the device never cools down. The heat is being generated in the charging coil front end components (mostly the zener diode limiting the rectified input).

Does anyone have any suggestions as to how to mitigate this runaway thermal problem at the receiver end?

  • Hi Wired, 

    When LTC4120 hits thermal shutdown, do you see any change on the input current of the LTC4125, or do you see any change on the FB of LTC4125 ? I think something can be done on LTC4125 side to detect whether the LTC4120 is in shutdown mode or not. For example, if a input current rise is detected, then you can readjust the IMON pin resistor to make the LTC4125 trigger input current fault. If a voltage spike is observed on FB of LTC4125, you can readjust the FB resistor to make LTC4125 trigger voltage protection.  

    If the signal on the LTC4125 side is not strong enough to differentiate whether LTC4120 is in shutdown or not, some helper circuit might be implemented increase the difference of Rx side resonant tank impedance. One way I am thinking is to use the _Fault pin of the LTC4120 to drive a FET that shorts the Rx tank to LTC4120 ground. If the fault is removed, the FET losses its driving voltage and release the short. 



  • Thank you for the prompt and thoughtful reply, Wenwei. You always give excellent advice.  I would probably lean toward a receiver side solution, which I think would be preferable from a safety standpoint for our application.  I was thinking something along the lines of your suggestion could work, but I'm just a software guy, so hearing it from you is welcome information.

    My concern was that once the tank was shorted to GND, the fault would be immediately removed because there would be no voltage at the RUN/IN pins, and the datasheet says that the LTC4120 would be in a disabled mode, with the status pins both de-asserted. Wouldn't this result in some kind of fault/no fault oscillation that would repeatedly disable/enable the tank?  Pardon my lack of EEness if I am misunderstanding your proposal. If the fault can remain asserted until the temperature falls below the hysteresis limit, then it seems like a workable solution.

  • I was also thinking about that. During a fault condition, the output current should reduce to zero, and the power consumption of the LTC4120 is low. With larger input caps, it should be able to keep LTC4120 active for the fault logic for several hundred milli-seconds. I would assume it works like a hiccup mode, retrying to startup every few hundred milli-seconds. If the heat is reduced, then it will be automatically restart. Is there a desired scenario ? 

  • As far as the reduction of heating goes, that sounds like it would be effective, assuming that the thermal fault would be detected at a much faster rate, e.g. within 10ms of startup.  The more difficult part is probably having to now create some type of algorithm to continue reporting a thermal fault when it will be possible for the hardware to alternately report NOT CHARGING and THERMAL FAULT (and possibly CHARGING, depending on how the LTC4120 sets the status on startup).  One of the reasons we are not using feedback on the transmitter was because our status bits were giving erratic (at least from a user's perspective) indications of charge status.

    For our application, I would expect the system to take a few minutes to drop below the temperature needed to clear the fault.