Raspberry Pi EVSE Hat

everything on this board works, so far as I can tell. I was able to write some python to force the relay out line low, toggle the GFI clear high briefly, then turn the relay out line on and toggle the watchdog line at 1 kHz and the little relay light on my test jig turned on. 

Everything else was the same as 1.0 and worked then, so I am waving my hands a bit at it.

So... for me, this one’s done!

I don't know if I want to sit down and write the code for a Pi EVSE. But essentially what it amounts to is a giant service loop:

• If the pilot is on, then perform a hundred or so ADC conversions on channel 0 (pilot feedback) saving the highest and lowest value seen. If the lowest value seen does not correspond to -12V, that's an error. From the highest value you can figure out the state. If it's near 12v, that's A. 9 is B, 6 is C and 3 is D.
• If the pilot feedback state has changed, then you may have to do something in response. A->B or B->A is just informational (plug in or plug out). B->C or B->D is a request for power. C->B or D->B is a request to end power.
• For a request for power, you should perform a GFI self test and then turn the power on. For a request to end power, you should turn the power off.
• If the power is on, you must toggle the power watchdog pin regularly (recommended frequency is 1 kHz, but no more than 100 kHz and no less than 100 Hz).
• If the power is on, the relay test line must be high. If the power is off, the relay test line must be low. You should allow up to 100 ms of grace after power transitions. Otherwise, that's an error.
• If the GFI line is high, that's a ground fault. Turn the power off and report an error on the pilot (stop oscillating - leave it either 0% or 100% duty). If you intend to perform an automatic GFI clearance, you should not reset the GFI until the clearance interval is elapsed. Reset the GFI before attempting to turn the power back on.
• You can perform ADCs on channel 1 to observe the current drawn by the vehicle. Collect samples for two zero crossings (zero is 512), then perform an RMS on the samples and scale it to obtain an RMS current draw. You can also perform ADCs on channel 2 to figure out the AC voltage. Look for the peak and scale that to determine the voltage.
• If you wish to change the pilot, you must give the car 5 seconds of grace to respond. That includes withdrawing the pilot while the vehicle is charging.
• Other than in response to a GFI, you should not turn off the power other than in response to a [CD]->B state change. Yanking power away from the vehicle is bad for the contactor. The vehicle will arrange for current draw to be reduced to near zero before changing state. Other than in response to a B->[CD] transition, you should never turn the power on for rather obvious reasons.
• In state A (no vehicle) the pilot should be a steady +12v. Do not oscillate the pilot in state A. A vehicle transition directly from state A to state C or D is illegal. A transition from state B to C or D is illegal unless the pilot is oscillating (an EVSE can deny permission to charge by refusing to oscillate the pilot).

The good news is that hardware PWM works and the jitter observed with RPi.GPIO is nowhere to be seen.

The bad news is that it doesn't appear to be supported by Python directly so far as I can see.

The other good news, though, is that it's fairly easy to do. It's like doing manual GPIO manipulation via /sys/class. You write a "0" to /sys/class/pwm/pwmchip0/export and in response you'll see /sys/class/pwm/pwmchip0/pwm0/ show up. Inside pwm0 you'll find "period", "duty_cycle" and "enable". Write a cycle period in nanoseconds (1000000 for 1 kHz) into "period", write the number of nanoseconds you want it to be high (e.g. 100000 for 10%) into "duty_cycle" and a "1" into "enable".

I built the first prototype and found a couple of errors on it:

1. The quad NAND gate has the wrong pinout.
2. There was no connection from the Pi GPIO header for the GFI test line

Both of those have been corrected and in addition, I replaced 3 diode-plus-pull-up level shifters with a triple bus buffer chip. It may be slightly pricier, but placing a chip and a bypass cap beats 6 passives. I also replaced the dual JK flip-flop with a single D flip-flop chip. The fact that it's a D vs JK doesn't matter in our case because we only use the set/reset functionality as a latch.

I was able to test the pilot generator and ADC and they work properly. Also the relay test input works (though there wasn't much chance it wouldn't).

On to v1.1!

Reading the ADC:

import spidev

spi = spidev.SpiDev()
spi.open(0, 0)
spi.max_speed_hz=1000000 # 1 MHz
spi.mode = 0
chan = 0 # 0..3 for MCP3004
buf = [1, 0x80 | (chan << 4), 0xff]
spi.xfer(buf)
val = ((buf[1] & 0x3) << 8) | buf[2]
# val is output, from 0-1023.

While the ADC is rated (at Vdd=5V) for 3.6 MHz, it seems like going above 1 MHz makes its linearity suffer. Not sure why. Still, that's well over 40k samples per second.

To test the pilot, do this in a tight loop, say, 500 times capturing the low and high reading. In theory a pilot voltage of -12v when presented to the divider network should result in an ADC voltage of about 900 mV and a +12v should read as about 4.55v. Those two values from the ADC are 184 and 932 respectively. Between those two values the scale should be linear.

Add this to config.txt:

dtoverlay=pwm,pin=18,func=2

That will populate /sys/class/pwm so that you can properly generate the pilot signal on GPIO18.

You also need to enable SPI with raspi-config for the ADC.

Nothing else special needs to be done for the remainder of the GPIO pins.

EDIT:

Well, maybe you need the overlay, maybe not. It depends on whether you want hardware PWM or not. For python's GPIO.PWM functionality, you actually don't want to use hardware PWM, but it remains to be seen whether the python methodology is going to result in a stable enough output.

EDIT 2:

Yeah, the overlay is going to be necessary. I haven't built the hat yet, but I took a look at the output from GPIO.PWM and it's jittery as hell. Definitely not clean enough for this.

I've fleshed out the preliminary schematic and it's now complete. In addition to what was sketched out as a design before, there's one more feature. There is now a hardware watchdog whenever the power relay is turned on. This watchdog requires toggling a pin every so often (my own recommendation will be at least once every 10 ms) whenever the power is on as a proof of life. If the watchdog is not triggered, then it will eventually cause the equivalent of a GFI event, forcing the power off. The watchdog is disabled whenever the power is off. Whenever the power is on, it's an EVSE's duty to continuously monitor the pilot impedance feedback to check to make sure the vehicle still desires power. Leaving the power on when it's not requested is a serious safety failure.

The ADC I've chosen is the MCP3004. It's a 10 bit, 4 channel ADC and it's pretty fast. It's connected up to SPI channel 0, so for Linux, you'd use /dev/spidev0.0 to talk to it. You perform a 3 byte bidirectional transfer, sending 0x1, 0xn0, 0x00 (where n is a code that selects which channel you want to read), and at the same time you'll receive 3 bytes, the last 10 bits of which will be the ADC reading. You can use a clock speed up to 3.6 MHz, though with the diode-and-resistor level shifter, 1 MHz is probably about all you can expect (this will have to be tested). Channel 0 is the pilot pin, channel 1 is current transformer and channel 2 is the AC voltmeter from the HV board.

I'm not sure where to go next. I don't really have a *need* for a Raspberry Pi based EVSE. I'm sort of hoping I can sort of put this design out there and a great horde of hackers will descend and run with it, but that's probably wishful thinking.

I've uploaded a preliminary schematic. Copied from OpenEVSE II is the GFI, +12 and -12 power supplies and the pilot generator.

The new bits are the Raspberry Pi interfaces. In particular, there's a bit of logic around the GFI and relay output that needs some explanation.

When a ground fault happens, the !GROUND_FAULT net will be brought low. That will cause the flip-flop to turn on, which will bring it's !Q output low, which will force the relay output off regardless of its state. The flip-flop can be reset with the PI_GFI_CLR pin, but only if the PI_RELAY signal is off. This means that you can't clear a GFI fault without turning the relay off first. This is a bit of belt-and-suspenders insurance against the software doing something dumb.

There's also a GFI_TEST line. The idea here is that you're supposed to pulse the GFI_TEST line with a 60 Hz square wave (bit-banging in software would be sufficient) and you should see the PI_GFI_SENSE line turn high. After waiting a little bit and pulsing the PI_GFI_CLR line briefly you should see PI_GFI_SENSE go low and stay there. That insures that the GFI functionality works properly. The output of the test circuit goes to a wire that takes 3 or 4 turns through the GFI CT coil and then connects to ground. The 60 Hz pulses will simulate a residual current. This GFI test should be performed immediately before the relay is turned on, every time.

The 5 volt supply is brought in from the FPC connector to the HV board. We also get the relay test / GCM signal and pass that (through a level shifter) directly to a pi GPIO pin. The idea is that this pin should follow the state of the PI_RELAY pin (modulo some switching latency). If it's on when PI_RELAY is off, then that's a stuck relay. If it's off when PI_RELAY is on, then that's a ground impedance failure.

What's still missing is an ADC for the pilot sense. This will be slightly complicated since the SPI lines on the Pi are 3.3v and we would prefer the analog reference voltage to be 5 volts. This will probably require some sort of level shifting. We could use an i2c ADC instead, but I really prefer SPI. We'll see. We also need to choose how many channels to make the ADC. We only need one channel for the pilot feedback sense, but with 3 channels we could also sense input AC voltage and add a current sense CT for power logging.