J1772 Hydra

Charge two electric vehicles at once

Similar projects worth following
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.

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 4.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:

  1. Provide 12 VDC power for the logic/display board
  2. Perform a GCM (ground continuity monitor) test to insure the path to ground is functional.
  3. 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.
  4. Switch the contactor power on and off for each car.

The 12 VDC power is provided by an isolated power supply module. It can provide up to 250 mA at 12 volts, which is plenty.

Most of the remaining functions of the...

Read more »

Adobe Portable Document Format - 103.10 kB - 12/28/2018 at 17:57


sch - 603.93 kB - 12/28/2018 at 18:00


brd - 206.87 kB - 12/28/2018 at 18:00


Adobe Portable Document Format - 103.44 kB - 12/28/2018 at 17:59


sch - 665.18 kB - 12/28/2018 at 18:00


View all 9 files

  • 1 × Power distribution block Cooper Bussmann 16220-2
  • 1 × 3 x 8 AWG SOOW cable - 4 feet 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

View all 18 components

  • Protect the programmer

    Nick Sayer4 days ago 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.


    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 Sayer6 days ago 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 Sayer6 days ago 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 Sayer01/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.

  • More progress

    Nick Sayer01/07/2019 at 05:11 0 comments

    While the pilot generator was close to spec with the last changes (in terms of rise and fall time for the pilot), some component changes dialed it right in. The opening resistors are now 1 kΩ and the closing resistors are now 4.7 kΩ. With that, the rise and fall times of the pilot are now around 2 µs, which the spec demands.

    I also discovered that running high current lines adjacent to the RTC and its crystal are bad for timekeeping. I've solved this in the next revision of the boards by moving the RTC to the top end of the board. I'm also going to tweak the layout of the car B pilot generator, as some of the components are too close together for easy rework.

    But the most recently fabbed boards (which will arrive tomorrow) are still fine - the component changes don't affect the layout, and you just need to keep the power conductors away from the RTC (running them above the board rather than below is fine, as the ground planes provide enough isolation).

  • Not quite there

    Nick Sayer12/24/2018 at 16:58 0 comments

    There are two issues I’ve observed with v4.4 that I’m going to have to fix with another update. One is that the charge pump has some difficulty keeping up with the choppy current demands of the pilot generator. The issue is the 10 kHz clock rate of the chip. Fortunately by just strapping pin one to Vin the clock rate can be increased to 45 kHz. Early experiments seem to show that this is good enough. The bottom edge of the pilot signal seems to take a little extra time to go all the way down, but in principle the car never sees the negative portion anyway, so unless it winds up being a problem I’m going to declare it good enough. I’ll try adding more reservoir capacitance to the prototype to see if it helps and if it does, that’s just a component upgrade.

    The other issue is that our Chevy vehicles seem to cause false GFI trips when power is first applied. I’ve spent some time simulating the circuit and now believe that the 10 µF cap I removed from the circuit some time ago may have served as an integral function. I’m going to try hacking it back into the circuit to see if the falsing goes away.

    If both of those issues are taken care of, then v4.4.1 will be the one for the foreseeable future.

    On the AC board side, v4.3.3 is likely to be good enough (with parts substitutions to decrease the GCM sensitivity), but I am going to try an experimental version substituting an LM393 comparator for the LM358 op amp. On that board, a comparator is actually what the circuit wants, and by leveraging the open drain output, we can reduce the parts count slightly, at the cost of inverting the sense of the signal (so a corresponding #define in the firmware will be needed).

    UPDATE: The GFI fix seems to have worked, but longer term testing will be required to absolutely confirm it. The added capacitance on the charge pump, however, didn't do any good. Really, though, the only alternative would be going back to the MC34063 based inverter, which I might do, but I still think this is good enough for now.

    UPDATE 2: It's a Christmas miracle! By changing the MOSFET turn-on resistors I've reduced the switching current enough to make the charge pump happy. The rise and fall times increased just a bit, but I believe it's still close enough to the spec requirements to score.

  • Coming back

    Nick Sayer12/16/2018 at 17:16 0 comments

    When we last left off, I had promised some updates, but never really delivered them. The problem that had put me off the project was the problem of the ground continuity monitor sensitivity, but in conversations with others in the OpenEVSE project, it seems that I was making the problem harder than it had to be. The 100 ohms per volt value from the spec that I had used as a target isn't the sensitivity of the GCM, it's the minimum impedance between either power conductor and ground (which is a spec we easily meet since the only path to ground from either conductor starts with a 150k flame proof resistor). So I could probably even slightly reduce the sensitivity of the GCM to make up for the temperature sensitivity that otherwise is shown by the optoisolators.

    I have the EVSE logic/display board sitting on my bench to build and have the AC board in at OSHPark. The schematics and board files have been updated to match these versions. I'll update the log when that's done.

  • State of the Hydra update

    Nick Sayer11/12/2017 at 20:03 0 comments

    I've been almost totally dedicated of late to other projects but I'm going to try to come back to the Hydra now.

    One thing I discovered not too long ago was that the triac was previously wired wrong. It turns out that triacs are not actually unpolarized devices, at least from the point of view of the gate. The gate needs to be taken towards the opposite main terminal to switch it on, and when the triac is on, the voltage across the main terminals will be near zero (because the triac is conducting), which dramatically reduces the current through the other components involved in triggering. Oops.

    So the AC board's contactor drivers work a lot better now. I'm going to keep using the half-watt components just to be sure.

    One of the fellows who bought a Hydra board set (I won't name him just because I haven't asked his permission first) has contributed to the firmware development in a big way, and a lot of his changes are going to make it back in. This will include some self-tuning for the RTC chip's trimming register (if you set the clock when it's wrong it will get better). He requested an i2c header for the board to add the ability to add off-board sensors, such as temperature sensors and the like. We'll see how much more we can cram into the firmware now that some of the space has been reclaimed by cleaning up and de-duplicating.

    What remains is the continuing difficulty with the relay test. To recall, we want to strategically set up a small leak from the relay test pins to ground and measure the current flow. When the relay is open, there should be no current flow, and when the relay is closed, there should be some. But for safety reasons, it's undesirable to leak more than 1 mA of current, but our detection threshold needs to be 24 kΩ. I think the solution is going to wind up involving an isolated power supply. A small 12VDC -> 5 VDC isolated module would work. The idea would be to set up a voltage comparator across a resistor in the leakage path, and then run the output through an optoisolator with the optoisolated output going back to the controller.

    I haven't sat down to figure that one out yet. I think the challenge is going to be to make it work without dramatically increasing the size or price. We'll see.

  • PT7C4311WEX accuracy redux

    Nick Sayer02/21/2016 at 06:48 0 comments

    I finally had a chance to perform the calibration testing for the clock.

    Stumbling block number one... the FT/OUT pin of the chip is an open drain, meaning you have to pull it up to actually get to see the square wave. Grumble. I was able to hack this up, but it was painful, so the next version of the board will actually add the pull-up resistor and have a calibration test pin for convenience.

    Stumbling block number two... The default value for the calibration register, it turns out, is +31, which ostensibly makes the thing run 124 ppm fast. So no wonder the Hydra clock has been all over the place before now.

    The good news is that the crystal I'm using, with the 8 pF loading caps, results in two board sets so far that have been inside of 10 ppm. Both are slightly slow - one 5 ppm, the other 1 ppm.

    I've had to customize the DS1307 RTC library that plugs into the Time library for Arduino. I haven't done it yet, but I'm going to need to fork the library for the Hydra so that others can build the same firmware. I've also made a bug fix for the time-setting code. The original code attempts to or the seconds with 0x80, but then the write() method converts the value to BCD, which means 0x80 isn't going to stay 0x80. The new method simply writes 0x80 into the seconds register in the first pass, then writes the seconds by themselves in a second pass.

    Anyway, if you've got a EVSE variant Hydra, your real-time clock is probably whacky. You probably want to update your firmware.

    UPDATE: My pull request to the DS1307RTC library was accepted, so you don't have to take my private fork any more! Yay!

  • A slight parts adjustment

    Nick Sayer02/15/2016 at 23:48 0 comments

    Our home Hydra EVSE failed this afternoon for the first time in as long as I can remember (don't let that fool you. It has failed before, it's just been a while, and not with the current revision). The plug for my eGolf started throwing error F, which indicates a ground failure. To recap, the current hardware has a GCM circuit tied to the load side contactor terminals. When the contactor is off, there should be no current, or it's a stuck relay. When the contactor is on, there should be current flow, or else it's a ground impedance failure. The latter was what was being indicated. Watching more closely, it was easy to tell that what was really going on was that when the contactor was being turned on by the logic board, there was no characteristic "kerthunk" indicating that it actually did it.

    I sort of should have seen it coming. The eGolf exercise the EVSE's contactor far more than is necessary. In fact, the eGolf's charging system is the flakiest and most finicky I've encountered so far (and I've encountered quite a bunch more than I've actually owned). Most notably, in the morning when it's time to leave for work, you have to click the key fob to unlock the plug-lock. When you do so, the car turns on the power. There's absolutely no reason for it to do so, since the batteries are all charged, and the climate control warm-up has already concluded. But that's what it does. Then it unlocks the plug lock and when you remove the plug, it turns the power off.

    That's a lot more contactor play than average. What failed was R6 - the 150 ohm resistor connected to the driver triac. It blew open. When I got it out of the circuit there was nothing obviously wrong with it on the outside. But it measured completely open. Replacing it brought the Hydra back.

    This suggests that that component needs to be made beefier. I'd been using ordinary 1/8W chip resistors from a reel, but it looks like the thing to do is use a 1/2 watt part. Fortunately, DigiKey has 'em. While I'm at it, I'm going to use 1/2 watt for the 2.4K resistor in the HV triac circuit too. That means 1/2 watt parts all 'round (the 39 ohm resistor in the outer snubber already has been upgraded).

View all 15 project logs

  • 1
    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.

  • 2
    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.

  • 3
    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.

View all 8 instructions

Enjoy this project?



Lance wrote 07/01/2018 at 19:36 point

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 point

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 point

Hi 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 point

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 7 days ago point

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 7 days ago point

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 point

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 point

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 point

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 point

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 point

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

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates