Monday, March 2, 2015

OpenEVSE II and Hydra status reports

The first batch of final boards for OpenEVSE II and the Hydra will arrive today. The designs for both were successfully prototyped already, so I have no doubt about the viability of these boards.

OpenEVSE II will be available in two formats, which differ only in the HV boards. One is intended for use with a line powered contactor, and the other with either a single DPST or two SPST 12 VDC coil relays. The contactor variant will only be usable at a single voltage, since contactors aren't typically agile from 120 to 240 VAC. But contactors are typically capable of switching much higher current. By contrast, the relay variant will work at any supply voltage from 100-240 VAC, but relays are typically only available up to around 30A.

Both HV boards are intended to fit in the OpenEVSE chassis available in the OpenEVSE store. You just need to drill new mounting holes, as the boards are slightly different sizes than the original OpenEVSE board.

Both variants include the full compliment of UL required safety checks. Of particular note is that the GMI test is now continuous while charging is in progress, and the ground current is limited to a maximum of 1 mA, which means it should not trip a normal household GFI.

The logic board now includes a standard OpenEVSE i2c header for further future expansion. It also has a RTC and a temperature monitor chip to measure the ambient temperature inside the chassis.

For the Hydra, there is a single HV board that supports only contactors (the case for an L1 capable Hydra is not compelling). It also now performs ground impedance monitoring and relay tests as well as a GFI self test whenever charging begins. It is available both as a standalone EVSE with a RTC, and as a splitter to facilitate sharing an existing EVSE.

All of the above are available for purchase right now at .

Wednesday, January 21, 2015

Final designs for OpenEVSE II & Hydra 4.0 are on their way

I've placed the order for what I hope will be the final versions of the OpenEVSE II and Hydra boards. I'm taking a bit of a chance in ordering them both at once, since I had planned to use one to validate the design of the other. But I've done enough testing with the OpenEVSE II prototype (0.3) boards that I'm fairly confident at this point.

New for the Hydra 4.0 design is ground impedance monitoring and relay testing. This brings the Hydra if not into full UL compliance, then at least asymptotically close. Originally, I had intended to leave the GMI system out of the "splitter" variant, but in adding a 1 mA current limit to the ground monitor circuit, I'm fairly confident that the test can be present and still not trip the GFI in the host EVSE - even if it's the ultra sensitive 5 mA type. If it turns out to be problematic, it can always be a "no-stuff" option on the AC board. Unlike OpenEVSE II, there won't be a voltmeter in the Hydra. There simply aren't any remaining analog pins on the controller. Even if that weren't true, there isn't enough room on the AC board for more HV components with sufficient creepage space around them.

OpenEVSE II is a reimagining of OpenEVSE. It changes completely the ADVPWR functionality. Automatic L1/L2 selection is done with an isolated analog voltmeter. The ground monitoring and relay testing systems can be done continuously rather than in isolation, as in the OpenEVSE base design.

Recent work has been done to add temperature monitoring to OpenEVSE. There isn't enough room on the logic/display board for an added sensor, but I did hedge my bets by adding an i2c header to the logic/display board. That can be used to add a remote i2c temperature sensor that can be placed in an interesting spot. But the ATMega controller chip has a built-in thermometer. It isn't tremendously accurate, and it can be affected by the controller's own activity. This has been particularly noted in testing with OpenEVSE, but in that case, the controller is mounted on the opposite side of the board from the main AC/DC power supply, which likely is responsible for quite a bit of conductive heating. OpenEVSE II's controller is well isolated from other nearby heat sources, so it should do much better. In any event, the temperature sensor is supposed to be a safety limiter rather than a critical measure of temperature (such as for a thermostat or the like), so its absolute accuracy is relatively unimportant. The real purpose is to attempt to shut down charging before the ambient temperature causes the controller to fail.

Saturday, January 10, 2015

OpenEVSE II logic/display board theory of operation

The OpenEVSE II design for the logic/display board is fairly well set by this point. All of the iteration lately has been on the feature set of the various types of HV/power boards. I thought I'd set down exactly how the various parts of the logic/display system operate.

I'll do this by showing one sheet at a time of the schematic and explaining all of what's there.

The first sheet is the power supply and GFI subsystems. The HV board has an isolated AC/DC power supply that feeds 12 volts to the logic/display system. EVSEs need +/- 12 volts and +5 volts to operate, so -12 volts and +5 are made with two DC/DC converters built from the venerable MC34063 DC/DC converter module. This chip can be used in buck, boost or inverting topologies, and we use the inverting topology to make a -12 volt supply rated for 50 mA max and the buck topology for a +5V @ 500 mA supply.

The GFI system is largely copied from a CR Magnetics application note. A capacitor is added to the amplifier stage to act as a low-pass filter, which adds some noise immunity. Rather than a second amplifier stage, the output from the first is simply fed into a comparator with a peak detector. That line is fed into an interrupt input pin of the ATMega chip that watches for a rising level. An interrupt service routine will quickly turn all of the relay output pins off.

There is a GFI test system, which simply consists of a current limiting resistor. A wire will go from that output and take 3 or 4 wraps around the GFI coil and then connect to ground. The code will pulse this line at approximately 60 Hz to simulate a ground fault. The expectation is that during this test the GFI will detect the pulses. The software will note a GFI failure if it doesn't.

The second sheet consists of the ammeter and the pilot generation and read-back circuitry. The pilot generator converts TTL output from the controller into +/- 12 volts. It does this using two pairs of transistors that make up a modified H bridge architecture. Two transistors are used to switch +12 or -12 volts onto the pilot output, and those two transistors are themselves switched on and off by transistors that are intended to translate the TTL levels into current flow to trigger the other two. Since the circuit is acting as an H bridge, it is critical to insure that the input is either TTL high or low and never a voltage that's in between. That could result in both output transistors being switched on, which would short +12 to -12 volts. R4 acts as a pull-up resistor to protect the pilot generator whenever the pilot output pin is in a high impedance state (which happens when the controller is being programmed or during and shortly after power-up reset).

The 1k resistor on the pilot output is required by spec to set the output impedance. The three resistors after that form a feedback network that scales the +/- 12 volt pilot to 0-5 volts to feed into one of the controller's A/D pins. The firmware will use this feedback to detect a missing pilot diode and the J1772 state requested by the attached car.

The ammeter is quite simple. It's a current transformer with a burden resistor and one leg offset to 2.5 volts. This is intended to keep the entire AC signal within the controller's input A/D range of 0-5 volts. Two zener diodes form a clamp to protect the controller from excursions beyond the acceptable range. The burden resistor must be carefully chosen. Too small and the ammeter's resolution will be poor. Too large and its range won't be high enough. The capacitor to ground on the anchored leg reduces noise in the readings.

The controller/display sheet includes the controller itself, which is clocked with a 16 MHz external crystal, the real-time clock chip and its backup battery, and the display. The display is the same design as the AdaFruit i2c RGB backlit LCD Arduino shield. JP3 is a bit tricky. It's not actually a separate connector, it's just the extra two pins for the RGB backlit LCD (the standard EAGLE part library only has a standard backlit LCD, which has only 16 pins).An i2c GPIO chip is used so that the I/O pins on the controller can be dedicated to EVSE functions rather than the display. The real-time clock chip also shares the i2c bus and has a CR1220 battery to keep the clock running during power outages or storage. The SPI bus pins of the controller are unused, and so can simply be connected directly to the AVR ISP connector for reprogramming. There are two solder jumpers present, One allows selection of the polarity of the backlight common pin for the LCD module. By default it's wired for common anode backlight LEDs, but changing the jumper (and the software) can allow use of a common cathode LED backlight instead. The other solder jumper connects the serial port's DTR pin through a capacitor to RESET. Closing that jumper will mean that transitions on the DTR pin will reset the controller. This is required if you want to upload new code over serial using an Arduino style bootloader, but is not recommended in any other context.

The FFC connector to the HV board has two otherwise unused pins (RELAY_B and AUX) that can be used for additional expansion functions in the future.

Saturday, January 3, 2015

OpenEVSE II design progress

The good news is that the design of the logic/display board has not really changed significantly since July. I have moved a couple of components around very slightly, but in general the separation of functions has really been quite a boon for the design.

When I last checked in, I had decided that the relay test functionality wasn't worth the trouble, so I converted it into a ground impedance test - which I knew was required by UL. I also replaced the original OpenEVSE L1/L2 test system (which also performed the ground test and the stuck relay test) with what I hope to be a reasonable isolated voltmeter.

Chris H corrected me, however. I thought a stuck relay test was unnecessary, but he said that UL actually requires one. So it's back in play.

What I've come up with is that the ground test circuitry is going to be replicated for a relay test line. The difference is that, while the ground test circuit has two diodes from each hot line and runs to ground, the relay test will simply run between the two hot lines on the load side, much like the voltmeter does on the line side of the relays/contactor.

OpenEVSE II relay board. This board works on both 120v and 208/240v, but is only rated for up to 24A charging.

OpenEVSE II contactor board. This board uses an external AC line powered contactor. The only limit on charge current is the contactor, but contactors generally only work at either L1 or L2 (not both).

Both variants have an isolated AC/DC power supply to produce 12 volts for the entire system. The relay variant has a 10 watt module and the contactor version has a 3 watt module. The difference is that the two relays draw 2 watts from the 12 VDC supply when energized, while the contactor is the equivalent of just an LED on the low voltage side.

Both the ground test and relay test hardware is nothing more than a comparator that feeds into a very basic peak-hold circuit so that the AC zero-crossing intervals don't count as "failures." The ground test is designed to insure that current will flow from at least one hot line to ground (for hot-neutral systems one of the hot lines will actually be a neutral line, so current flow will not be expected in that case). The test is a little trickier than it sounds. You can't naively put a pair of optoisolators in place - one for each hot line - from the hot line to ground, since a circuit path would exist from one hot line through its optoisolator to ground, and from there through the second optoisolator to the opposite hot line. That test would "pass" regardless of whether the ground impedance is high or low. You can, however, use a pair of (beefy) diodes so that, effectively, only one hot line at a time is presented with an opportunity to conduct through the optoisolator to ground.

The optoisolators are LTV-844S, which have AC emitters - each of the 4 independent optoisolators has a pair of diodes in inverted parallel (this is not shown in the schematic, which shows the unidirectional LTV-846S instead). Effectively, this means that the transistors see light proportional to the absolute value of the input voltage. The series resistors chosen are intended to try and keep the optoisolators in their linear range (if possible), and are also sized based on the power equation: P=E^2/R. Note that for the ground-fault system, the math is deceptive. The actual voltage is never more than 120 volts because the measurements are always relative to ground. In addition, each resistor only gets a 50% duty cycle, as the negative half of the cycle is blocked by the diode. For the 91k resistors, the worst case is 240 volts, which comes out to just under 2/3 watt. Lastly, all four resistors are flame-proof, so that they act like fuses and burn themselves out harmlessly if stressed.

The output side of each optoisolator is set up, more or less, with a classic voltage divider configuration. For the ground test and relay test systems, the result is simply compared to 1 volt by a comparator and peak-hold circuit. For the voltmeter, the result is fed into a non-inverting amplifier. As supplied, the amplifier is configured as a voltage-following buffer (unity gain), but gain can be added by altering the components without re-spinning the board.

The relay board has a simple common emitter switch with a flyback diode to switch the relay coils on and off. The contactor board has an optoisolated triac that's used to drive a (slightly) larger triac to switch the contactor on and off. Both the main triac and the driver triac are provisioned with snubber circuits which serve the same purpose as the flyback diode on the relay board: they provide a path for the coil collapse voltage to go when the contactor is switched off.

Monday, December 29, 2014

OpenEVSE II - progress at last

After letting the prototype boards sit on my bench for almost six months, I finally got around to building them.

I've got to redo the voltmeter portion of the HV boards, so there will be a 0.3 board, but I think the 0.2 logic/display board is a keeper.

Here are some docs to peruse:

The relay board variant is designed to be used at both L1 and L2, but the relays are limited to 24A continuous (30A circuit breakers / fuses). The contactor board variant can be used with any line-powered contactor and the design imposes no current limit constraints beyond that of the contactor, AC and J1772 cables. But the contactor coil will likely only be usable for 208/240 volt power (you could get an 120V coil contactor, but for L1 you might as well use the relay variant).

Saturday, December 20, 2014

Contactor Adapter users guide

This post is the permanent home for the instructions for the Contactor Adapter.

Version history:

  • 1.4: Increased creepage distances for improved safety and isolation.

Contactors are very similar to relays. Classically, the term is used to describe relays that switch higher powered loads on and off, and typically have AC line voltage powered coils, while relays tend to be smaller and have low voltage DC coils.

The initial project that drove the design of the contactor adapter was OpenEVSE. The OpenEVSE and Hydra boards had switched 12 volt outputs designed to open and close relays to turn the power to the car on and off. 30A DSPT relays were not hard to come by, but they came with QD terminals. QD crimp terminals for 10 gauge wires can be had, but in heavy usage they were not reliable.

Switching to contactors resulted in a much more reliable design for the high-current paths, but led to the need for the contactor adapter.

To make use of the adapter, first pick a contactor with a coil whose voltage matches the voltage of the load that you're going to switch. The contactor adapter is rated for 240 VAC RMS maximum (it can be used at 120 VAC as well). Insure that your contactor coil draws no more than 100 mA (most won't) not counting initial surge currents.

The contactor adapter's high voltage terminals are a switch. Wire the contactor so that one coil terminal is fed directly from one of the line inputs. Wire the other contactor coil terminal to one of the contactor adapter's high voltage terminals. Wire the other contactor adapter terminal to the other line current source. If you're using hot-neutral wiring, then you should place the contactor adapter in the hot line rather than the neutral line. If you're using hot-hot wiring, then it does not matter which hot line you use.

The input side of the contactor adapter is effectively an LED. The contactor adapter is supplied with a 330 ohm series resistor, which means that the ideal switching voltage is 12 volts. The contactor adapter will draw approximately 30 mA. If you wish, you can replace the series resistor with a 150 ohm one, in which case the contactor adapter can be driven directly with a (5 volt) output pin from a microcontroller (assuming that that one pin can drive 30 mA).

Unlike relay coils, the contactor adapter is polarized. You must connect the positive terminal to the voltage source and the other terminal to ground. For OpenEVSE boards, the common center pin of the relay terminal is positive, the individual relay pins are ground.

Note that most of the board has line voltage present when it's connected - and this includes the bottom of the board. Mount the board securely with appropriate mounting hardware, including standoffs to keep the bottom of the board a minimum of 1/4" away from anything else.


Wednesday, December 10, 2014

On hardware versioning

I don't know if this is a particularly interesting topic for a blog post, but I sort of had a realization last night about how best to manage hardware version numbering.

What it comes down to is the nature of the change that requires crossing a particular boundary. I've identified three boundaries:

  1. A major design change - wholesale changing of chips, new hardware features, etc.
  2. A change that impact the "cream" layer - requiring a new solder paste stencil and/or PnP programming.
  3. A change in signal routing or silkscreen - requiring new PCBs.
  4. Any other change - typically just parts substitution, stuff/no-stuff or solder jumpers.
Going forward, this is how I'm going to version hardware. I'm going to use the old software standard of n.m.o formatted version numbers, but other folks prefer Axy style, and that's fine too. But I've discovered that there is value to characterizing which changes require a new stencil, and this scheme means I don't have to try and remember that 0.3 could still use the 0.2 stencil.