Connector release on power fail

[zharijs]

Hi. I must be missing something trivial, but I can't find any code line to unlock the Type connector when power fails. Now to think about it I don't see how the hardware should know that power is failing either. Can anyone tell me how is this feature supposed to work?

[mstegen]

That was a feature on SmartEVSE v2, but unfortunately i could not get it to work on v3. On v2 it worked automatic, when there was a power loss, the CP signal would not be stable, and a state change from state C to A would be triggered automatically.

[zharijs]

I'll look into that. I've used voltage divider + Zener diode to ground connected to one of SSR pins configured as input with interrupt attached. Handler pretty much mimics same thing that RCM fail does, using unused error flag to mark it. It works stable, but of course, it takes the pin away from one of the SSRs.

I'll see if I can come up with something killing CP instead and report back.

[zharijs]

Here's an idea. Using one gate 74125 circuit powered from 3.3V, A tied to GND, Y goes to ESP CP pin and /OE goes to resistor divider + 3.0V Zenner to GND. In addition I'd like to have a Schottky diode in series of 12V PSU. Something like MBR540 or alike.

So:

• 12V falls fast (before diode) on power loss but it falls slow after diode on large cap keeping buck running.
• /OE gets engaged by falling voltage on resistor divider, turning 1G125 output from Z to LOW, virtually tying CP pin of ESP32 to GND.
• Software exits C state and releases the cable.

I'll put it together and test it out..

[zharijs]

So waht I just tested in hardware and what worked:

• I've changed the series resistor for tank capacitor - now it's 30 times smaller and on the output of 220V PSU together with series diode. This keeps the buck from oscillating because of the R-C of the tank cap and series resistor network.

• I've added the series diode to isolate the source and measurement (detection) path from the tank cap, so measured ramp would be steep falling at power loss while system voltage drops slowly, feeding from the tank cap.

• 74LVC125 has tri-state output and negative OE pin, so when power fails, OE is engaded.

• Input A is tied to 3.3V, so when the OE is engaged, it's overriding the measurement of CP voltage with max V, this breaking the "C" state and triggering the unlock.

Here's my proposition schematic for next release (changes in red squares):

Here's the signals:

• Magenta: 12V from PSU
• Orange: 12V after diode and resistor on tank cap
• Magenta: CP-IN on ESP32 pin
• Green: 3.3V on buck output

Fork (different display used, so changed init for display): https://github.com/zharijs/SmartEVSE-3/blob/main/schematic/smartevse%20v3%20unlock%20fix.PNG

[zharijs]

Oh, and also external devices (sensorbox, etc) should be powered before the diode, so they would not drain the tank cap...

[zharijs]

One more thing - if you use the diode after the 220V PSU and power the RCD before it, RCD will fail immediately after power loss so if always used with RCD, you would not necessarily need the 741G125 with voltage divider, adding diode and powering RCM before it would be enough. Tested with WA RCM14-03

[zharijs]

Did some more testing, cleaned up some power-up and power-down issues - here's the final version I am happy with at the moment. Note - I use MPS power supply and different LCD, so do test on your system before using.

[mstegen]

Thanks for your tests and suggestions. I'm a bit worried about the voltage drop on the 12v rail caused by the diode. Will have to verify if the CP output still reaches a high enough level. Also the 3R3 resistor will cause C14 to charge at a peak charge rate of >3A, as the PSU can only supply 420mA, i don't think this will work reliable. But i like your idea's. Will probably implement a power fail detection on a future version. I'm thinking on using a optocoupler connected to mains, with some series resistors, just like is used on the Sensorbox.

[zharijs]

I'm a bit worried about the voltage drop on the 12v rail caused by the diode. Will have to verify if the CP output still reaches a high enough level.

There is no voltage drop as measurement path is powered before diode in the latest version. The drop did not mess with the measurements enough anyway, but still I thought about that too and moved the front-end and charge-pump to before the diode. No point in keeping it powered during power loss anyway.

Also the 3R3 resistor will cause C14 to charge at a peak charge rate of >3A, as the PSU can only supply 420mA, I don't think this will work reliable.

PSU has some sort of soft-start so the peek charge for the tank will not be as high. I can test the actual value with current probe on scope later. The 100 Ohm large resistance introduces 2 issues - first, it makes RC that oscillates with the buck converter shutting down and coming up again, 2nd - the ESP32 takes much more power than PIC. In v2 PIC was held powered up for long enough with 100 Ohms in series easily, powered through LDO, but ESP32, especially if transmitting, will die with 100 Ohms in series between power pin and power source (tank cap during power loss state) and buck is shutting down and coming back up, etc.

I will run more boot loops and see how it comes on after longer off state and so on, maybe the resistor has to be bigger, but definitely it can not be 100 Ohms with ESP32 and buck.

Never the less, I'd recommend the diode instead optocoupler solution - you have effectively same reaction time, less parts, simpler design, cheaper, no need to consider creepage for another component. No need for peek detector (because it's DC instead of AC). Not like it's hard to implement in SW or HW, but why if you could do without?

Actually using RCM de-power to trigger state change -> unlock works really well, so I will likely ditch the 1G125, just leave the power diode there for that. I would not use the system without RCM anyway.

Also, one more thing - you might consider ESP32S3mini as you care about I/O count more than about the flash size. ESP32S3mini has

• Considerably more I/Os.
• Better ADC
• Smaller size
• built-in USB controller with JTAG interface supporting download, serial on semihosting and real debug with breakpoints and register / memory / variable monitoring.
• All pins are usable - internal SPI flash pins are dedicated and are not routed to module's pins.

Sure, take whatever sticks. I'm just giving back to community after leeching, you know...

[mstegen]

Ah i see now that you connected the opamps before the diode. Good. Yes the 100 Ohm charge resistor causes oscillations, when powering down, i have seen that too. I'll do some experiments with other (lower) values. I agree that the best part is no part. Will consider the diode solution. Next version will most likely use a ESP32-S3, as i then don't need the CP2102 any more. Not sure if it will be the mini, as i heard that they are more difficult to solder on reliably, and there is no easy way to rework them. Anyway, thanks again for your suggestions!

[mstegen]

With a 3.3 Ohm resistor the 5W PSU is stuck in hickup mode. The unit will not power up. Increasing that to 12 Ohm did not resolve it. Only with a 50 Ohm resistor i got it to work.

But i think i can make your idea work by adding a diode in reverse, parallel with the 100 Ohm resistors , so that the tank cap will not discharge over the resistors, but through the diode.

Leaving the resistors at 100 Ohm reserves some current for attached Led's and the sensorbox. And it still charges the cap in ~5 sec's, that's fast enough.

[zharijs]

Not sure if it will be the mini, as I heard that they are more difficult to solder on reliably, and there is no easy way to rework them.

From my experience, it's not much harder. The contacts are bit smaller and closer, but they are still huge in comparison with your typical 0.5mm pitch DFN / QFN.

If it's about the center pads - you don't have to solder them for the module to work. They are GND and module has GND plane anyway, so for testing purposes you can just solder the side pins. That's what I do and never had issue wit that.

as i then don't need the CP2102 any more.

I did have an issue with built in JTAG once, I managed to brick the thing by bad firmware in a way that I needed the classic 2 transistors + serial to upload the code and then built in JTAG worked again. It had something to do with boot-looping before JTAG firmware can start or something along those lines. I think the issue is that USB part of the JTAG is implemented in software.

So I'd keep some pads for the serial cable, maybe keep double-transistor too, so you could use of-shelf USB CP21xx, FTDI or CH340x cables directly with no need for special cable.

Mini does have smaller flash though, so check that it fits your future plans, if you consider it.

[zharijs]

With a 3.3 Ohm resistor the 5W PSU is stuck in hiccup mode. The unit will not power up. Increasing that to 12 Ohm did not resolve it. Only with a 50 Ohm resistor i got it to work.

Yes. I tested it with VTX-214-005-112 and it can't properly start with such small resistance. With 10 ohms it started fine for me, but some of the times it hickuped before starting. I do have FBM in series with the resistor though, so that adds a bit of resistance and filtering there.

VTX hiccupping before starting with 10 Ohms + FBM

I too ended up with 47 Ohms + FMB when I had no hiccups anymore and a bit faster cap charge.

And it still charges the cap in ~5 sec's, that's fast enough.

It's not enough to open the lock, if you power it up with closed lock. It opens halfway. With 47 Ohms it opens fully. I'm testing with Phoenix contacts Type2. If you want to know exact PN, I have to check Phoenix order history.

With 47ohms you can see the cap is barely charged enough for the startup unlock. You can increase the delay in SW of course.

• Cyan - 12V from PSU
• Orange - Tank voltage
• Green - One of motor driver output voltages
• Magenta 3.3V rail from PSU

adding a diode in reverse, parallel with the 100 Ohm resistors

Yes, that's a good point - reverse diode across the resister would add more consistency and remove oscillations form 3.3V buck. There is still one oscillation right after the marker (magenta = 3.3V dip and recover for a bit) with 47 ohms. It should be fixed by reverse diode in parallel though. Will try later.

PS: first cursor is where unlock actually happens due to tying the CP_IN to 3.3. The signal is cut to max at few ms, delay is what it takes for FW to change states and is0sue command. I'm thinking of routing the 1G125 to override the RCM signal, that works faster. Not that it's not enough as is, but I'm a bit worried about edge cases. Like -25 Celsius, motor is cold, lube gets hard, capacitor looses some of it's capacity, the process takes longer... I'd rather have the unlock triggered sooner than later.

H.

[zharijs]

Oh, I'm dumb. The motor driver can be routed on the primary side, before reverse diode - then it does not matter how fast tank cap is charged as long as it is charged before power is lost.

[mstegen]

In a next version prototype i have a second uC that can unlock the Lock on a power failure. Power failure is detected with a voltage detector circuit (similar to what is used in the Sensorbox), to sense the voltage between L and N. So it's very quick to react.