J1772 Hydra

CUI has released an extra tiny 3W power supply series. It's essentially 1 cubic inch. It'a also a little bit cheaper. The one big change is that CUI recommends an inrush limiting resistor on the AC side, which should help protect the fuses from wear. This will only work for the Hydra, unfortunately, and not for OpenEVSE II. 3 watts isn't quite enough headroom to drive a 12 volt relay (which is something OE2 still supports). But the Hydra exclusively supports contactors, so 600 mA @ 5V is plenty.

This project has been pretty stable. The only two changes I'm contemplating are adding an MCP9808 temperature sensor to the board for over-temp detection and adding the OpenEVSE II AC voltmeter.

The problem with either of these options is that the Mega328 is running out of space in flash. Adding either feature would require more code, and I'm not sure it would fit.

Moreover, it's hard to squish the voltmeter onto the AC board, and would also require freeing up an ADC pin on the 328, which means firmware changes (because something non-analog would have to move from port A to port C) which would not be backwards compatible.

For now, I'm probably going to at least add the MCP9808 hardware and perhaps kick the can of software support for it down the road, but I'm probably not going to add the voltmeter.

I'm sort of torn between two SSR alternatives.

First, there's the CPC1972GSTR. This was the first one I tried, and it had a problem with reliably turning off. Adding a snubber (properly) solved this problem, though. On the one hand, it has a zero-cross circuit, which is strictly speaking unnecessary for this application and is theoretically problematic for an inductive load (though, again, in practice, with a proper snubber, it still works). On the plus side, it is physically smaller (6 pins instead of 7 - really 8), and has a blocking voltage spec of 800 volts, which is comfortably above the peak-to-peak voltage for 240 VAC and above the MOV's maximum clamp voltage. On the minus side, it's about 35¢ more expensive.

The alternative is the AQH0223A. It's absolute maximum repetitive peak off-state voltage is 600V, which concerns me. This is not only lower than a 240VAC peak-to-peak voltage, it's also lower than the maximum clamp voltage of the MOVs (though that's less concerning as that voltage would be non-repetitive). The only reason I could guess that this is working is that the load represents a voltage drop so that the switch isn't seeing the full peak voltage (but I can't really accept that fully as there would be very little current flowing with the switch off). It's also a physically larger package (but the creepage distance is not any larger - both relays have a .2" BIS separation between the switching pins, though the CPC1972GSTR does have an NC pin between that reduces the total creepage a little), but lacks the zero-cross circuit and is cheaper.

UPDATE: I think my concern about the p-p AC voltage is incorrect. The peak voltage the SSR will see is the peak, not peak-to-peak. So 339 V, which is well under 600V (and the MOV will prevent transient excursions higher than that).

So what’s left is that the CPC1972GSTR has the interloping pin that reduces the creepage distance and a higher cost. 

Today I got the 5.0 boards working properly, even with the current SSRs.

It turns out that adding a snubber across the load doesn't work. The snubber belongs across the switch. I took the snubbers I had added and patched them in across the output side of the SSRs and the problem of the B relay not turning off when the A relay is on went away.

So the boards I have coming this week from OSHPark are going to be "art." I've ordered a 5.0.1 and 5.1.1 version for delivery later this month with the snubber components correctly wired. The difference between the two boards is the 6 pin vs 7 pin SSR pinout. It turns out that the Panasonic SSR with the 7 pin (DIP-8 SMD, but with pin 7 missing) layout is about 25¢ cheaper at Q:25, and if it works, I'll probably go with it in place of the 6 pin part.

UPDATE: I got one of the 5.1 version boards back and put one together for a test. The snubber was wired to the load in this variant, but I used a through-hole resistor to hack the snubber to be across the switch. I also got AQH0223A SSRs to try. These SSRs lack the zero-cross detection circuit, which means they'll be somewhat more robust with an inductive load. That board worked and so that means that the v5.1.1 boards will be the ones to go forward. These are the same, but have the snubber properly connected.

V5.0 makes only a few changes, but they're fairly substantial.

The biggest change is that instead of the primary power supply making 12 VDC and a buck converter turning that into 5V, the primary supply is 5V and a boost converter is used to make 12V. As before, the -12V supply is derived from +12V with a charge pump. One advantage of this system is that there is a use for 5V on the HV board to run the comparator that's part of the relay test. 5V used to be sent back to the HV board from the logic board for this purpose. 12V is still fed back to the power board, but there's (presently) no use for it.

Since the boost converter and the microcontroller are both fed from the 5V bus, the controller and ISP connector together form their own separate power domain fed from the 5V bus by a MAX40200 ideal diode chip. This cuts down on how much circuitry the programmer has to power.

To give the controller board a good bench test, I designed a test bench board. It has the FFC connector, LEDs to indicate the contactor state, DIP switches to simulate the AC/GMI test circuit and a barrel connector to feed either 5V or 12V power (depending on the HW version). Unfortunately, there's no safe way to test the HV board, but the point of the design is that the HV board is so simple it should just either work or not.

With the test jig, I've been able to validate the board. Tomorrow I'll rebuild my Hydra to use the new boards.

UPDATE:

I had an opportunity to complete the build with HV board 5.0. Unfortunately, it's not perfect. The contactors showed an alarming tendency to stay closed after charging completed. The good news is that the result was an "R" error, so at least it's not a silent failure. Even adding a snubber wasn't enough to solve the problem, so the SSRs, I'm sorry to say, are fired.

The combination of EVSE board 4.4.2 and HV board 4.4 is just about perfect, so far as I can tell. The schematic for 4.4.2 doesn't differ from 4.4.1 - the clock chip is just moved to the top of the board to be away from the AC wiring.

HV board 4.4 replaces the LM358 with an LM393 comparator. Since the LM393 has open-collector outputs, it's slightly better for the relay test outputs to be inverted, which requires altering the firmware. The circuit leverages the open-collector so we don't need diodes like we did with the LM358 output. The output is an RC circuit designed to slowly rise to Vcc. The LM393 output shorts that node to ground, discharging the cap. This arrangement allows the output to be constant given a 25 Hz pulse rate (as would be the case in Europe where they have 230v H-N wiring) so the firmware doesn't have to sample it repeatedly.

That said, v5.0 is coming from OSHPark next week sometime. It won't be operationally any different, but will be somewhat simpler for me to build. It will be interesting to see how it functions given that we're constructing both pilot voltages ourselves now.

The 5.0 design currently has 5v supplied from the HV board instead of 12v, and instead of deriving 5v from 12v with a buck converter, 12v is derived from 5v with a boost converter. And then after that, -12v is derived from +12 with a charge pump.

One of the things connected to the 5v rail is the ISP header for programming the controller. In the past, I've noted that when you connect up the programmer, the display lights up because the programmer provides power. My programmer is normally configured for 3.3v, so that means that effectively the whole circuit is "browned out." This hasn't been an issue before, but I'm now concerned that the booster and the rest may be just too much stuff to ask a programmer to power incidentally. Not to mention that I'm not sure what the booster is going to do with 3.3v instead of 5 (other than just draw ~40% more current).

So that means that the ISP header and controller need to be in their own power domain, with a backfeed prevention circuit bridging the two. 

The backfeed prevention circuit starts with a P channel MOSFET connected between the Vcc and PROG_VCC nets. What's a little unusual is that the source is connected to the PROG_VCC net and the drain is connected to Vcc. At first glance, this seems backwards, but the key to the operation of the circuit is the MOSFET's body diode. It must be forward-biased in the "normal" state of affairs and reverse biased during programming. For the gate, we start with a pull-open resistor from source-to-gate of 100 kΩ. That will insure that the gate is pinned high unless explicitly brought low. This is accomplished with an MMBT3904 BJT transistor. The transistor's collector goes to the gate and the emitter to ground. The base is connected to the Vcc bus with a 100kΩ resistor. A BJT is used in this case because we want to detect the ability of Vcc to actually supply current. There will always be some manner of leakage through the MOSFET, but unless it's turned on, there won't be enough current available to switch on the BJT.

It's important that if you do this, you don't wind up having the controller's GPIO pin power the rest of the circuit by accident. This can happen if another IC connected to a controller's output has a protection diode from the input to Vcc. If this is the case, you have to add series resistance (1 kΩ is good) to keep this from happening. This isn't a problem during programming - most of the non-ISP lines are inputs then - but in the period of time between finishing programming and removing the programmer, the code will run. This can also happen if you have other devices sharing an ATMega's SPI bus. Since the SPI pins are used for ISP programming, they may need protection from other devices.

For the Hydra, none of the pins need protection. Most are inputs, and those that are outputs don't have any low impedance paths to Vcc.

UPDATE:

It's worth mentioning that I've discovered that this circuit is a simpler version of a well-known design idiom known as an "ideal diode." The difference between the classic ideal diode's behavior and mine is that in my case, any voltage at all on the +5 side is enough to close the MOSFET, while an ideal diode has a comparator between the two sides and only closes when the voltage on the "anode" exceeds the voltage on the "cathode." Typically this is done using two PNP transistor B-E junctions acting like diodes with a common cathode (base). Whichever "diode" winds up forward biased will also have collector current, and that collector current is used to pull the MOSFET gate up towards the source when the "cathode" transistor is the winner.

More about the Ideal Power Diode circuit (my favorite is variant 3) is here.

SSRs have been a thing for a while now. OpenEVSE, in fact, uses them to drive contactors (when so configured). I've been stubbornly resisting using them to this point if for no other reason than I just thought I could do better on cost and correctness rolling my own.

I can't really objectively say that anymore. The CPC1972GSTR‎ is a 250 mA capable 800V AC SSR that costs only 20¢ or so more than a MOC3041 and uses the exact same footprint. It's as if you took a MOC3041 and just beefed up the "driver" triac inside it so that it could drive real loads all by itself.

I'm still going to keep the MOV across the contactor coil outputs. That should keep any commutation spikes from reaching the SSR, but unless I get any big surprises putting the theory into practice, this part ought to be able to drive a contactor coil without any trouble.

Going with this part saves a ton of board space. Unfortunately, given the mechanical arrangement of the Hydra the board sizes are fixed, so that space is going to go to waste. But it'll still save me a lot of time pick-and-placing the components.

So this, plus the shift to a 5V primary power supply with a 12V boost converter on the logic board is going to be V5.0. I'll get them fabbed as soon as I test the v4.4.2 boards that are heading back down from OSHPark right now.

It turns out CUI has updated their power supply lineup, so we have a choice between the PSK-S3 series (either 5v or 12v) and the PSK-P5B series. The two are pin-compatible. The Hydra doesn't need more than 3W, but I may decide to just stock the 5W for common use with both the Hydra and OpenEVSE II.

One nice thing is that we can get rid of the extra 400V "intermediate" cap that we had to add for the old VSK supplies.

Traditionally, the Hydra has used a +12V AC/DC module and a +5V buck converter on the logic board, and then +5 is fed back to the AC board to run the relay test.

It's only now just occurred to me that this is a little bit backwards.

The circuit needs a lot of +5v power, but only needs +12V for two purposes: to feed the charge pump to make -12 and for the pilot generator.

It probably makes more sense to put a 5v AC/DC supply on the AC board and a +5->+12 boost converter on the logic board for the +12v needs.

Not sure when (or if) I'm going to make this change, but I'm at least going to look into it to see how feasible it is.