Description

I became a Maker shortly after I got my first Electric Vehicle. I was a HeathKit kid back in the day, but wound up doing software because I saw surface mount as The End of the home hardware hacker. Turns out I was wrong, but that's another story. My EV led me to discover OpenEVSE, which led me to Arduino, and then to EAGLE and OSHPark and the rest is history.

I got the EV because there were charging stations (EVSEs) at work. But they were oversubscribed, and frequently used at only half their capacity (most public EVSEs are capable of 6.6 kW, but most older LEAFs and all current PHEVs only charge at 3.3 kW). The Hydra was born from a desire to allow these EVSEs to be used at their full capacity.

It would be easy to build a box with a J1772 inlet and two plug/cable sets, but I wanted to come up with a solution that was safe and as compliant with the relevant standards as it could be. The Hydra is the result.

Details

There are two variants of the Hydra. One is the "splitter" variant. It has a J1772 inlet and two plug/cable sets. It was the original version of the Hydra. The other variant is the "EVSE" variant. It trades the J1772 inlet for a simple AC power cable. To be compliant with the standards, the EVSE variant has a GFCI for safety (the splitter doesn't because the host EVSE is assumed to have one). The EVSE variant also has a clock/timer chip and the firmware has an event system to facilitate allowing EV charging to happen only when electric rates are lowest.

Both variants offer two different operating modes. In "shared" mode, the rules are that if both cars are requesting power, each will be allotted half of the power available (the available power is indicated by the host EVSE for the splitter variant, and is a user configuration parameter for the EVSE variant). When one car finishes (or if only one car is connected), then that car is allowed full power. In "sequential" mode, only one car is allowed to charge at a time. When the charging car finishes, the opportunity to charge will be offered to the other car. The benefit of the Hydra is that the plug doesn't have to be manually moved from one car to the other (potentially at 2 AM for ToU charging).

Sensing the amount of available power (for the splitter variant) and informing each car of the available power is done via a signal wire within the J1772 cable called the "pilot." The EVSE indicates its availability by presenting a +/- 12 volt 1 kHz square wave on the pilot line with a 1 k-ohm impedance. The duty cycle of the square wave is the indication of the ampacity of the EVSE. The car accepts this offer by loading the pilot line with a particular resistance value in series with a diode to ground. The two most common resistor values are 2.7 k-ohm and 882 k-ohm (or 1.3 k-ohm in parallel with the 2.7k-ohm). The 2.7 k value indicates the presence of the vehicle. It will bring the 12 volt pilot down to 9 volts (due to the 1 k source impedance). The diode will prevent the resistor from impacting the negative portion of the square wave, which will remain at -12 volts. This is an important safety feature that allows the EVSE to distinguish between a vehicle and a bucket of salt water that has JUST the right resistance. Adding 1.3 k-ohms in parallel with the 2.7k will drop the voltage down to 6 volts. The host EVSE monitors the voltage of the pilot output to detect these state changes from the vehicle and turn the power on and off.

The UL specifications for charging stations require a number of safety systems, and the Hydra makes every attempt to include them all. These include:

A GFCI circuit - stops charging instantly if residual current leakage is detected in excess of 20 mA. This is present only on the EVSE variant (the splitter variant relies on the presence of a GFCI in the host EVSE).
A ground impedance monitoring system - stops charging if current flow to the system ground is not possible, or excessive impedance is detected.
A relay status test - checks to insure that voltage is present on the J1772 output side of the contactors if and only if the contactor is actively engaged.

The instructions here are for both the version 5.x Hydra EVSE and splitter variants.

Theory of operation

Follow along with the schematics in order to see what's going on. Each section will reference a different page of the schematics

HV board

The HV board has 4 jobs:

Provide 5 VDC power for the logic/display board
Perform a GCM (ground continuity monitor) test to insure the path to ground is functional.
Perform a relay test to insure that there is power on the load side of each contactor if and only if that contactor is engaged by the firmware.
Switch the contactor power on and off for each car.

The 5 VDC power is provided by an isolated power supply module. It can provide up to 5 watts,...

Files

Hydra_II_EVSE_5_0.pdf

Adobe Portable Document Format - 110.76 kB - 02/08/2019 at 08:54

Preview

Hydra_II_EVSE_5_0.sch

sch - 672.15 kB - 02/08/2019 at 08:52

Download

Hydra_II_EVSE_5_0.brd

brd - 207.35 kB - 02/08/2019 at 08:52

Download

AC_board_5_1_1.pdf

Adobe Portable Document Format - 37.00 kB - 02/20/2019 at 19:16

Preview

AC_board_5_1_1.sch

sch - 280.05 kB - 02/20/2019 at 19:13

Download

Components

1 × Power distribution block Cooper Bussmann 16220-2

1 × 3 wire SOOW cable - 4 feet - sized for desired ampacity Available from Home Depot.

2 × Current Transformer CR Magnetics CR8420-1000

2 × Current Transformer - GFI CR Magnetics CR8420-1000-G

1 × Water resistant, lit button Available from AdaFruit or the OpenEVSE store

Project Logs

Collapse

Yet another power supply
Nick Sayer • 07/12/2021 at 14:24 • 0 comments

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.
Stability
Nick Sayer • 08/03/2020 at 16:34 • 0 comments

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.
Torn between SSR alternatives
Nick Sayer • 02/26/2019 at 19:03 • 0 comments

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.
Update on the SSRs
Nick Sayer • 02/14/2019 at 20:46 • 0 comments

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.
5.0 build report
Nick Sayer • 02/08/2019 at 07:38 • 0 comments

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.
4.4.2 build report
Nick Sayer • 01/24/2019 at 18:01 • 0 comments

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.
Protect the programmer
Nick Sayer • 01/18/2019 at 18:07 • 1 comment

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.
SSR contactor drivers
Nick Sayer • 01/16/2019 at 21:01 • 0 comments

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.
More on power supplies
Nick Sayer • 01/16/2019 at 18:09 • 0 comments

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.
Changing up the power supplies
Nick Sayer • 01/14/2019 at 19:05 • 0 comments

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.

View all 21 project logs

Build Instructions

Collapse

Step 1

First, start by preparing the outer chassis. Remove and set aside the lid. Select one of the two short sides to be the top. This side will receive the button for the user interface. The opposite short side will receive either the cable gland for the AC supply cable (for the EVSE variant) or the J1772 inlet (for the splitter variant). The two long sides will each have a cable gland for a J1772 cable for each car.

The button hole is 5/8" and should be simply centered on the top side. For the two J1772 cables, you want each to be centered vertically between the back and the front, and as close to the bottom "rib" on the inside of the chassis as you can. The easy way to do this is to take the outside diameter of the cable gland, divide it by two, add a quarter inch and measure that distance away from the rib and mark a vertical line from the back to the top edge of the chassis. Drill the appropriate size hole for the cable gland centered on that spot.

If you're building the EVSE variant, then center a hole for the AC cable gland in the bottom side of the chassis. If you're building the splitter, then you want to mount the inlet as close to the top edge of the chassis as possible, but without extending past it. Even if you're careful to do to, you may find that the mounting hardware hits or gets in the way of the internal mounting plate. If that happens, you will need to cut relief notches in the mounting plate.

Step 2

Prepare the button by connecting three wires to a 3 pin .1" female SIP header. The center pin should be red, the outside pins green and black. The button will have 5 terminals on it, marked +, -, C (or COM), NO and NC. Connect the red wire to the + terminal, the black wire to the NO terminal and the green wire to both the - and the C (or COM) terminals. Set the button aside for later.

Step 3

Prepare the internal mounting plate. You will drill holes to mount the two contactors, the power distribution bus, the ground bar and the standoffs for the boards.

The plate can be divided logically into the top and bottom half along the center, which is defined by the two half-moon cuts that accommodate the center ribs on the long sides. The top half (where the button will go in the chassis) will take the logic and HV boards, one above the other. The bottom half will get the ground bus, the power distribution module and the two contactors.

The power distribution module is mounted centered horizontally, flanked by the two contactors. The two contactors should be mounted as close to the center as possible to allow room for the J1772 cables to enter via their glands below the contactors. The distribution module should be mounted towards the center as well to allow room for either the inlet and its wires or for the AC cable gland and the GFI coil. Mount the contactors first and the distribution module second. This makes it easier to get to the screw holes at the base of the contactor since the distribution module will be in the way if it's mounted first.

The ground bus should be mounted in an out-of-the-way spot below one of the contactors, making sure that it will be easy to route the three main ground wires (each J1772 cable and the inlet or AC ground) to it, but that it won't be anywhere near any of the contactor, inlet or HV bus terminals.

Using either of the two PCBs as a template, mark the four corner holes in the top half. The boards should be centered in the available space, but at least an inch and a half away from the top edge (to leave room for the button). Drill 1/8" holes to accept \#4 hardware. Attach a 1/4" \#4 M-F hex standoff in each hole, securing it on the bottom with a lock washer and a nut. Place the HV board on top of the standoffs, with the 5 screw terminals towards the bottom. Secure the HV board in place using the longer \#4 M-F hex standoffs.

Discussions

Brandon Kruger wrote 08/13/2022 at 14:33

I purchased one a couple years ago and finally got it put together but I am not having any luck. Side A gives a GFI error half the time I connect a vehicle, the other half of the time charging just never starts even though the vehicle can see available amps. I have verified connection from pilot pin to Hydra board. Side B will give a GFI error half the times a vehicle is connected and will actually charge sometimes, but gives an overcurrent error (18A on 16A pilot) when only 16 amps are actually being pulled. I've rebuilt the thing twice following instructions to the T but getting the same results. Any advice?

Are you sure? yes | no

Nick Sayer wrote 08/13/2022 at 15:43

I used to have a Bolt that caused GFIs fairly often. It was annoying and I never found an acceptable solution to it. The lease ended on that car and it was replaced with a MachE that now rarely causes a GFI.

I’m sure that the issue is some sort of deficiency in the GFI that causes it to be sensitive to inrush or something of the sort, but I’ve never discovered what the solution should be. The GFI does have a low pass cap installed in one of the amplifier circuits to cut down on high frequency noise causing nuisance trips, but that apparently isn’t enough.

As for the over current, you can attempt to calibrate the current sensor by changing the constants in the firmware and updating it. Building the firmware requires fetching a few oddball Arduino libraries and modifying the hardware.txt for a “bare” ATMega328PB.

For the difference in behavior of plug A, I would recommend using an EV simulator to examine the behavior. I assume you have two cars and swapping the plugs between the two cars shows that the misbehavior is consistent between them. It’s possible the pilot generator is misbehaving, and measuring the peak voltages in various states should show what’s up.

Are you sure? yes | no

Lance wrote 07/01/2018 at 19:36

Hi Nick, just wanted to check in and say that I finally built my Hydra EVSE variant. It appears to be up and running. A few of the hookups were a bit confusing because the silkscreen on the logic board was partially covered up by the connector, or the pictures or didn't match the instructional text exactly. The GFI circuit is one example. It wasn't clear which pin corresponded exactly to which wire. Looking at your pictures, in one example you had a red and 2 black wires (IIRC) and in another a green, a BLUE and a red. Going with the latter picture, I connected them in this order (L to R): Green, Black, Red and all is well.

BTW, my splitter variant ended up failing on one of the outputs. The contactor would audibly close, but the car didn't actually draw any current. I suspect some kind of a pilot issue, although I did check the connections and couldn't find a fault there. Anyway, I stopped using it because a splitter with only one output is kind of useless. Plus a change in commutes and vehicles (I upgraded to a 30kWh LEAF) changed our charging habits such that we could effectively plug share a single EVSE. But I am about to sell my LEAF and with it will go the 240V upgraded portable EVSE. It's being replaced with a Tesla Model 3, which could work fine from a NEMA 14-50 using the UMC, but that would leave my wife's Volt charging at 120V, so it was time to build the Hydra EVSE.

Anyway, thanks again for the great work on the project. Looking to get a lot more use out of it.

Are you sure? yes | no

Nick Sayer wrote 01/14/2019 at 17:53

Have you considered building the EVSE variant? That would give you two J1772 plugs from your one NEMA 14-50 outlet. It's a little less "hacky" than using the splitter. I originally designed the splitter for my Day Job office where there were hardwired pre-installed EVSEs and we wanted to charge two LEAFs or PHEVs at the same time with them (we stopped using them because we moved to a new building where the EVSE placement is such that there's no opportunity to share a plug between multiple parking spaces).

"Upgrading" your Hydra from the splitter to the EVSE variant just requires replacing the logic board (you may need to replace the AC board depending on what version it is), replacing the inlet with an AC cable and adding a GFI coil pair assembly. You can do all of that and still preserve most of your investment.

For your failed output... a few things to try...

0. Do both plugs behave the same way? If so, then this may be a compatibility issue of some sort with your vehicle. If not, then it's likely a failure somewhere.

1. Temporarily disconnect the car plug's proximity line from the logic board (if you had one connected). If that suddenly allows the car to charge, then that's where the problem lies. For the splitter variant, the car's proximity wire is only used to warn the cars that the splitter inlet is being disconnected. You can use the splitter without proximity wires, but the rule there is that you must not disconnect the inlet without disconnecting the vehicles first (the risk is that you'll cause arcing).

2. You can use an EV Simulator (I sell one on Tindie) to "pretend" to be a car and analyze the pilot. It's conceivable that the pilot generator has failed, though I would consider it extremely unlikely that the contactor would turn on with a bad pilot.

3. Depending on how old your Hydra is, your splitter variant may not have the relay test system. If it doesn't, then you can't actually be sure power is being supplied to the car without testing it yourself.

Are you sure? yes | no

Lance wrote 03/16/2017 at 14:04

Hi Nick...me again! We recently moved to a new house. I left my old EVSE at the old house and for the time being I have been using my 240V upgraded Nissan portable EVSE as the host EVSE (I am getting ready to build the standalone version of the Hydra so this is only temporary).

I have noticed that my Hydra goes into PAUSED state several times during charging. Examining the code it appears that the incoming pilot signal indicates less than 12A and causes the Hydra to turn off the pilot signals to any cars that are charging. I suspect this might be happening because even though the portable EVSE was upgraded to handle 20A operation, it does get warm during use and perhaps it is throttling back (but not completely turning off) its max current briefly (usually the unit comes out of PAUSE after a few seconds and charging proceeds). The problem is that my wife's Volt does not like this very much. She gets an error message that charging was interrupted on her console the next morning. Not to mention that we both get texts from our cars when charging is interrupted in this fashion. It's not a severe error really, but to my wife any error message is severe.

So my comment:

When I use just the portable EVSE without the Hydra, charging is not usually interrupted on either car. I wonder if the portable EVSE throttles back to between 6A and 12A, but Hydra gives up at 12A because it thinks it needs to be able to split the power. However, if only one car is plugged in and actively charging, it really could go down to 6A. Wondering if some logic could be added to handle this case.

Are you sure? yes | no

Nick Sayer wrote 01/14/2019 at 17:58

The splitter variant should display the inlet pilot's power allowance in the top line of the display. If the host EVSE were throttling based on temperature, you'd see that number go down. If the incoming pilot drops below 12A, then the splitter will, indeed, pause with the code as-written. The best suggestion I have for debugging this is to connect something to the serial output on the board and capture the debug output. That will tell you why it's happening.

You could hack the firmware to make a special case just for your situation - if the pilot is oscillating, but less than 12A, you could (instead of pausing) force both car pilots (if active) to 6A. I wouldn't really add that to the normal firmware because it is, in principle, a violation of the spec to offer more to the cars than the host EVSE is presenting.

If I were designing a host EVSE with temperature protection, though, I wouldn't reduce the output power, I'd just stop pilot oscillations entirely to force the vehicle into state B. If your host EVSE is doing that, then that too would explain the pauses. The splitter violates the spec by presenting the state C impedance whether the host EVSE is ready or not (a "vehicle" is not allowed to enter state C unless the pilot is actually oscillating).

The splitter offers a design choice that solves this problem, however. If you supply 120/208/240v power to the AC IN terminals on the power board from some other source, then you can open the "INT_PWR" jumper on the logic board. In this configuration, the splitter will *not* force the host EVSE power on permanently, but instead will only enter state C when at least one vehicle contactor is turned on. If you do this, you must use the same voltage supply as the contactor coils (but it does not have to be the same voltage as the car power). The external power supply need only supply a handful of watts - it's just powering the logic systems of the splitter itself and the contactor coils. You could just use an ordinary NEMA5-15 plug and household socket (you would, however, need to use 120V contactor coils).

Are you sure? yes | no

Lance wrote 01/15/2019 at 19:29

Hi Nick. I did in fact build the standalone variant and it has been working reasonably well. The main issue is that the GFI protection trips pretty "easily". Actually it's been better lately, so wonder if it's a temperature dependent thing. Unfortunately because it does trip occasionally as soon as I plug into the car (or when the car initiates charging in the middle of the night, say with a timer), I can't really reliably count on it for a timed charge. But other than that, it is working very well.

Are you sure? yes | no

Nick Sayer wrote 01/15/2019 at 19:34

I believe the GFI sensitivity issue is because I removed a capacitor across the output of the GFI first stage amp. It turns out that that cap seems to perform an important integrating function. You can try to hack in a 10 µF cap from the cathode of the diode to ground and it will probably be better.

Are you sure? yes | no

martin.polak wrote 10/19/2016 at 11:46

Hi Nick, would you mind uploading a drawing of the wiring for the GFI detect and the relay test? and also which wires connect where on the HV board?

Another thing: is it ok, that the hex spacers are made of metal and thus connect display board ground to AC board ground to the metal plate in the housing (which should also be GND)

Are you sure? yes | no

Nick Sayer wrote 10/19/2016 at 15:28

The relay test is quite simple - just wire the load side of the contactors to the relay test inputs on the HV board. 22 gauge wire will do - it's not high current. There are 5 connection pairs on the HV board - AC in, contactors A and B and relay test A and B. The contactor connectors go to the contactor coil. The relay test wires go to the load side of the contactors. There's no polarity on either - just make sure relay test and contactor A both go to one contactor and B to the other.

The GFI system is a little weird. The two GFI coils are wired in parallel. For best results, they should be wired so that their directionality is the same. So if you have them oriented the same way, then connect the two "lefts" together and the two "rights" together. Select one side of the coils to be ground. Connect the test wire up to that ground point and then pass it through one of the coils twice, then through the other coil twice. That wire connects up to the "test" pin on the GFI connector. The coil wires that are connected to the other end of the test wire go to the "ground" pin on the GFI connector. The remaining pair of coil wires go to the "GFI" pin on the GFI connector. The idea is that the controller will pulse some 60 Hz 5VDC current through the test wire and expect to see a GFI interrupt as it does so. If that doesn't happen, it's a test failure.

Metal hex spacers should be fine.

Are you sure? yes | no

martin.polak wrote 08/19/2016 at 17:35

Hi, I'm really glad I found that project - exactly what I've been looking for ... but without having to hammer my own head for a great solution :-) couldn't resist to order one across the big pond!

I just wanted to understand a bit more on your design considerations:

- why did you pick HV controlled contactors instead of DC 12V coil ones? Shouldn't those be easier to drive from the ATmega?

- have you also considered an ACS712 (Hall sensor) based current measurement instead of transformer based one?

- do you have any plans about expansion on the controller end: like ESP8266 Wifi, RFID card reading

Are you sure? yes | no

Nick Sayer wrote 08/19/2016 at 18:22

I chose contactors because it was much easier to find high current UL registered contactors than relays. My OpenEVSE II project has HV boards that can operate relays instead of contactors, but that's necessary for a unit that can work at both L1 and L2. There's generally no purpose to build an L1 Hydra.

I've not considered expanding the feature set of the Hydra as at the moment the flash space is almost exhausted. I have a design on paper for a board with a bigger controller (ATMega644 perhaps), but haven't really had much incentive to go that route.

Are you sure? yes | no

Nick Sayer wrote 08/19/2016 at 18:24

I haven't tried using other than CTs for current sensing, as the CTs seem to be good enough. It's not really "revenue grade" sensing, really. Just a convenience so you can see what the cars are doing.

Are you sure? yes | no

J1772 Hydra

Become a Hackaday.io member

Just one more thing

Description

Details

Theory of operation

HV board

Files

Hydra_II_EVSE_5_0.pdf

Hydra_II_EVSE_5_0.sch

Hydra_II_EVSE_5_0.brd

AC_board_5_1_1.pdf

AC_board_5_1_1.sch

Components

Project Logs Collapse

Build Instructions Collapse

Enjoy this project?

Discussions

Become a Hackaday.io Member

Does this project spark your interest?

Report project as inappropriate

Send message

Remove Member

Project Logs

Collapse

Build Instructions

Collapse