A new hobby evse

Earlier this year I purchased a Toyota Plug-in-Prius. The car comes with a slow charger module that is powered through a standard 120v 15amp outlet. This kind of outlet can deliver something around 1kw of energy. For the 4.4kw battery pack in the PiP, it takes about 3 hours to charge the pack from its empty state. Empty for the PiP isn't actually a zero charge level, the battery is kept within a 15% to 85% State-of-charge(SOC) to prolong its life.

Frequently I was finding that I didn't have enough time to charge the pack before leaving on another trip. One option was the $1500 or so to purchase a 240v charger and have someone install it. A quick search on the web turned up the OpenEVSE project, a project to build a evse charger.

I started to read about the evse project and got interested in building one. I did want to have some kind of network support so I could control and monitor charging, schedule it better than the car could and otherwise expand upon what the project was already doing. The project currently uses an ATmega328 MCU, a low cost embedded processor. At the time, earlier this year, there wasn't even enough memory in the chip to fit the code to calculate energy consumption. There was some discussion about adding a serial command set to interact with the evse from a remote system. I even joined in on the discussion group and started working on a binary command set. The project maintainers thought there might not be enough memory to fit the binary commands without disabling the serial console support.

Adding a binary command set sounds like a good idea. It would enable the current stable code and system to be preserved. The next question was the link layer. The ATmega has serial, i2c, and spi interfaces but these don't have built in error checking. You would end up needing to accept some level of potential for errors or add error checking via a software link layer on one of the physical interfaces. Assuming we have a link layer that handles errors, the next issue is what kind of system you might want to interface with the atmega. I, and others expressed interest in adding a raspberry pi or other low cost computing platform. The difficulty is that while these platforms can usually accept serial, i2c, or spi, you would need to hand connect the systems using jumper wires. To me this seems error prone, why not use a standard and easily available connection like USB. USB, in addition to being a standard and having readily available cables, also performs error checking and re-transmission.

Thinking about the capacity issues with the current ATmega328, having to create yet another software link layer, and then guide people through connecting to the system got me thinking about the bigger picture of the design. It seemed like the OpenEVSE project was having similar issues to a project I'm working on in my full time job. At work the current implementation of some systems is limiting the ability to add features due to lack of capacity. Architectural decisions related to the platform are making this difficult to fix without a large redesign.

My first thoughts were to upgrade the ATmega to one with more flash memory but the version used in the current OpenEVSE is a ATMEGA328P-PU and there wasn't a larger version with the same pinout. I have experience with the stm32 series processors. These are more expensive than the atmega but they are significantly faster, offer much more memory and offer additional interfaces such as USB and Ethernet. Specifically I was interested in the STM32F103 series, for the role of the main evse processor. I tried to get some traction with the OpenEVSE guys to switch to another processor, such as the stm32, and to do so in order to add support for USB or Ethernet. The response wasn't enthusiastic, maybe because the existing system works and has been debugged, and some people thought it was silly to use USB when many chips and systems have one of the interfaces found on the ATmega, serial, spi or i2c. I agree that most systems do have serial interfaces and a great deal of modules are currently interfacing with either serial, spi or i2c.

I do also believe that for the average person and for most systems people want to interface with, that USB is a better choice. It also allows the application side to be developed on a PC with extra hardware like a serial to USB converter or relatively more difficult to find spi or i2c interface devices. In addition, an stm32 solution could provide these interfaces in addition to USB and or Ethernet.

I started on a design of a new evse, based on the current OpenEVSE design but with a stm32f103. The stm32 would provide much more memory, making it easier to develop new features such as the binary protocol. You can read about some of the things that I encountered during this work on other stories here on my blog.

After a few months I had an initial board schematic with the stm32 part and had been bringing up the software for a few weeks. The process was not simple. Even when using an Olimex STM32-H103 board, just bringing up freertos had taken a few weeks. I realized that I simply wasn't making any progress. And then I found out about the BeagleBone Black.

The BeagleBone Black, or BBB, is a $45usd mini computer board. It has a two 46 pin headers, a 1 GHz arm processor, 2gb of on-board flash memory, 512MB of ram, USB, HDMI and a microSD card. It can run Angstrom and Ubuntu Linux, among others. The idea behind using the BBB is to add some amount to the overall system cost, in exchange for a system that is working and capable of being used for much higher level functionality such as web services, remote access etc.

The concept for the new evse design was stackable modules, a power board module, a logic board module and a computing module. The current system consists of three parts. Because of the stackable modules there is also a possibility that the BBB could be replaced by another implementation, the new implementation simply has to interface with the signals on the headers on the logic board level.

Power board

This board contains all of the high voltage components in the system including the connectors, relays, and voltage monitoring. The board also integrates the current transformers and a voltage transformer necessary for energy monitoring. The energy monitoring portions of the design are based on information on the openenergymonitor.org website. This board also contains a 60-260VAC to DC power supply that provides 12v for the rest of the system.

Kicad's pcbnew layout tool

Version 1 of the board showed up today, 2013-08-02.

While it clearly isn't ready for prime time, already I found that some through-holes are misplaced and I suspect some parts are too close together and will intersect with the logic board, it is real hardware and should be useful to help with v2. I'll be starting on building it up and debugging it in the near future.

Logic board

This board contains two sets of 2x46pin headers, one set to connect to the power board and another to connect to the BBB. In terms of components, the board contains the 12v to 5v DC to DC regulator to provide the 5v required by the BBB. The BBB back supplies 3.3v through its headers. The logic board also contains the GFCI circuit as well as signal conditioning circuitry that ensures the proper voltage levels will be passed to the BBB. This board is currently in development. I'm waiting to build this board until after I'm able to bring up the powerboard.

BBB

The top level of the stack is the BBB. The BBB performs system control and monitoring functions. Because the BBB is basically a full featured computer, it should be relatively easy to expose http/https rest interfaces to the evse and a web server to prove a web based interface to the evse. The BBB also has a usb host port, making it easy to plug in a Bluetooth or wifi usb adapter to provide network connectivity with an off the shelf module.