• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 62 subscribers
  • Views 425 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:

BQ76952: Using Predischarge autonomously

BQ76952: Triggering SCD followed by a pre-discharge cycle for load capacitance at start-up

Harry McNally
Intellectual 485 points
Part Number: BQ76952


Hello Asher and others

Adding to the previous thread, I have come back to look more closely at the start-up speed when using pre-discharge autonomously.

I have a 400uF load capacitance and chose a pre-discharge rise-time of 200mS. A 160ohm pre-discharge resistor is about right to reach 95% of stack voltage.

This waveform shows the start-up:

Prior to SCD trip, 400uF load capacitor charges to 8V then after a 2.35 second hiatus, predischarge operates and charges the load capacitance to stack voltage

I close a switch to connect the 400uF load capacitance. The load voltage rises rapidly to 8V volts (X10 probe) before the SCD trips and disconnects the main FET.

You can then see a 2.35 second pause until the PDSG enables and the voltage rises up to the stack voltage in 200mS as designed.

I have adjusting register delays to find the source of the pause before PDSG enables.

I started with the SCD delay at 15uS and recovery time at 1 second. PDSG enabled @ 2.7 seconds

I adjusted SCD delay to 0uS and PDSG enabled @ 2.3 seconds. I then restored delay to 15uS.

I adjusted the SCD recovery time to 0 seconds and PDSG enabled @ 2.96 seconds (?). I restored recovery time to 1 second.

I adjusted Load Detect, Retry Delay to 0 seconds and PDSG enabled at 2.35 seconds. I restored Retry Delay to 2 seconds.

I then kept the same register settings and ran multiple start-ups (discharging the load capacitance between tests) and found the delay jitters around 2.3 to 3 seconds.

What I am -guessing- is that the jitter is the time that the ADC scan loops around to reach the Load Detect voltage acquisition. Because the load voltage is at 8 volts this is well above the 4 volt load detect threshold so the load detect immediately triggers the pre-discharge and PDSG enables.

If my guess is correct, is there some way to increase the scan rate so the load detect comes around more often ? This is autonomous operation so a higher scan rate will have to operate at all times. I want to reduce or remove the pause so SCD trip is immediately followed by PDSG and the load capacitor is charged in the sub-300 millisecond range so pre-discharge startup is unnoticeable to the user.

All the best
Harry 

  • 0
    TI__Mastermind 25980 points

    Hi Harry,

    The SCD recovery is based on the SRN-SRP voltage staying below the threshold for the whole delay.

    Load detection based recovery is for the SCDL protection (from the TRM):

    You may try capturing the waveform of the voltage between the SRN and SRP pins to see if the added delay is due to the voltage exceeding the threshold.

    Regards,

    Max Verboncoeur

  • 0 in reply to Max Verboncoeur
    Intellectual 485 points

    Thank you Max. Your feedback gave me a new approach.

    I first looked at potential noise in the current sense circuit. I was using Protections:SCD:Threshold of 0 (10mV) to always cause the SCD event. Using peak detection on the CRO I was confident the noise never exceeded +/-1.3mV. I can observe the SCD event with a rise to 100mV until comparator delay and FET off time sees the pulse decline. I can't see any other disturbance above the noise over the next three seconds (and pre-discharge has occurred).

    To discount noise further, I adjusted Protections:SCD:Threshold to 1 (20mV) and observed the same pre-discharge delay with jitter from several repeat tests of between from 2.3 to 3 seconds. I am confident it is not a shunt noise issue.

    I then realised I had misunderstood the transitions and assumed I had to transition through Alert to Trip to Recovery and had Protections:SCDL:Latch Limit = 1. To observe only the Alert to Recovery, I set Protections:SCDL:Latch Limit = 255.

    I now have a good handle on the recovery time "jitter".

    If I set Protections:SCD:Recovery Time = 0 and run 20 connections to a (discharged) pure capacitive load the delay (recovery) time on the CRO waveform in my first post varies between 7.6mS and 1010mS.

    If I re-run the test with Protections:SCD:Recovery Time = 1 (second) the delay varies between 1.09 seconds and 2 seconds.

    Re-run the test with Protections:SCD:Recovery Time = 2 gives 2 seconds to 3 seconds.

    Re-run the test with Protections:SCD:Recovery Time = 3 gives 3 seconds to 4 seconds, etc etc.

    I now think the firmware does not react to the comparator SCD event to start the recovery time but has a 1 second poll or scheduled recovery test. The jitter is the delay between the event and the next recovery test epoch.

    So setting Protections:SCD:Recovery Time = 0 doesn't engage the pre-discharge circuit immediately after the Alert every time; unfortunate for me but it is what it is.

    I'd just like to confirm with you that my reasoning is correct and so I can consider how this will impact our approach.

    All the best
    Harry

  • 0 in reply to Harry McNally
    TI__Mastermind 25980 points

    Hi Harry,

    I think your reasoning is close. I discussed with our systems engineer and if the device was in SLEEP mode, the recovery may be delayed up to 1s. In NORMAL mode, the recovery may be delayed up to 250ms. 

    Regards,

    Max Verboncoeur

  • 0 in reply to Max Verboncoeur
    Intellectual 485 points

    Thanks Max

    The delays for SLEEP and NORMAL make sense.

    Commanding the BQ with a support MCU looks like the approach I will need.

    All the best
    Harry