GFCI self test failure

[Scott G]

Last weekend I built my first OpenEVSE unit using the v4 hardware.  It came with firmware v3.9.5 and the GFCI Self-Test defaulted to turned off. When I re-enable the GFCI self test in the setup, and then I restart, it fails the GFCI self test (red screen on the LCD).  I tried this both with and without the car attached, and tried powering down, unplugging, for ~15 seconds and all attempts the GFCI self test fails.

I saw elsewhere in the forums a suggestion that the 10uF cap (C14) is not needed and could be causing this issue because it is acting as a sample-hold and keeping the 'fault' interrupt sensitive for too long. But I don't see how this would cause the self  test to fail, from what I see in the Gfi.cpp code since the self test code waits till the pin PD6 goes low and then additional 1sec before it returns.

I think I've got the GFCI Coil connector plugged in correctly (orange wires for the self-test loop closest to the AC/DC block -- see attached picture). 

The GFCI coil is reading 45.3ohm and the self test wire is reading 0.3ohm, so that seems to be OK. On Chris' suggestion, I bent the outer pins on the 4 pin connector just a little bit so the connector would fit more snugly. But when I tried GFCI self test again, it still failed. This time I only tried it with the car disconnected, but I tried both menu-initiated reset and unplug/re-plug restart.  It failed all the time in both cases.

I had taken some pictures of the back side of the board when I was assembling it, so I could check component values or any other "options" (like removed R28) after I got it together.  I don't see anything obvious in the picture, but admittedly it's a little fuzzy in the upper right corner where the GFCI input stage parts are placed.  I guess I'll have to take it apart this weekend and give it a better review, checking some part values as much as I can with my cheap ohmmeter.

I'm also hoping by this weekend to have my laptop outfitted with all the compiler and USBasp programmer drivers to go out and try burning the latest v3.9.9 dev release.

Any suggestions about what I can try or what else I should check?

[Craig Kirkpatrick]

Everything looks right and I did confirm that the connection of the coil with the orange wire side closest to the power-supply brick is correct.

I think you understand what the self test does, and that is it pulses a little current thru the orange wire and sees if the GFI succeeds to cause an interrupt input to the microprocessor.  The self test can be disabled but the actual monitoring of GFI events is always on.

Besides just swapping the board to see if that remedies the trouble, one little experiment you can do is to loop a small wire thru the GFI coil (don't take anything apart) and use a small battery like any AA battery to just briefly energize your extra little wire.  With the OpenEVSE even sitting in the "Ready" condition you should see it briefly recognize the GFI fault and then it resets the fault since in the Ready state it doesn't make sense for it to wait to reset.  I would say that if the little wire and AA battery experiment doesn't trip a GFI fault then somehow the coil side of the GFI circuit is not intact and therefore you are not protected to true GFI events.  On the other hand if the wire and AA battery experiment does trip the GFI then at least your kit is still safe, it is just the self-test circuit that somehow is not functioning and you could trace those components to locate the trouble.

If trouble shooting it to the component is not really your cup of tea then just email Chris.  He is super about supporting customers.

Best Wishes,

Craig K.

[Scott G]

Thanks, Craig!  Great suggestion!

I'm going to replace my J1772 cable this weekend anyway (swapping out a 20' for a 25' cable) so I'll have it apart to make that change and I'll do that AA-battery GFCI runtime check.  I don't have any problem debugging stuff to the component level, but I just really miss my old lab setup from when I worked at GE Industrial Systems doing embedded controller designs.  At my new job, I don't have access to the good o'scopes and signal generators and meters that would be great for this kind of stuff.

I did recently see my old Radio Shack "digital logic probe" when I was cleaning out the garage, so I'll have to turn up the box that this went into and see if I can use that to check for the pulses going to the self-test coil.

- Scott G

[chris1howell .]

There may be a code change we can test when you go to 3.9.9.

Not long ago we changed the PWM of self test it was 50% on 50% off. It was reduced for UL, they wanted a very tiny current to test GFCI. I am wondering if we are on the borderline with the amount of current.

--
You received this message because you are subscribed to the Google Groups "OpenEVSE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openevse+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Scott Gaskins]

According to the changelogs, though, the 33% duty cycle for GFCI self test went into 3.9.5, which is what I'm running now.

As part of my debug, after I am successful at burning a new regular image, I'll try changing that back to 50% to see if it improves the test result.

- Scott G.

--
You received this message because you are subscribed to a topic in the Google Groups "OpenEVSE" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openevse/joOssmouqa8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openevse+u...@googlegroups.com.

[chris1howell .]

Okay... Let me know if you need a replacement board/coil. I will send whatever you need to diagnose.

[Danny ter Haar]

On Thursday, September 17, 2015 at 10:22:41 AM UTC-7, Chris wrote:

There may be a code change we can test when you go to 3.9.9.

Not long ago we changed the PWM of self test it was 50% on 50% off. It was reduced for UL, they wanted a very tiny current to test GFCI. I am wondering if we are on the borderline with the amount of current.

Maybe a menu option to calibrate the GFCI self test ?

Start with with 0% pwm, increase till it triggers and add 10% to the value ?

 

[Craig Kirkpatrick]

Chris, just as a data point my new bench development/test OpenEVSE is a V4 running D3.9.9 with a GFI coil attached.  I'm not seeing GFI selftest errors nor did I ever see selftest errors with any firmware revision.  Hope that helps.

On Thursday, September 17, 2015 at 10:22:41 AM UTC-7, Chris wrote:

[chris1howell .]

I do not think a menu option is necessary (if duty cycle really is the issue). We just need to find the minimum value to account for variance.

[Danny ter Haar]

On Thursday, September 17, 2015 at 12:28:27 PM UTC-7, Chris wrote:

I do not think a menu option is necessary (if duty cycle really is the issue). We just need to find the minimum value to account for variance.

Even though the manual says 5 windings, people might accidentally  do 4 or 6 (unless all new GFCI ct's are prefab now)

[Scott Gaskins]

My GFCI coil came pre-wound and the v4 kit has a 4 pin connector for the GFCI coil so there's no soldering needed like it showed in the build guide for the 3-pin connector.  From my build picture in the first post, it seems that my coil only has 4 loops, though... Am I looking at that correctly?

--
You received this message because you are subscribed to a topic in the Google Groups "OpenEVSE" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openevse/joOssmouqa8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openevse+u...@googlegroups.com.

[chris1howell .]

All coils are prefab now... :)

[Craig Kirkpatrick]

Scott, I count 5 conductors passing thru the coil on your orange wire and that is exactly the same as the coil I got with mine.  I think there must be something not 100% correct with the board.  You can debug it or just swap with with Chris.

[chris1howell .]

I am pretty sure my hunch is right. Last week I was testing a batch of boards and I was getting GFCI self test errors. I tried a new coil and it was okay but threw the other on my bench. It checked out fine measuring both coils so I was a bit puzzled, but I moved on and did not think much about it until Scotts Email....

I just grabbed the coil and it failed self test on 3.9.8. Loaded up 3.3.4 and enabled self test and it passes... I think 33% is just too low to account for variance in the circuits and coils.

I am very interested to see if Scotts results are the same as mine at 50%.

You received this message because you are subscribed to the Google Groups "OpenEVSE" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openevse+u...@googlegroups.com.

[Craig Kirkpatrick]

Chris, well that sounds very concrete to me.  Scott, I think you know how to change D3.9.9 back to 50%.  Or let me know if you want me to do it.  Chris, also let me know if you want me to do that for a new version we'll likely call D3.9.10  

Best Wishes,

Craig K

[Scott Gaskins]

I've got a lot of work going on and commitments tonight and Friday night, so the soonest I'll be able to try is on Saturday.  I've got to get the compiler working and firmware loader working, but after that the change looks to be quite easy.  I'm planning to try several settings between 50% and 33% so we have at least one additional datapoint for the variance.

What if the GFI self test loop increments the duty cycle with each iteration?  Would that be acceptable to UL?  I haven't dealt with UL requirements in a long time.

Good to know that it's the number of wires passing through the coil that counts as "loops".

- Scott G.

 

[Keith Thomas]

I too am suddenly having gfci fault errors, I did have them intermittently with 3.9.5, i just installed 3.9.8 and charged several times without an issue, I just had to disable the gfci fault test to get the car to charge, I will check the connection when I get back home this afternoon.

[lincomatic]

there are two types of gfci errors. gfci fault and self test. they have different causes. what is the exact message you're seeing?

Sent from my iCrap

--

[Scott G]

lincomatic,

The only type of check you can disable is the GFCI Self Test, right?

Does disabling the self test also turn off the whole GFI fault checking?

[chris1howell .]

Scott,

Disabling Self test does not disable GFCI. THe only way to disable GFCI it to not install the coil or remove it from the source code.

Your issue is failing self test, boots when self test is disabled and errors when enabled.

Chris

[Scott G]

Ok, so I had a few minutes this afternoon and I tested the GFCI operation while charging (actually just Connected... my car had finished charging) with the single, small wire through the GFCI coil and then briefly tapped the ends of the wire to an AA battery.  It indiciated GFI Fault very quickly, just like it should have -- Whew!  I'm glad that the function is good and I haven't been risking any kind of shock in the rain and such this past week.

Then I reset the unit by just going through the setup menu and scrolling to 'Exit'.  Apparently it took the fact that I went into Setup while there was a fault showing as indication that leaving setup should cause it to reset itself.

The only thing I think I lost by doing this was the accumulated Wh counter from my last charging session.  I'm going to have to re-check this to be sure, but I think when I caused the fault and then reset through the menu that the session Wh count did not add to the cumulative total kWh.

Also, when it reset while the handle was connected to the car still, it detected the service type as "L1:12A", when I actually have it plugged into 240V L2 and configured the max current to 20A.  Is this some kind of fall-back setting to limit the operation of the unit after a fault condition?  Or is this a consequence of resetting while connected to the car?

[chris1howell .]

Hi Scott,

Thanks for the testing. You are giving me more confidence we need to up the GFCI self test duty cycle just a bit...

The fall back to L1 is due to your vehicle being connected during reset. The Power on Self Test will not cycle the relays with a vehicle connected and can not determine the service level. Once charging starts the service level should go back to the correct value.

Chris

[Scott Gaskins]

Chris,
After charging starts, I don't see the service level on the display anymore.  And is the 12A current limit enforced now, instead of my configured limit?

You received this message because you are subscribed to a topic in the Google Groups "OpenEVSE" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openevse/joOssmouqa8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openevse+u...@googlegroups.com.

[chris1howell .]

The Current limit advertised by the pilot should go up as soon as charging starts. However, some EVs do not adjust the current up if it changes.

This behavior is vital to safety. Many users travel with their OpenEVSEs and frequently use both L1 and L2, If there is a power failure and the station restarts it defaults to the lower of the 2 settings until it can verify. We used to have a setting that always defaulted to your choice of L1 or L2 but that could put you in a dangerous situation where a power failure could result in a current setting that is too high.

[EV@TucsonEV]

Scott – what ev do you have?

 

Rush Dougherty

Dougherty Designs

1014 E King St

Tucson AZ 85719

520 240 7493

www.TucsonEV.com

 

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6140 / Virus Database: 4419/10662 - Release Date: 09/18/15

[Keith Thomas]

Went out and checked the charger again, reactivated the self test, now it all works ok, will have to keep an eye on it.

On Wednesday, September 16, 2015 at 8:11:04 PM UTC-7, Scott G wrote:

[chris1howell .]

I think we have the issue figures out. I believe a little testing and a simple firmware tweak will take care of the false negatives on the self test.

--

[chris1howell .]

Another user Steve is reporting the same issue... Looks like 33% is just too low.

[Craig Kirkpatrick]

I can characterize what level works or does not work on my bench setup for the self-test.  I have two of the new pre-build coils and two V4 controllers handy.  I can see if there is much variation in the pwm% among the four cases of 2 coils and 2 controllers.  It will give us an idea if 33% is just on the hairy edge or if it is very inconsistent among the hardware variations.  I was going to work on this exercise today but I ended up with other priorities at home.  I think it will be interesting and I'll try to do it early Saturday.

-Craig K.

[Scott G]

Rush,

I have a 2012 Chevy Volt.

- Scott G.

[Scott G]

Ok, I got the compiler and my firmware upload to work today after a brief misunderstanding with the "programmer" setting -- I needed to change it to USBasp to match my programmer dongle.  I was happy that the compile and upload worked the first time after that!  The only disappointing thing was that when I uploaded through the Arduino GUI, it erased my saved, accumulated kWh.  Is there any way to program that back into the EEPROM or to avoid loosing it in the future?  

The result of my several trials was was that 33% duty cycle was reliably *not* passing the GFI self test.  But the values of 40% and 50% were passing the GFI self test every power cycle (tried 4-5 times each).

So I've left it at 50% for now, and I'm contemplating my next code update.... :-)

- Scott G.

[Craig Kirkpatrick]

Scott, I also just finished some of the experimentation and you really are not going to believe my results.

To keep you in suspense, let me first answer the question about the kWh getting cleared.  I just copied and pasted this from something I wrote once before:

I have a two part answer.  First: Yes, there is a fuse setting that either preserves eeprom during programming or wipes it.  The command avrdude -c USBasp -p m328p -U hfuse:w:0xD7:m would set it so that eeprom is preserved.  By default we use avrdude -c USBasp -p m328p -U hfuse:w:0xDF:m in batch file scripts.  Notice just one bit is flipped going from 0xDF to 0xD7.  Eeprom not only has the accumulated kWh but also all of the button menu settings.  Choosing to keep the eeprom contents can be very useful if you do a lot of re-programming.  Remember you only need to set the fuses once and they are "sticky" until you go and set the fuses again.

Second: There is a nice RAPI command to set the accumulated kWh.  You would use $SK 123456 to set the accumulated kWh to 123.456 kWh.  It is a nice way to restore your accumulation if you wipe it by accident.

Explaining RAPI since you are new, it is the Remote Application Programmatic Interface over the FTDI header on OpenEVSE.  If you have a USB-FTDI cable you can use a terminal to type the commands at the OpenEVSE.

Set 115200 baud and set both NL & CR within the Serial Monitor Tool within Arduino and it makes a convenient terminal for typing commands.  I usually type $SE 1 to turn on echo.  Then $GV just to confirm things are talking.  Then you can use the $SK command as I wrote above.  I think depending upon what state the OpenEVSE is in the kWh may not flip the display immediately, so just try to plug in or unplug the car if the kWh change does not show up right away.

Now for my unbelievable results.  So far I have only used one of the OpenEVSE controllers I have on hand but I did try swapping two GFI coils.  I get the same result with both coils.  Both coils give me a GFI selftest error at 1% and both pass at 2%.  That is no typo, one percent duty cycle fails selftest and two percent duty cycle passes.

My conclusion is that it is not the coils.  It is not the 33% in the default D3.9.9 code.  It must be some variation of components on the OpenEVSE controller board.  Maybe the contract manufacturer screw up some resistor value they pick&place in the GFI circuit when building the boards.

I have one last thing to test and that is to repeat the experiment with the second V4 OpenEVSE controller I have on hand.  I'll do that a little later today.

-Craig K.

[Alan Kirk]

There is a way to adjust the EEPROM kWh data via RAPI interface.  It was covered in another recent post, I believe from Craig.  I'll look for it and send it on, if I find it!

From 13 Sep post from Craig:

a) I have a two part answer.  First: Yes, there is a fuse setting that either preserves eeprom during programming or wipes it.  The command avrdude -c USBasp -p m328p -U hfuse:w:0xD7:m would set it so that eeprom is preserved.  By default we use avrdude -c USBasp -p m328p -U hfuse:w:0xDF:m in batch file scripts.  Notice just one bit is flipped going from 0xDF to 0xD7.  Eeprom not only has the accumulated kWh but also all of the button menu settings.  Choosing to keep the eeprom contents can be very useful if you do a lot of re-programming.  Remember you only need to set the fuses once and they are "sticky" until you go and set the fuses again.

Second: There is a nice RAPI command to set the accumulated kWh.  You would use $SK 123456 to set the accumulated kWh to 123.456 kWh.  It is a nice way to restore your accumulation if you wipe it by accident.

b) Yes, $GV returns the firmware version and the RAPI code version, return string looks like $OK D3.9.8 1.0.3    By changing the esp8266 code that Chris has worked on you can query anything available via RAPI and post it to Emoncms.  For example on the Steampunk EVSE I modified the code to read the fault counters via RAPI and post it to my Emoncms dashboard since that build is headless and I want to keep an eye on the fault counters.

c) I'm not sure where you are headed with this one.  If you mean to log it in Emoncms then that is simple I suppose.

d) Emoncms is ideally suited to do this and it does not require any OpenEVSE firmware changes.  I have not created a dashboard that does this but maybe someone else reading this has an example dashboard showing kWh per day.

Best Wishes,

Craig K.

[chris1howell .]

Craig,

It is nothing on the board.

I have verified the boards trip at the correct current between 15 and 20ma. I can recreate the issue reliably with the same test board. On 3.7.8 (33%) Self trip fails with 1 coil but not another coil from the same batch.

Both coils pass if I downgrade to 3.4.4 (50%).

Chris

On Sep 19, 2015 1:39 PM, "Alan Kirk" <ki...@hughes.net> wrote:

There is a way to adjust the EEPROM kWh data via RAPI interface.  It was covered in another recent post, I believe from Craig.  I'll look for it and send it on, if I find it!

On Wednesday, September 16, 2015 at 8:11:04 PM UTC-7, Scott G wrote:

Last weekend I built my first OpenEVSE unit using the v4 hardware.  It came with firmware v3.9.5 and the GFCI Self-Test defaulted to turned off. When I re-enable the GFCI self test in the setup, and then I restart, it fails the GFCI self test (red screen on the LCD).  I tried this both with and without the car attached, and tried powering down, unplugging, for ~15 seconds and all attempts the GFCI self test fails.

I saw elsewhere in the forums a suggestion that the 10uF cap (C14) is not needed and could be causing this issue because it is acting as a sample-hold and keeping the 'fault' interrupt sensitive for too long. But I don't see how this would cause the self  test to fail, from what I see in the Gfi.cpp code since the self test code waits till the pin PD6 goes low and then additional 1sec before it returns.

I think I've got the GFCI Coil connector plugged in correctly (orange wires for the self-test loop closest to the AC/DC block -- see attached picture). 

The GFCI coil is reading 45.3ohm and the self test wire is reading 0.3ohm, so that seems to be OK. On Chris' suggestion, I bent the outer pins on the 4 pin connector just a little bit so the connector would fit more snugly. But when I tried GFCI self test again, it still failed. This time I only tried it with the car disconnected, but I tried both menu-initiated reset and unplug/re-plug restart.  It failed all the time in both cases.

I had taken some pictures of the back side of the board when I was assembling it, so I could check component values or any other "options" (like removed R28) after I got it together.  I don't see anything obvious in the picture, but admittedly it's a little fuzzy in the upper right corner where the GFCI input stage parts are placed.  I guess I'll have to take it apart this weekend and give it a better review, checking some part values as much as I can with my cheap ohmmeter.

I'm also hoping by this weekend to have my laptop outfitted with all the compiler and USBasp programmer drivers to go out and try burning the latest v3.9.9 dev release.

Any suggestions about what I can try or what else I should check?

--

[Craig Kirkpatrick]

Chris, I agree you and Scott are getting similar results but my results seem to contradict yours.  I'm about to try swapping the V4 since I can do that pretty easily.

Other things I experimented with to see if it made any difference was whether the OpenEVSE's +5V was burdened by any additional items.  In my case it was easy to either keep my ICSP programmer cable connected to my computer or unplug it.  Unplugged from the computer I can tell from the LCD that it burdens the +5V a bit.  That little experiment didn't change my results, still failing selftest at 1% and passing at 2%.

I'll have to really give this some thought to imagine a root cause that fits yours and Scotts data and my data also.  So far it does not make sense.  Ok, here is one idea.  Take your "bad" coil that still measures the correct coil resistance and plug in a little 4-pin header strip and measure at the pins since this is what the board sees.  Maybe the connector itself just isn't mating repeatedly to the 4-pin header.  You can tell I'm running out of ideas :-)

I'm open to ideas to experiment today if you want to throw some things at me to test.  Just let me know.  I'm now lacking my nice Oscilloscope, had to return it to Keysight.  I do have a good multimeter.

If it helps both my coils have lot# 071415

Best Wishes,

Craig K.

[Scott Gaskins]

Craig, I can get back to testing in a couple of hours, but for now I'll say that I'm going to try your 1% and 2% settings on my coil.

I'm going to try printing to the LCD from the GFI selftest code and try running the selftest in small increments multiple times.

- Scott

--
You received this message because you are subscribed to a topic in the Google Groups "OpenEVSE" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openevse/joOssmouqa8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openevse+u...@googlegroups.com.

[chris1howell .]

The trip point should be 15 - 20 ma. the 5v output goes through a 330 ohm current limiting resistor for 15ma.

The 5 turn wrap gives an power through the coil of 75ma.

The 33% duty cycle gives an theoretical current thorough the coil of 24.75ma. UL requires this to be 30ma or less. The calculations do not account for any resistance, or rise and fall times, power dissipation over time, etc. It is just not enough.

I have no clue how 2% is working for you, the current should be 1.2ma, way below the minimum trip of 15ma.

[Craig Kirkpatrick]

Chris, What is dawning on me is that maybe thinking in terms of DC resistances and DC currents is not explaining the frequency dependent characteristics of the coil.  Maybe there are resonant highs and lows reacting to the duty cycle.  I should really do some sweep of 5% increments from 5% to 50%.  Actually Scott may be way ahead of me with his idea of automating that sort of sweep.

In the past I could have used an instrument such as a low frequency vector network analyzer to excite the circuit to see the behavior over frequency.  Sucks that I don't have ready access to all that gear any longer.  I was spoiled having about $1M of test equipment at home until early August when I departed working for Keysight.

-Craig K.

[chris1howell .]

Does your board still have the 10uf Cap or did you remove it as Nick does? This may allow the quicker pulse of 75ma to trip early.

I am sure there are AC components in play. All I can tell you is the math UL required for WattZilla certification. They requested the change from 50% (37.5ma)(pre 3.7.8) to 33% middle of 20 - 30ma. We can go up to 40% (30ma) and still be compliant. We are up to 5 reported cases of GFCI issues with 3.7.8+ firmware. In all cases disabling self test returns functioning to normal.

[Craig Kirkpatrick]

Chris, I have not modified my boards in any way.  I just dropped in the second V4 I had available and the results are repeatable, same as the board I used earlier today.  Maybe there is some resonant null around the 33% point.  I'll try to scan % around that to see if I get any failures.  I'll let you know.  This is an interesting problem.  I'll have some results in about an hour I expect.

-Craig K.

[chris1howell .]

Frequency is also be a significant factor. What frequency are you running? 1% duty cycle at 1 second on and 99 seconds off would surly trip the self test. 

[chris1howell .]

Thank you for testing... It will be interesting to discover what you learn.

[Craig Kirkpatrick]

I'm trying to maintain the frequency and really just adjust the dutycycle.  The ON and OFF durations add to 16,667.  I'm about to hunt around 33% to see if it will fail.  I'll let you know soon.

[Craig Kirkpatrick]

I was not able to find a duty cycle anywhere between 39% and 29% that would cause it to fail the GFI selftest.  Still the only way I get it to fail is setting the duty cycle below 1.5%, and actually 1.5% passes but 1% fails.

I'm open to more experiments if you can suggest any.

Also it will be interesting to see if Scott finds it passing when he sets it lower than the 33% that is coded into D3.9.9 on his kit.

[chris1howell .]

Are you testing with the pre built 4 pin version? I can test a bunch of coils and send you one that fails at 33% but passes at 50%.

I think the solution is just going to be going back to 40 or 50.

[Craig Kirkpatrick]

Chris, Yes, I'm using a pre-built 4-pin GFCI coil.  You can go ahead and send me a failing coil and I'll work on getting to the root cause of this.  I won't be able to work on it until Saturday 26th since I have some other things I'm working on mid-week.  I'm very interested in getting to the bottom of this puzzling problem.

-Craig K.

[Scott G]

My test is complete.  My coil failed from 1% up to 36% and again at 98% and 99% duty cycle.

Here's the code I used, a bit of a hack from the existing GFI self test, to display on the LCD the pulse width (positive), the loop #, which corresponds to duty cycle because I changed the GFI_TEST_CYCLES to 100, and then the 'j' counter which shows how many pulse tries it took to get an interrupt.  Then between each test try I added a delay(1000) for things to settle down and I then cleared the testSuccess so we were starting over again.

I videoed the test run so I could record the values.  As soon as I get this video out of my phone, I'll post a link here.

uint8_t Gfi::SelfTest()

{

  testInProgress = 1;

  testSuccess = 0;

  unsigned long pw=0;

  unsigned long pwn=0;

  int j=0;

  for(int i=0;  (i < GFI_TEST_CYCLES); i++) {

    pw = ((i+1)*166);

    pwn = 16667-pw;

    for(j=0; !testSuccess && (j < 60); j++) {

      pinTest.write(1);

      delayMicroseconds(pw);

      pinTest.write(0);

      delayMicroseconds(pwn);

    }

    sprintf(g_sTmp,"%05lu:%02d:%02d:%02d",pw,testSuccess,i,j );

    g_OBD.LcdPrint(0,1,g_sTmp);

    delay(1000);

    testSuccess = 0;

    WDT_RESET();

  }

  // wait for GFI pin to clear

  do {

    delay(50);

    WDT_RESET();

  }

  while(pin.read());

#ifndef OPENEVSE_2

  // sometimes getting spurious GFI faults when testing just before closing

  // relay.

  // wait a little more for everything to settle down

  // this delay is needed only if 10uF cap is in the circuit, which makes the circuit

  // temporarily overly sensitive to trips until it discharges

  delay(1000);

#endif // OPENEVSE_2

  m_GfiFault = 0;

  testInProgress = 0;

  return !testSuccess;

[chris1howell .]

We may not know the exact cause but we know the solution. I am going to start sending boards out with 50% duty cycle until we verify something else works.

The only differences in the coil between a good and fail at 33% is.

Fails
.5 ohm ST
44.2 main

Passes
.4 ohm ST
45.9 main

My guess is some combination of variance in the coils causes not enough power to trip. Some users report it works sometimes and fails others.

[chris1howell .]

Hi Scott. Very good data... This is the exact result I expected. Looking forward to the video.

[Scott Gaskins]

https://www.dropbox.com/s/3fltt79ovk9s4d8/2015-09-19%2021.56.57.mp4?dl=0

In this video, the test started passing at 35% and stopped again at 98%.
Sorry for the rotated image. My phone didn't like laying flat like that.

- Scott G

On Sep 19, 2015 10:36 PM, "chris1howell ." <chris1h...@gmail.com> wrote:

Hi Scott. Very good data... This is the exact result I expected. Looking forward to the video.

--
You received this message because you are subscribed to a topic in the Google Groups "OpenEVSE" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openevse/joOssmouqa8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openevse+u...@googlegroups.com.

[Craig Kirkpatrick]

Scott, Nicely done!

[Craig Kirkpatrick]

Scott, I used your code and ran it on my test setup.  If you watch carefully in the very beginning you can see it fail at 1% and passes all of the way up to 97% or 98%.

Also interesting is how low the j counter is showing most of the time it takes just 1 try to get the interrupt.

Video from my test setup using Scott's code: http://www.youtube.com/watch?v=MZowFDVFcgU

-Craig K.

[chris1howell .]

Craig would you mind sharing your hex? I'll run the same board with 2 coils.

You received this message because you are subscribed to the Google Groups "OpenEVSE" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openevse+u...@googlegroups.com.

[Scott Gaskins]

Craig,
Yes, your coil seems much more sensitive. I didn't get to do all the fixing I wanted today with my box, so I'm going to take it apart tomorrow and I'll try to get a high res photo of the back side to verify the component values by marking.
I'm happy right now with a 50% duty cycle, though.

I got my Huzzah WiFi board, but I haven't really read up on the best way to put it in the unit or program it. So I'll be playing with that if I have time tomorrow also, and maybe adding another 12v->5v regulator to power the huzzah.

- Scott G

[Craig Kirkpatrick]

Chris, hex file is here for you: https://www.dropbox.com/s/91roj8uq5uek9la/open_evse.cpp.hex?dl=0

[chris1howell .]

Thank you, i will run tomorrow with the 2 coils then prob a few more... (I have about 400 in stock... :) )

[Craig Kirkpatrick]

I ran the second coil I have and I got the same results, only failing at 1% and above 97%.  It will be interesting to hear what you find tomorrow.

Thanks to Scott for creating the nice test code!

[Craig Kirkpatrick]

Scott, Since I had my extra V4 controller sitting here I shot a photo so you can most easily compare your components to what I have.

Also you can download a free copy of Eagle from Cadsoft and then you can open the schematic and board layout for the V4 board from here:

http://store.openevse.com/products/openevse-plus-v4-universal-charging-station-controller

.

[chris1howell .]

I do not think this issue has anything to do with the board. I have two coils, one that works at 33% and one that does not. All testing is with the same board.

You received this message because you are subscribed to the Google Groups "OpenEVSE" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openevse+u...@googlegroups.com.

[Craig Kirkpatrick]

Chris, I'm just trying to be helpful since Scott said he may take time to look at his board.  Did you get a chance to run that code with the "bad" coil yet?

[chris1howell .]

Mystery Solved...

Due to the diode in the GFCI circuit in one direction of the winding the coils tickle the circuit with more sensitivity.

Original coil

34

Ten random coils

31

1

1

32

1

31

1

1

33

1

If you swap the orange wire the 1s become 30s and the 30s become 1s... 

[chris1howell .]

Thank you for all the help Scott and Craig...

[Danny ter Haar]

On Sunday, September 20, 2015 at 2:48:38 PM UTC-7, Chris wrote:

Mystery Solved...

Due to the diode in the GFCI circuit in one direction of the winding the coils tickle the circuit with more sensitivity.

So it is the polarity of the pulse that makes the difference ?

[chris1howell .]

Yep, the GFCI circuit only measures the positive side of the AC wave. I am exploring a biased dual opamp circuit to measure both. The current circuit is fast enough to pass UL with fast contactors but measuring both + and - will open up even more.

So in one direction the rising edge is tickeling the circuit. In the other it is the falling edge.

--

[Craig Kirkpatrick]

OK.  Confirmed.  I took my spare coil and swapped the orange wires and now that one fails up thru 34% and begins passing above that.

Wow Chris, impressive job figuring that out!  I was posing frequency domain explanations yesterday...

Clearly the original code with 50% worked as designed and gave plenty of margin for reverse winding coil self-test wires.  Let us know what you think about firmware/hardware changes moving forward to address this.  My first thought is that so many folks have wound their own self-test wires and soldered one end that it is not realistic to have them remedy those coils.  Swapping wires on the CR Magnetics built coils is easier.  Give it some thought and let us know if you have thoughts about the firmware and what you want us to do there.

Great work.  Thanks Scott for the nice test code to speed the coil characterization.  And I'm glad to see we have another contributor to the OpenEVSE firmware too Scott!

-Craig K.

On Sunday, September 20, 2015 at 2:48:38 PM UTC-7, Chris wrote:

[chris1howell .]

The intent of the self test circuit is to ensure the GFCI circuit is connected and functioning. I think changing the code back to 50%, will fulfill the intent of the circuit and allow the check to function for everyone. 40% is within the UL target but a little closer to to the coil variance, I would think it would be okay.

The actual GFCI trip point is not affected regardless of coil direction so there is no issue with safety.

[Craig Kirkpatrick]

Yep.  I was thinking the same thing that the actual coil sensitivity to a real GFCI event is a bit unrelated to the coil self test and I even wondered why UL got there noses into the self-test other than admiring your innovation having the self-test.  I'll change D3.9.9 to D3.9.10 with 50% right now.

[chris1howell .]

Awesome, I will pull down 3.9.10 and run it through my tests...

Thanks again Craig and Scott...

[Craig Kirkpatrick]

D3.9.10 is there  https://github.com/lincomatic/open_evse/archive/development.zip

I double checked it with both of my coils (one intentionally reversed the self-test wires) and they both pass now with 50% duty cycle in the code.  I always like to check my work :-)

[Scott G]

Thanks, Craig. I'll be playing more with this as I have time for sure!

Did you consider replacing R23 with a capacitor instead?  If the self test is sending a 60Hz signal anyway, then a cap there should pass that signal with a zero DC bias. I don't know what value should be that's enough to trip the GFI detector, though.  Would need a little bit of spice sim. I've been working in digital logic too long to remember this analog stuff. :-)

- Scott 

[Craig Kirkpatrick]

Scott, Though I am an electrical engineer by training, I must defer this to Chris who designed the board's hardware to comment on the hardware change suggestions.

Keep in mind that thousands of OpenEVSE hardware boards are deployed worldwide.  Surprisingly large number yes?  OpenEVSE is a huge success by any measure of an open source engineering design.  I love contributing to the further success of OpenEVSE.

Scott, to play more immediately with OpenEVSE firmware you can comment out  #define DELAYTIMER_MENU in open_evse.h and it will give you 3K space to play.  All that means is you set your RTC clock first, then the menus that set the clock go away - no big deal.  Otherwise we are bumping upon the 32K ceiling for code for the Atmel328P.  It is pretty amazing what we can do in 32K!

We are not stuck with the 32K ceiling.  It will just take some time to evolve the design somewhat.

-Craig K.

.

[Scott G]

You weren't kidding about bumping up against 32k limit!!

I got some time this week to try and add a menu item to reset the accumulated kWh, and without resorting to undefining the "DELAYTIMER_MENU", I had to rework a bunch of code just to get to where I was ~20 bytes over limit.   But then I went down a rabbit hole of trying to see if I could do something else interesting with the LCD display and I discovered that the options for "MCP9808_IS_ON_I2C" and "TMP007_IS_ON_I2C" were both enabled in the development branch code, but the v4 kit from Chris didn't include those extra temperature sensor goodies.  So when I commented those out, I got back another ~900 bytes and my new menu item code now compiles.

So, as much as I think I have the new menu item implemented correctly, I'll be really finding out by trying it out this weekend -- if I get some free time away from household chores.

And if this works, I'm going to try adding a function that will auto-reset the accumulated kWh on a monthly basis, based on a setting of which day of the month the power company reads your power meter.

One question that I have after my coding this week... How does the I2C reading of the OpenEVSE RGB LCD + RTC board work if the RTC (DS3231) and the 16-pin GPIO (MCP23017) chips are both set to I2C address '000' ?  The schematic from Chris' products page (RGC_i2c_v1plusRTC.pdf) shows the MCP23017 with all 3 address selector pins tied to '0' and I don't see how the base address of the RTC chip can be changed from 0 anyway. 

Is the schematic just outdated, or is there some other way that the base address for the DS3231 gets set?

~ Scott G

[Craig Kirkpatrick]

Scott,

You probably are not waiting for an answer any longer and figured it out for yourself.  Usually I2C devices have some hard-wired default base address that you hope is unique among the devices on the bus.  Then since it is possible to want more than one of any same device on the bus the parts usually have a few address pins so you could have two or more of the same part and separate their addresses.  Finding the I2C addresses is a matter of getting the component datasheet and reading it.  Just use Google and search DS3231 and you can find the datasheet to download.  At least that is my method for figuring this out.

Glad you found other ways to free up code space.  Still my favorite is undefining #DELAYTIMER_MENU.  Once you set the clock you don't need LCD/Button to set it again unless you worry about Daylight Savings Time.  Freeing 3K is like gaining forty acres of code space to farm ideas  ;-)  Even after ridding the menus you can set the clock most easily over FTDI with the RAPI commands.

-Craig K.