Start a new topic

Raspberry Pi EVSE hat

This isn't really OpenEVSE, but I wonder if there's any call for a Raspberry Pi EVSE hat. It would have the following functions:

1. A PWM generator for the pilot.

2. An ADC to sense pilot feedback.

3. A relay output tied to an on-board GFI circuit. A ground fault would cut the relay without any software intervention. The software would be able to sense that a GFI happened and reset the GFI detector.

This would potentially interface with my OpenEVSE II HV boards. Those boards would be able to provide GCM and 5V power for the Pi.

1 person likes this idea

1 person likes this

Will the GFI be able to recognise DC faults as well? Just thinking off the top of my head here but I believe conventional GFIs get locked up by DC current saturating the sense coil. Would it be possible to detect this using a second coil that's effectively a two-winding transformer with the supply leads running through? In normal operation the EVSE puts a wave into one winding, senses the same wave coming out of the other and all is happy. If the GFI coil gets saturated by DC leakage this second coil would also get saturated, trashing the output wave and revealing the fault.

It may even be possible to dovetail this into your 10ms watchdog circuit, by feeding the pulses to one winding and the other winding to the watchdog. Saturate the coil and the watchdog doesn't get fed.

I could be talking absolute rot but I thought I'd put it out there on the off-chance that some of it's sensible.

I believe the GFI circuit already would catch a DC fault. Any residual current excursion over ~17 mA or so will cause it to trip. Keep in mind that even an AC detector would catch a DC fault, since a fault has to have  a beginning moment, and that moment will be a transition that will be AC in nature. That's always the case.

But isn't DC saturation how the "trip lock" function on wiring loop testers operates?  They don't detect the change when the DC is introduced, and would only have one chance to do so.

There’s no opportunity for the GFI to saturate. The instant the residual current reaches the threshold it trips. If you have balanced DC traveling through a GFI coil (which you never would here), the coil doesn’t “see” anything that would saturate it.
And once a GFI trips, the source of power ostensibly goes away. If the vehicle imposed a voltage on the AC lines with the source power off, well, there’s nothing the EVSE can do about that.

UK wiring regulations now require EVSEs to be protected by a type A or type B GFI.

Both detect pulsating DC.

Type A will continue to function as an AC GFI in the presence of up to 6mA smooth DC but does not detect the DC.

Type B detects both AC and DC.

If a new design (and your Pi-Hat design has a lot of potential in my opinion due to the flexibility such a large controller provides) caters for DC faults without offloading the job to a dedicated breaker then it could bring down the overall EVSE cost and make it more appealing for companies who may want to base their own EVSEs on a Pi instead of an OpenEVSE or Mainpine. As it is they ought to fit the appropriate breaker either in the EVSE or upstream of it, which would also be the case for OpenEVSE and presumably Mainpine-based ones as well.

More details on the GFI (RCD) requirements here and here.

Well, the GFI on the pi hat is exactly the same as the OpenEVSE one (up to the point where the hardware flipflop starts the latching portion of the design). If there are improvements required, they should be universal.

But I still don't see anything that suggests that the OpenEVSE GF detector is inadequate.

Is there scope for shrinking the hat at all, or is the layout too cramped? Anything that could help this get shoehorned into a DIN rail enclosure (say with a Pi Zero rather than a full-size Pi) could set it up to be the ultimate upgrade for a Mainpine-equipped EVSE.

If I didn't already have an OpenEVSE I'd be seriously tempted by this, having recently been bitten by the Pi bug (I've got Domoticz, Ubiquiti Unifi and an Apache web server running on a Pi 4 and it consumes even less power than the Atom-based Acer One netbook it's replaced).

It could be made smaller. You can always sub out SSOP or QFN parts where available. The design is open, so there’s nothing stopping someone from going for it. I am probably going to leave it where it is, at least for now.

I would be remiss if I didn't add, however, that if you google "Pi DIN rail mount" you get a nearly infinite supply of options, the majority of which would accommodate a 3ish wearing a hat. :D

Login or Signup to post a comment