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.

AFE3010: application

Part Number: AFE3010

Dear Peter,

Here I have some questions about AFE3010 application as below,

The circuitry as below,main function inclued EOL & GFAULT, 


Questions:
1. Any comements/suggestions on SCR-TST external connection?  Will it affect SCR self test ?

2. Power on by 120Vac 60Hz or 230Vac 60Hz, the ALARM output High(0.5Hz). We did below test, pls check and advise your idea. 

 a.   SCR,ALARM,FT, SCR_TST wave while power on 120Vac,60Hz:
   
   
   b.  OUT wave is different from datasheet figure 17
        

  c.  FT,NG_OUT, OUT, PH wave while power on 120Vac,60Hz:

       

Looking forward to your reply.

Best regards.

Lin
       

  • Hello Valued Engineer Lin,

    Here are my schematic review notes:

    1. R7 may need to increased to something > 10-Ohm given that the internal regulator at VDD pins has breakdown for 20-V. Providing some current-limiting resistance here will help stabilize this and D4.
      1. Measure VDD during device power up and until it starts failing self-test to ensure that VDD is remaining stable at 20V until
    2. NG_OUT pin is missing a 0.1uF capacitor in-series with R24 as per typical recommended schematic.
    3. C33 and C25 off the ALARM pin do not seem necessary unless you are purposely trying to smooth out the 3kHz PWM from ALARM pin.
    4. I do not see how FT pin can perform its job. CON1 should connect directly to the line voltage at all times. R36 will reduce the gain of the self-test signal and increase chance of false-negative. R50+R51 (20kΩ) may reduce self-test signal and increase chance of false negative. The recommended schematic for a 120VAC has R50+R51 < 11kΩ. You will have to choose this value if circuit is to work with both 120VAC and 230VAC.
    5. Everything connected of the SCR pin is not clear in purpose.
      1. Are you driving a solenoid?
      2. Is MCU measuring the SCR signal in order to open a load switch elsewhere not shown on schematic?
      3. Keep in mind that the SCR can only drive ~2mA.
    6. The SCR_TST connection to Q8 looks correct.
    7. R30+R32 is usually the solenoid, which usually has a much lower resistance.

     

    In the “a” images, device is clearly failing its self-fault test (associated with FT pin). The FT fires 5 times every second after power up because device is not measuring this signal (see Figure 10 of datasheet).

    In the “b” images, the current transformer is clearly not receiving any differential ground fault signal induced by the self-fault test from FT pin. Thus, the CON1 header is not connected to the LOAD side of the line voltage. OR the connection is correct, but R50+R51 and R36 are too high to turn on Q6.

    In the “c” images, device (or current transformer) is not sensing the emulated ground fault induced by FT pin. Also NG_OUT looks slight unstable ( I recommend addressing notes 1 and 2 above to potentially remedy the unstable NG_OUT signal).

     

    Overall you just need to make this schematic look more like the recommended from datasheet and also modify components according to my notes at top and get it to work at 120VAC. Once it is working then start adding back your customer circuitry until you notice device starts failing self-test again so we know where and why it is failing

     

    Please ask me any other questions you may have.

    Sincerely,

    Peter

  • Dear Peter,

    Thanks for your review and comments.

    My reply below.

     

    1. R7 may need to increased to something > 10-Ohm given that the internal regulator at VDD pins has breakdown for 20-V. Providing some current-limiting resistance here will help stabilize this and D4.
      1. Measure VDD during device power up and until it starts failing self-test to ensure that VDD is remaining stable at 20V until
        The vdd regulated at 20V, see below. 

    2. NG_OUT pin is missing a 0.1uF capacitor in-series with R24 as per typical recommended schematic.
      There is 0.1uF on the other page of schematic,The NG_OUT,REF,FB,OUT peripheral circuit and the value same as Figure 15.


    3. C33 and C25 off the ALARM pin do not seem necessary unless you are purposely trying to smooth out the 3kHz PWM from ALARM pin.
      Yes, it's use to smooth out the 3kHz PWM 

    4. I do not see how FT pin can perform its job. CON1 should connect directly to the line voltage at all times. R36 will reduce the gain of the self-test signal and increase chance of false-negative. R50+R51 (20kΩ) may reduce self-test signal and increase chance of false negative. The recommended schematic for a 120VAC has R50+R51 < 11kΩ. You will have to choose this value if circuit is to work with both 120VAC and 230VAC.

      According to the measurement, the current through R50,R51 is 8.6mA (86V/10K)

      In addition, the self test still failed when R50 change to 0R



    5. Everything connected of the SCR pin is not clear in purpose.
      1. Are you driving a solenoid? No
      2. Is MCU measuring the SCR signal in order to open a load switch elsewhere not shown on schematic? Yes
      3. Keep in mind that the SCR can only drive ~2mA. Noted ,thanks
    6. The SCR_TST connection to Q8 looks correct. Noted
    7. R30+R32 is usually the solenoid, which usually has a much lower resistance.
      The waveform as below, any comments?


      In addition,I try to use contactor instead of R30,R32, but the self test still failed.


      I have more question as below.

    8.  After below change ,The self test sill failed, we got the waveform as below, pls check and comments.

          



      Looking forward to your reply.

      Best regards.

      Lin

  • Hey Lin,

    I am looking over this and will respond shortly.

    Best,

    Peter

  • Hey Lin,

     

    1. The waveform generated when changing L2 to L1 for PH pullup makes sense. If you shift PH voltage by 180°, then FT will fire during the wrong phase (negative phase). Since the amplifier is inverting, the resulting signal at OUT is going up. It should be going down. This is why PH and FT pins should be pulled up to the same line signal so they are in phase.

     

    Overall there is still an issue with the system being able to detect the emulated ground fault through Q6. In first images, OUT signal is unchanged when FT goes high, which is clearly indicating the transformer is not “seeing” the emulated ground fault. When you switched R49 pullup from L2 to L1, I finally see the OUT voltage responding to FT pin, but it is moving in the wrong direction. It should be moving down below 2.5V.

     

    Try these debugging and simplifying steps. If one does not fix the issue, then move on to the next step.

     

    1. First make sure that PH pin is pulled up to L2 and that R50 is also pulled up to L2 via the CON1 component. Or vice versa, both CON1 and PH pins are pulled up to L1. Either way they must always be pulled up to the same LINE signal.
      1. Please confirm that the emulated ground fault through Q6 is actually translating into a signal detected and amplified at OUT pin.
        1. System will never work if it cannot detect this self-test signal at OUT pin.
      2. Probe OUT, PH, FT, SCR to understand best what is happening

     

    1. Reduce R36 to a short
    2. Replace R50 with a short.

    1. Once you see OUT moving in response to FT, make sure the OUT signal is going below 2.5V (going down). If it is not, then you may need to flip the polarity of the current transformer by either:
      1. Switching pins 8 and 6 of CON5
      2. Or switching the direction of L1 and L2 into the CT from one side to the other.

     

    1. Float the SEL pin (disconnect from ground).
      1. This will turn of the SCR self test. If system stops failing as it has been, then the root cause was inability to pass SCR self test.

     

    1. With SEL floating remove unnecessary SCR circuitry (R31, Q8).
    2. Reduce R30+R32 to a total of 5kΩ or lower to better match recommended schematic.
      1. It is possible that the RC filter from R30+R32 and C21 could be slowing down the sense line signal at SCR test and interfering with self test.
    3. Also modify the following components:
      1. Change C2 to a resistor from ~560-Ω to 1kΩ.
        1. This may be unnecessary but it ensures that SCR output current will have a path to ground if the resistance going into Q3 base it too high or too small.
      2. Remove and short out D3
        1. This resistor seems unnecessary.

     

    Sincerely,

    Peter

  • Dear Peter,

    Thanks for your comments.  the OUT signal is below 2.5V and the ALARM signal become normal after switching pins 8 and 6 of CON5. therwaveform as below.

     OUT signal is below 2.5V

    ALARM  ON 280ms while power on.

    Here I have further questions.

    1.  How to verify the 100-turns coil ?Below is the NG-OUT waveform , any comments?

         
    2.  We have false trips problem on our product, we would like to improve it in the new design, do you have any imformation/experience on AFE30100 could share with us?


    Best regards.

    Lin

  • Hey Lin,

    Ok so it appears that the polarity of the fault signal was the root cause. The power images are showing normal behavior where device passes first self-test and the blinks ALARM once to indicate it has passed first self-test after power up. Note that establishing correct system polarity is part of design procedure detailed in section 8.2.2 of datasheet.

    1. To verify the Neutral-to-ground detection, you need to at the very least confirm that test can detect and fire SCR to a 2-Ω neutral-ground fault resistance as instructed in the datasheet Section 8.2.2:

    2. Can you explain more about the false trip? Is it shortly after power up or can it be at any time? Is it consistent?

    It would be helpful to try to capture the pin voltages before the SCR is fired (so try setting a pulse trigger off SCR going > 1V for > 8ms). You have to use a pulse trigger and not an edge trigger because there will SCR edges in response to the SCR self test.

    My recommendations and debug steps for this include some steps from my previous post:

    1. Determine if there is any consistency to where the false trip happens (e.g., shortly after power up or not).
    2. Capture an oscilloscope shot triggered off SCR pulse (>1V for > 8ms) with a ~2 second time window.
      1. The 2 second time window will help us determine if device is failing a periodic self test (FT and SCR_TST) or failing a continuous self test (PH and SCR_TST pins). See section 7.3.7 for more information on this.
    3. Also attempt the following board/BOM modifications to see if this removes the false tripping:


        1. Also modify the following components:
          1. Change C2 to a resistor from ~560-Ω to 1kΩ.
            1. This may be unnecessary but it ensures that SCR output current will have a path to ground if the resistance going into Q3 base it too high or too small.
          2. Remove and short out D3
            1. This resistor seems unnecessary
        2. Reduce R36 to a short
          1. IF this fixes false trip, then root cause was marginal detection with self fault test at FT pin, but this seems unlikely.
        3. Replace R50 with a short.
          1. IF this fixes false trip, then root cause was marginal detection with self fault test at FT pin, but this seems unlikely.
        4. If possible, float the SEL pin (disconnect from ground).
          1. This will turn off the SCR self test. If system stops false tripping, then the root cause was inability to pass SCR self test with sufficient margin.
        5. ONLY with SEL floating, remove unnecessary SCR circuitry (R31, Q8).

    Although I am not fully privy to your system requirements, to me the following board simplifications should be made to help simply the debugging process.

    Sincerely,

    Peter

  • Dear Peter,

    See my reply below.

    1. Can you explain more about the false trip? Is it shortly after power up or can it be at any time? Is it consistent?

    Sorry that we are talking about our old version by using another brand GFCI controller product will have false trip problem.

    Now, we will use TI AFE3010AIRGTR for our new version thermostat with GFCI product and would like to consult you if any we can improve the false tripping issue.

    There are two targets that we would like to review and fulfill:

    1. Can fulfill the IEC61000-4-6 (i.e. conductive immunity test) that testing frequency range from 0.15MHz to 230MHz, Test voltage is 10Vrms and DWELL time is 1 seconds.
    2. If the power line is connecting some noisy dimmer switch (like Lutron), No false tripping found.

     

    Therefore, please let us know your comments about AFE3010 to deal with above noise cases and if any comments and filtering suggestion for the circuitry ?

     

    Thanks and best regards.

    Lin

  • Hey Lin,

    The best things to do to prevent false tripping from these noise sources are:

    • Capacitors at digital pins (PTT, SW_OPEN, and SEL). The typical is 1nF, but you could go up to 5nF. You cannot use very high capacitors at these pins because the delay in their voltage rise may cause a false reset during power up.
      • All noise blocking capacitors should be as close to the input pins with short returns to the AFE3010 ground plane.
    • Use a ~600nF capacitor across the 100-turn coil terminals. You may be able to go higher depending upon coil impedance, but always validate device trip time to ensure BW has not been affected.
    • Maintaining good distance between AFE3010 input traces and the high voltage line busses.
      • One trick is placing the current limiting resistors (e.g. R48 and R49 closer to the line bus and further away from PH pin. But still keep C27 as close as possible to PH pin.
    • Using a large ground plane for AFE3010
    • Keeping the impedance between AFE3010 ground and return for VBIAS as low as possible.

    Hope this helps.

    Sincereley,

    Peter

  • Dear Peter,

    Thanks for your reply.

    Refer to  the trip point test, we found the trip point is ~21mA RMS, rather than 5mA RMS, We tried to increase the R7 resistor from 36k to 62k, the Vout change,but the trip point no change. Below is wiring diagram and the waveform, pls review and comments.

    Wiring diagram

    While R7 = 36K , the trip point is 21mA RMS.

    While R7 = 62K , the trip point is 21mA RMS too.

    Looking forward to your reply.

    Thanks and best regards.

    Lin

  • Hey Lin,

    Is the system passing self test and not false alarming when powered on for a few minutes without any fault current present? I just want to make sure device is not failing self test.

    Based upon the VOUT amplitude’s almost 2x increase between the 36 k and 62k, the true trip point should have decreased below 21 mArms.

    Additionally given the fact above, it does not make sense that VOUT amplitude at 19mArms is the same for both cases.

    Can you confirm what the fault current was on both scope images labeled as “under 19 mArms”? And please repeat the experiment as explained below?

    When trying to measure trip point, you have to increase fault current very slowly and give a brief 1 second pause after every small incremental increases in fault current (about 0.5mArms steps). Procedure is explained in step 3 of section 8.2.2.

    You can speed process up by setting fail current so that Vout is just below 0.5V peak to peak (<2.75V and >2.25V). The device should not be tripping here. Then increase fault slowly. If you increase too fast then it can make trip point look higher than what it really is.

    Sincerely,

    Peter

  • Dear Peter,

    The self test pass and performed once in every 180 cycles.

    We found the trip point  is 4.6mA RMS, while the leakage current increase to 4.65mA RMS, and the SCR output high(duration 12.8ms), but the ALARM output keep LOW ( Identify by MCU detecting ALARM signal ),Is ALARM keeping LOW normal ? As per datasheet ,the ALARM output should be HIGH after fault detection.

    Thanks and best regards.

    Lin

  • Hey Lin,

    According datasheet Figure 10 and Table 3 (section 7.4.2), the ALARM only blinks on and off continuously when AFE3010 has failed a self test. When devices fires in SCR in response to a true ground fault, the ALARM stays low.

    Thus, what you are describing makes sense because you are testing device with a ground fault that is switched out once SCR goes high. And ALARM does not blink and remains low.

    Is my interpretation of your post correct?

    The only way this changes is if you pull SCR_TST pin to GND. Doing this (along with SEL=GND) would make ALARM goes high at all times except when device fail a self test per Table 3 of datasheet.

    Hope this helps.

    Best,

    Peter

  • Dear Peter,

    Yes, your interpretation is correct.

    Here I would like to double confirm with you that if the below method  is the correct way we should do.

    "B. Second option is as you describe. Once SCR is fired, pull SW_OPEN low and monitor ALARM for about 1 second to see if goes constant high (ground fault) or continues blinks (EOL condition). Then release SW_OPEN."

    Many thanks

    Lin

  • Hey Lin,

    This "B" option is still valid as a method to determine if the SCR fired because of a ground fault or because of an EOL (end-of-life) condition (failing a self test). 

    However, option "B" is actually not necessary. Without using SW_OPEN you can still differentiate a ground fault and an EOL condition by monitoring what ALARM is doing as I describe in previous post (note Figure 10 and Table 3 of datasheet). Just so it is clear, you do not need SW_OPEN to know if SCR fired because of a ground fault or EOL condition. If SW_OPEN is floating (unused), ALARM will stay low if there is a true ground fault, but ALARM will blink if there is an EOL condition (AFE3010 fails self test).

    Using SW_OPEN pulled low is a matter of preference of the ALARM logic. In other words do you want ALARM to remain always off for no EOL condition (SW_OPEN floating) or always ON for no EOL condition (SW_OPEN low)? In both cases, ALARM will blink for a failure in a self test.

    Sincerely,

    Peter

  • Dear Peter,

    Thank you very much for your eleboration.

    Below is the PCB Heat distribution, the ambient temperature is 22.8c,the highest temperature of device is 49c。  

    I have below questions.

    1.  The temperature rise up 26c, is it normal?

    2.  Are there any ways to low down the temperature?

    3. Which components would effect the device temperature?

    4. What is the relationship between temperature and trip point? will the trip point high while the temperature high?

    Thanks and best regards.

    Lin

  • Dear Peter,

    I have more question as below.

    5. When SCR fired, Is the SCR pulse at least one positive half cycle? Is there any case less than positive half cycle?

    6. if continue Ground Fault, what is the output of SCR ?  the SCR fired once or continuously?

    7. Whether the same SCR and ALARM signal for both Neutral-Ground leakage and Ground Fault leakage ?

    8. Does it need to reset the device after artificial Neutral-Ground leakage and Ground Fault leakage?


    Thanks and best regards.

    Lin

  • Hey Lin,

    5. Yes, it fires for at least one positive cycle where the positive cycle is determined by zero crossing tracking at the PH pin.

    6. If SCR fires once and the ground fault continues (Vout is still exceeding internal comparators >2.75V or < 2.25V), then device will respond according to section 7.3.7.2's Amplifier Short/Open continuous self test. This sections describes that if SCR fires once and Vout is still showing a real ground fault, then SCR will fire a second time and blink the ALARM pin to indicate there is some single-point failure such as a short between REF pin and FB pin for example.

    7. If the device has fired SCR whether because it detected a fault or failed a self test, it will always have to be reset via the PTT or SWOPEN pins to reset the internal fault counter and/or stop the ALARM blinking.

    Sincerely,

    Peter

  • Dear Peter,

    The above questions 1-4, 7 have not been replied, can you help to reply?


    Thanks and best regards

    Lin

  • Hey Lin,

    My apologies.

    1 through 3. 

    I don't think this rise is normal.

    I believe this temperature increase is most likely due to excess supply current going into VDD pins. This was my first schematic comment in my initial reply on this post two weeks ago.

    You should be able to drop this supply current without any change to device operation by increasing R7 to something reasonable (try 510-Ohm). Right now, there is a 0-Ohm and this is all that is limiting current between a 24-V Zener and the 20-V Zener inside the device. Thus, there is going to be excessive current.

    4. There is some slight change in trip point over temperature, due to 0.5uV/C input offset shift, but trip point error over temperature has been extensively tested and characterized per the UL 943 specifications and even higher up to 105 degrees C.

    I hope this helps.

    Sincerely,

    Peter

  • Dear Peter,

    D4(24V zener)  and C22 are not mounted, just reserve to use.

    For the chip temperature issue, I tried to change the value of R7 to 510R, 200R,100R , and self-test fail when using 510R & 200R . and self test pass when using 100R.

    Below is  R7 waveform on 0R, 510R , please check and comment, thank you.

    While R7= 0R, the VDD input current is 9.4mA based on the R45 voltage drop (4.8V)

     

    While R7= 510R, the VDD input current is 3.9mA based on the R7 voltage drop (2V)

     

     While R7 = 510R, the self test failed when power up .

       

    Below is the waveform of R7 on 0R & 510R, it seems that there is no big difference on VDD.

      

    By tha way, what is the minimum VDD input current?  there is no spec. on datasheet.

    Best regards.

    Lin

  • Hey Lin,

    There really is no minimum specification. There is the typical quiescent current specification, but the minimum of this won’t vary much, maybe by -15% to -20%. Either way it doesn’t really matter because supply current is dominated by the regulating current of internal 20V Zener.

    The reason device is failing self test with higher R7 is the slower VDD power on time. This will affect how other rails are powered on.

    Thankfully you should be able to fix this by reducing the supply decoupling capacitance (C28 etc) such that the effective RC time constant remains the same.

    Sincerely,

    Peter

  • Dear Peter,

    About the leakage test, I found that the leakage of 6mA & 264mA, SCR output waveform is different, see below。

    Leakage current 6mA.

    Leakage current 264mA.

    I have below questions。

    1. What is the condition for SCR to output 2 pules?  Will there be more pules output?

    2. According to the measurement, the pules time of two SCR is about 20ms, is it possible to be longer than 20mS?

    Thanks and best regards.

    Lin.

  • Hey Lin,

    1. It could be that the spike on CH1 is causing a spike on at PTT or SWOPEN and causing device to perform a reset. Another possibility is that the AFE3010 was still sensing a fault after first SCR pulse and this triggered a 2nd SCR pulse according to the device's amplifier short/open self test (section 7.3.7.2 of datasheet), but since the load fault ceased within 1 cycle, the AFE3010 did not start blinking ALARM.

    2. For certain self-test failures (e.g., the PH pin opens), the SCR will continuously fire for two full cycles. The reason it does this is because it cannot track its "clock" (the zero crossings of line) so fires SCR for a conservative period of time to ensure SCR is pulsed during at least one positive line cycle.

  • Dear Peter,

    Thanks for for your comments,

    About the responnse time  mentioned on spec table 1, when fault current is >+/-50mA, response time is 10ms,.

    Below is the load(leakage resistor) ,OUT,SCR waveform based on leakage current 264mA ,

    We could see the OUT respond immdiately while current leakage happen.

    See from below waveform, the SCR fired(duraction 8ms),14ms later than the current leakage happen.

      

    See below waveform, SCR fired in 10ms when current leakage happen.

    My questions as below.

    1. What affect SCR response time? 

    2. Do you have any sugguestion on fasten SCR response time?

    3. We got the time from SCR to ALARM is ~1s, when we set the self test fail , Is this time constant ? if not, What factors affect the time?

        

    Best regards.

    Lin.

  • Hey Lin,

    1. SCR response time is a factor of what internal comparators are being tripped and how often based upon a rolling average of cycles that depends upon fault amplitude.

    2. The only way to increase SCR trip time is to increase amplifier gain (R23).

    3.  Yes. The ALARM blinks 60 cycles after SCR is fired. So for a 60 Hz system this is one second. After this ALARM blinks on for 60 cycles and then turns off for 60 cycles and repeats indefinitely (so 0.5 Hz blinking for a 60 Hz line).

    Sincerely,

    Peter

  • Dear Peter,

    Thank you for  your reply.

    We have some more questions as below-

    1. Selt test once per 180 cycles, is it possible to be happened with ground fault at the same time? If so, what is the ALARM output?

    2.  Pls find self test pass waveform under 240Vac 60Hz supply as below-

      

        a.  We found FT output  is happened 1ms later than positive half-cycle started, is the time normal? What effect the time?

        b. As shown on above CH3 chart,  VCE is 78V while 240Vac supply, and VCE is 54V while 120Vac supply, do you have any suggestion on selt test circuit improvement?

    3. Re chip temperature,  the highest temperature is 65c under  25c ambient . We made below change, but no change, do you have any suggestions on it?  Could D4 use 12-20V zener?

          - Add D4(24V zener), the highest temperature keep the same.

          - Change R7 to 100R, the highest temperature low down 5c  only.

    Thanks and best regards.

    Lin 

  • Hey Lin,

    1. If a ground fault were to occur exactly when FT pin was activated then it would not affect trip time if the faults was tripping the last comparators at 40 mArms. If the fault is less, then trip time is only increased by les than 1 ms (or as long as it takes for device to recognize the device is passing internal self test). ALARM shouldn’t blink because it only blinks for a failed self test.

    A. This is completely normal. The start of the next phase when PH voltage increases up to the internal 20V clamp. This voltage will be slightly lagging behind real line voltage because it is a voltage coming out of saturation. You can see this delay in Figure 17.

    B. I do not understand the question. If you want one BOM for both line voltages you have to choose the lower resistor that works for the 120 VAC.

    1. Ideally D4 should be between 20V. 18V to 20V could be acceptable. But as soon as you make it > 20V, then you need R7 to limit current from the voltage drop.

    Sincerely,

    Peter

  • Dear Peter,

    Thank you for your comments.

    Here are some more question for you, pls kindly advise.

    1. See from below power-on waveform,  CH3(ALARM) output  high for 3000ms period (self test pass), it is different from 250ms in datasheet. Is ALARM output 3000ms normal?  Or is there any problem on AFE3010 chip?

         

    2. In leakage test, when we do fault current 204-264mA (@ 204 & 264Vac) test, self test is fail(ALARM blinking), but when  we  do fault current 4-6mA test, it passed. We try to change R35 and R50 to 0R, the result is same. Below is the relevent circuit, pls kindly check and comments.

       

    Thanks and best regards.

    Lin

  • Hey Lin,

    This is not normal behavior. Perhaps there could be something happening at the SW_OPEN pin? Please measure this pin voltage during this same test to see if it is getting pulled down. This could definitely cause ALARM to stay high.

    I ask this because ALARM is only released when CH 2 (GFAULT) goes high out of negative state.

    Something is causing device to fail a self test and it is dependent upon amplitude of ground fault (which also corresponds to how fast device trips SCR). Is your system responding to what it sees from AFE3010? We really need pin waveforms of or as close to  VDD, OUT, PH, SCR during this test to better understand.

    Sincerely,

    Peter

  • Dear Peter,

    Here are some more waveform about ALARM blinking , pls check and advise your comments. 

    1.  Below is waveform during the test, it could be seen SW_OPEN(CH2) is unstable, but VCC is stable.

       

    2. When ALARM blinking , FT(CH1) is still doing the self test.

      

    3. We found the SCR always output 2 pulse, before ALARM blinking everytime.

      

    Best regards.

    Lin

  • Hey Lin,

    1. First image on the left is showing SCR being fired twice. SW_OPEN shows some oscillation, but nothing that should switch the digital mode.

    For the second image on the right, I do not understand how CH4 is ALARM. CH4 seems like it should be SCR voltage, in which case this image would represent device passing self test. Please confirm.

    1. Device may still perform periodic self test if it failed another self test (e.g., amplifier short/open self test).

            3. So if the ALARM is unexpectedly blinking every time the SCR is fired twice, then this makes me think the device is failing its amplifier short/open self test (see section 7.3.7.2 of datasheet). This happens when Vout is still >2.75V or < 2.25V even after device has fired SCR. This is exactly what it looks like in the third image. It’s possible that the delay from SCR activating until the load switch actually opens is too long and thus Vout is tracking the ground fault after the first SCR pulse causing device to think there is an amplifier short/open failure.

     

    Overall I was more interested in looking for more data/waveforms when ALARM is staying high for 3 seconds. Was this event a one time event? Is it repeatable? What system condition cause this event to occur?

     

    Sincerely,

    Peter

  • Dear Peter,

    Pls find reply as below -

    1. First image on the left is showing SCR being fired twice. SW_OPEN shows some oscillation, but nothing that should switch the digital mode.

    For the second image on the right, I do not understand how CH4 is ALARM. CH4 seems like it should be SCR voltage, in which case this image would represent device passing self test. Please confirm.

    [Lin] Sorry for typo, CH4  is SCR.

    1. Device may still perform periodic self test if it failed another self test (e.g., amplifier short/open self test). 

            3. So if the ALARM is unexpectedly blinking every time the SCR is fired twice, then this makes me think the device is failing its amplifier short/open self test (see section 7.3.7.2 of datasheet). This happens when Vout is still >2.75V or < 2.25V even after device has fired SCR. This is exactly what it looks like in the third image. It’s possible that the delay from SCR activating until the load switch actually opens is too long and thus Vout is tracking the ground fault after the first SCR pulse causing device to think there is an amplifier short/open failure.

     [Lin

    a. How to verify “amplifier short/open self test fail” ? Is there any other methods, except measured  Vout ( >2.75V or < 2.25V) ?

    b. If the third image shows amplifier short/open self test fail, how long "SCR activating until the load switch actually opens” will take?How to improve this time, so as to avoid amplifier short/open self test fail?

     

    Overall I was more interested in looking for more data/waveforms when ALARM is staying high for 3 seconds. Was this event a one time event? Is it repeatable? What system condition cause this event to occur?

     [Lin]  It is repeatable. It happen on power on everytime. Is it the chip problem?

    Thanks and best regareds.

    Lin

  • Hey Lin,

    There are two separate issues right now (but they could have same root cause).

    First issue: SCR is firing twice and ALARM blinks in response to a ground fault. 

    1. This most assuredly is due to device failing is amplifier short/open self test. And this looks like its happening because ground fault is not ceasing fast enough after SCR is fired.
    2. The only way to fix this is to directly (or as close as possible) connect SCR pin to the solenoid/relay/load switch you are using to open the load. However when I look at the most recent schematic, I cannot tell how the SCR signal is being translated to opening a load switch.
    3. Can I get more information on how SCR signal translates into opening a load switch and what the load switch is exactly? Is a host processor taking care of this? If so, can the firmware be adjusted so that SCR triggers MCU interrupt and MCU immediately turn off load switch?
    4. Can system be retested with R31 reduced significantly (e.g., 500 Ω)? I ask because maybe Q8 is not being turned on fast enough and so driving high bias current could help.
    5. Also what is the point of D3 and R1? Can you try retesting overall device operation with either D3 or R1 unpopulated?
    6. Please try probing the SCR signal as it is translated down signal stream? So probe SCR pin and the load switch input to see the delay between this points. Also knowing the delay between switch input and actual switch opening is going to be needed.

    Second issue: ALARM stays high for 3 seconds.

    1. They are saying that this occurs every power up, but the waveform contradicts this because it looks like SCR is firing in response to a ground fault. I guess I just need more information on this occurrence.
    2. What happens after this event? Is ALARM blinking and device needs to be reset? Or is device is normal operation and will respond to a real ground fault?
    3. What is the CH2: GFAULT signal? Is this voltage of OUT pin (pin 13) of the device?
    4. If CH2 is measuring OUT, then why is it dropping to -0.5V? There needs to be more investigation here because OUT should not go below GND rail or else if can cause damage to the device.
      1. During this exact event, in addition to SCR, GFAULT, and ALARM, please also measure/probe SW_OPEN and VDD with respect to GND pin of AFE3010.
    5. If OUT is being pulled to -0.5V, then this makes me think something or some bias event is pulling significant current out of the AFE3010 causing its internal 2.5V reference voltage to collapse and also causing ALARM to oscillate, which does not stop until this event stops and CH2 goes back to normal 2.5V.
    6. I wonder if D3 and R1 is causing the oscillation at ALARM.

    Overall, I highly recommend simplifying the schematic and remove all unnecessary components so that schematic matches more closely the schematic shown in the datasheet. Then retest all basic function and probe the pins I recommend. Here is simplified schematic I would recommend:

    Other temporary things I would try are:

    1. Open the SEL pin
    2. Drive VDD pin with a 20-V source directly.
    3. Try decreases passives and RC time constants between SCR and load switch.
    4. I crossed out R31 value because I think value could be dropped to potentially turn on Q8 even faster.

    Sincerely,

    Peter

  • Hey Lin,

    Looking back through previous messages I have noticed some things.

    One it looks like there is about ~13ms delay between SCR being enabled and the relay switch opening (see t2 below). Also the delay between relay and load opening (t3 below) is about 8 ms. This overall delay time is too long and will most likely cause a 2nd SCR firing and/or device to fail its amplifier open/short self test. When using a solenoid to mechanically open a load switch, delay times between SCR firing and load switch opening are shorter (<10ms).

    In previous waveforms, the TP30 (GFAULT) always seems to react after SCR, which does not make sense as AFE3010 will only fire SCR if it sense a ground fault. I do not see a TP30 in any of the schematics, which makes me think GFAULT is not representing the VOUT, but rather something else. Please confirm what TP30 or GFAULT really is. If you are going to measure a representation of the the fault current, simply probe OUT pin (pin 13).

    Another thing I noticed was that in the waveform below, GFAULT also collapses to below GND (almost -1V) when ALARM is blinking in response to a self test fail. Why would this happen? There is not reason to have ALARM and GFAULT logically tied together. GFAULT in all other images never goes below GND. So something is pulling this signal low when ALARM blinks, and this is potentially causing other issues during the power up issue where ALARM gets stuck on for 3 seconds. I believe this happens only on power up because VDD may not be fully charged; however, during a random self-test fail (with VDD at full charge) it is not enough to make ALARM remain on for 3 seconds. Please try testing system with the simplifications I recommend in last post.

    Sincerely,

    Peter

  • Dear Peter,

    Pls find reply as below .

    1. Can I get more information on how SCR signal translates into opening a load switch and what the load switch is exactly? Is a host processor taking care of this? If so, can the firmware be adjusted so that SCR triggers MCU interrupt and MCU immediately turn off load switch?

      [Lin]
      See below updated circuitry , once leakage, GFAULT changed from HIGH to LOW for MCU detection, then MCU output (RELAY) through Q2 to close relay (relay control the load on/off).
    2. Can system be retested with R31 reduced significantly (e.g., 500 Ω)? I ask because maybe Q8 is not being turned on fast enough and so driving high bias current could help.
      [Lin] Will arrange test,thank you!
    3. Also what is the point of D3 and R1? Can you try retesting overall device operation with either D3 or R1 unpopulated?
      [Lin]
      See above circuitry,SCR ,ALARM send signal to GFAULT through D3/D6,MCU detect this signal to idendify different mode (EOL,G-FAULT)
    4. Please try probing the SCR signal as it is translated down signal stream? So probe SCR pin and the load switch input to see the delay between this points. Also knowing the delay between switch input and actual switch opening is going to be needed.
      [Lin]
      According to our updated circuitry test result(as below), it is around 10ms from SCR fired to load switch to off.
      The response time of SCR and GFAULT is similar.
        

    Other temporary things I would try are:

    1. Open the SEL pin
      [Lin] SEL connect to GND at the bottom of the IC, so it can't open SEL.
    2. Drive VDD pin with a 20-V source directly.
      [Lin] Will arrange test,thank you!
    3. Try decreases passives and RC time constants between SCR and load switch.
      [Lin] any suggestion?
    4. I crossed out R31 value because I think value could be dropped to potentially turn on Q8 even faster.
      [Lin] Will arrange test,thank you!

    Best regards.

    Lin 

  • Hey Lin,

    Thanks for the information.

    1. I see. I understand you want to differentiate between EOL and ground fault, but I think in order to understand the true root cause in all of this you really need to remove diodes D6 and possibly D2. You want to start with simplest configuration, which is ignore ALARM output for now and just keep the D6 to Q1 pathway only dedicated for SCR to MCU. I am concerned that having these pins tied together and the entire level shifting circuit is causing some unstable feedback. I would suppose that the safest course is to make sure you have dedicated pass through from SCR to relay. Right now you are mixing both with both ALARM and SCR being low pass attenuated before Q1. Maybe the ALARM should be low pass filtered, but the SCR should not and connected directly to Q1 base?
    2. Ok will wait for the result.
    3. See my response in 1. Please remove D6 and  D2, I don’t see a reason for D2 if MCU is going to be the source driving load relay.
    4. The first image shows 10 ms delay from time GFAULT  is pulled down until load stops. It doesn’t seem to show SCR, but this still feels too long. The second image shows a slow decay of Q1 base and this seems to keep GFAULT low for another 5ms. Maybe add a weak pull down to Q1 base so that this voltage decays faster once SCR falls?

    Also, passives I recommend to reduce are R15, C25, C11, C6, R8, C24, C15, C33. Overall you want to reduce any R and C to reduce settling time constants.

    Sincerely,

    Peter

  • Dear Peter,

    Update the following test result.

    2. Can system be retested with R31 reduced significantly (e.g., 500 Ω)? I ask because maybe Q8 is not being turned on fast enough and so driving high bias current could help.
    [Lin] R31 change to 500R and 300R respectively,the result same as before.

    3. Drive VDD pin with a 20-V source directly.

     [Lin]  No mater VDD supply DC 20V and AC together, or supply AC first,  DC 20V later,  both Alarm blinking, the waveform as below.   Pls check and advise your comments. 

      

    4. See my response in 1. Please remove D6 and  D2, I don’t see a reason for D2 if MCU is going to be the source driving load relay.

    [Lin]  We removed D6,D3,D2, the Alam output maintained 2.78S when power on,  it is different from 0.25s in datasheet.

    We also do the leakage test (264mA/264Vac), Alarm still blinking.

    5. The first image shows 10 ms delay from time GFAULT  is pulled down until load stops. It doesn’t seem to show SCR, but this still feels too long. The second image shows a slow decay of Q1 base and this seems to keep GFAULT low for another 5ms. Maybe add a weak pull down to Q1 base so that this voltage decays faster once SCR falls?

    [Lin]  GFAULT and SCR is synchronize, and logic oppisite because of  OP2,  as second image above.

    10ms is from SCR fired to Load swith off.  See from the first image, the time from SCR fired to MCU output (CH4) switch relay off pulse is 2.2ms,  and from relay switch to off (CH2) is 10ms in total, Is this time still long?

    When GFAULT change from HIGH to LOW, MCU will output off pulse to shut off relay in 2.5ms. Regarding to GFAULT keep low for another time, it is irrelevant to load switch, R15 and C25 are as low pass fitler to filter out SCR self test pules and smooth ALARM 3KHz signal.

    The second image just would like to show you the  GFAULT and SCR synchronization.  

    Here are some more waveform about ALARM,SCR measument, pls kindly check and comments.

    a.  ALARM(yellow) output  high for ~2700ms period (self test pass), it is different from 250ms in datasheet.

    b. we did fault current 264mA (@ 264Vac) test, we found the time of SCR fired to ALARM is not constant and  ALARM blinking.

    c.  Below is the waveform of self test , is it any problem on FT,D11,SCR_TST,SCR?

     

    Thanks and best regards.

    Lin.

  • Hey Lin,

    I will have to respond tomorrow on this tomorrow.

    Sincerely,

    Peter

  • Hey Lin,

    1. What is the same result? ALARM blinking or ALARM staying on for 2.8 seconds?
    2. This waveform shows ALARM performing normal blinking due to a self test failure (ON for 1 second, OFF for one second). There is one issue with this waveform and that is it shows Vcc reaching full charge after approximately 150 ms, which is too long. Can this Vcc rise time be decreased closer to 30 ms?

    This waveform indicates that changing how the device is powered actually fixes the 3 second ALARM problem, but then introduces a false blinking. Is this assessment correct?

     

    1. So you removed D6, D3, and D2. But did you replace D6 with a short? If not, how were you able to observe ALARM pin, through oscilloscope probe?

    Before you made this change, how was this system behaving? Was it showing ALARM blinking after power up? Or was it showing ALARM only blinking once after power up for 2.8 seconds?

    Does the false ALARM blinking only occur during a leakage test?

     

    1. 10 ms from SCR activates until relay mechanically closes should be ok.

     

    5a. ALARM voltage waveform does not look ideal. First, it has an initial spike and then only falls to ~1V during the 3 kHz switching, when it should fall to 0V probably because of D6. Then it does not go all the way back up again.

    5b. This is probably due to the same root cause creating the lone 3-second ALARM on time. The delay time almost seems related to the ALARM on time (~2.78 seconds). ALARM should not be blinking here because it is a real ground fault. I still believe that this false EOL blinking is due to the long delay between SCR firing until load actually ceases.

    I would say this behavior is the lowest of priority to fix if it still remains once other issues are resolved.

    5c. This waveform is showing normal self-test behavior.

     

    There must be a reason why the ALARM stays on for almost 3 seconds for the initial power on blink. The only thing make ALARM stay on indefinitely is the SW_OPEN pin being held low. Please try to repeat the power on test (with no fault) and probe SW_OPEN pin. You sent some waveforms of SW_OPEN previously, but these were during steady state operation, not during a power up.

     

    Are there any instances where device fires SCR in response to a ground fault, and there is NO ALARM blinking?

     

    Sincerely,

    Peter

  • Dear Peter,

    Would it be possible that we can send the PCBA to you for helping speed up to locate the problem ?

    Best regards.

    Lin 

  • Dear Peter,

    2.  Yes, you are right. It is ALARM staying on  2.8 seconds when power on, and ALARM blinking when leakage current 264mA.

    3. We could try to  fasten VCC, then test again.

    4.  NO, we removed D6, the oscilloscope probe is measure D6 positive pad.

    5.  We try to replace chip(AFE3010)  by a new one,  but ALARM still stay on for 2.8 seconds when power on,  and in 264mA leakage test, ALARM still blinking.

    5a.  See below circuitry,  the initial spike is generated by SCR fired, then is Alarm output.

       

    5b. 10ms is the shortest response time of existing hardware and software.

    5c. SCR_TST(CH3) is in negative half-cycle, is the wave normal?

    6. Are there any instances where device fires SCR in response to a ground fault, and there is NO ALARM blinking?

        Yes,  NO ALARM blinking is around 50% in the whole leakage test , any comments?

    Thanks and best regards.

    Lin

  • Hey Lin,

    I think sending the board should be ok, but let me double check.

    A. Would you please probe SW_OPEN pin during device power up during the 2.8 second ALARM event. If easier just completely float the SW_OPEN pin and retest.

    B. Try decreasing power up time close to 20ms. Please measure how fast the VDD rises on power up.

    C. Would you please try to speed up the SCR-to-relay open timing as much as possible? Do this by removing C2, D6, and C25. See if this helps with the false blinking on high leakage fault test. I ask because of this image below showing the two SCR pulses, potentially indicating a false amplifier self test fail as mentioned.

    Another thing to measure during this debug of false ALARM blinking it the OUT pin. Maybe OUT is not decaying back to 2.5V fast enough during the high leakage fault tests. You can test this by adding some weak pull down resistors (5kOhm to 10kOhm) at OUT pin to GND.

    Sincerely,

    Peter

  • Dear Peter, 

    Thanks for your support. 

    A. We had found out the reason of ALARM on 2.8s, it was caused by MCU G_reset internal pull up. Thank you for your patience.

     After removed D7, we got the waveform of TP26 (ALARM/SCR) high for 340ms as below-

      

    B. Removed D8,  and VCC supply DC 19.9V , test result as below-

       - See from 1st image below , VCC rised from 0V to 20V less than 1ms.

       - See from 2nd image below,  Alam blinking when power up AC240V firstly , then power up DC19.9V. (No leakage)

      

    C. We are searching the more senstive relay for test.

    BTW, we have done 264mA leakage test by removing C2, D6,C25, Alarm still blinking.

    Your image above was measured by old circuitry,  from this image we could see SCR had fired in negative half-cycle, but GFAULT voltage keep the same, for OP3 out of working in  negative half-cycle. In order to use SCR signal to close Load efficiently, we updated the circuitry  as below new version. Theoretically,  the new version closed Load would not slower than the Solenoid(figure 15) in datasheet.

    D.  we try to add resistor 5.1k at OUT to GND, The ALARM blinking on high leakage(264mA) fault test.

    Could you pls advise your contact info. ? We would like to send you a PCB board for your analysis.

    Pls let us know if your have any idea on test anytime.

    Thanks and best regards.

    Lin.

  • Hey Lin,

    A. Great! Likewise, thanks your patience as well. This makes sense because SW_OPEN is the only pin that can make ALARM stay high continuously.

    B. I am confused on what the differences are between these images. The first image looks great, but the second image shows a bad Vdd rise time. Is the right image related to the ALARM blinking on power up with leakage or is this a new issue? Or is this fixed by putting D8 back? 

    Ok so we can focus just on the ALARM blinking after 264mA leakage test. This is what I would do.

    1. With leakage at 264mA, get a waveform probing SCR, OUT, ALARM, line at 10ms/division.

    2. Repeat waveform, but also probing SCR_TST. Make sure probing SCR_TST does not change device behavior.

    2. Reduce leakage current until the problem stops. At this leakage current, grabs the same waveform as done in step 1.

    3. Compare waveforms from steps 1 and 3.

    4. Try everything to make sure the delay from SCR on to relay off is reduced. 

       4a. Remove C2, D6, C25 (already done)

       4b. Reduce R15, R9

       4c. Remove, reduce C11, C6

       4d. If you can float the SEL pin, then you could open all highlighted components (R31, C21, Q8).

    I still stick to this idea about the delay between SCR and relay off based on what I see here in image below. It does appear that Vout is slow to go back to 0mA point (2.5V), and this could be causing the false ALARM blinking. Other possible causes are disturbances at SCR_TST or PH pins. 

    I would like to test your board, but I really need to confirm a couple things. Please contact me via private message so we can work out the details on this and how you test your board.

    Sincerely,

    Peter