v5 and other discussion

[Chris Morgan]

Hello.

I've been discussing with Chris some hardware and software developments and wanted to bring more people into the mix, I realized I was leaving Lincoln out. I'm new to openevse so if I'm off the mark I'd like to apologize in advance for my ignorance.

Some of the background:

- I'd like to have a web enabled wifi OpenEVSE. I'd like to help get there.

- It makes sense to keep the core evse controller simple so it can work without a display or web interface etc.

It seems natural to use an external system to provide web/wifi and other features beyond the base evse functionality. For inter connectivity to the external system a few schemes have been proposed:

- i2c interface

- binary serial interface

I've started a google doc to specifiy this here: OpenEVSE binary serial protocol If you'd like edit permission email me but I've enabled comments by default.

- ascii text interface

 A modified version of the current cli.

During the discussion about adding i2c and binary interfaces it came up that the current chip, an atmega328pu (32k flash) is nearly out of capacity. That spawned another thread of discussion about how to resolve the issue.

- Removal of console interface

- Upgrade to a larger atmega part, 644 and 128 models look similar enough (and are still through-hole parts), although it is possible with reflow equipment to solder qfn and fine pitch parts in the higher density packages it is a bit of a pain for home assembly.

- Switch to an alternative architecture. Chris mentioned the STM32F1 series, specifically the STM32F103. I'm quite familiar with these and they can have a ton of IO, the one I use has 5 serial ports and a boatload of gpio, I think STM32F105 is the particular part. The cpu is a Cortex-M3, 32bit armv7-m architecture. Its a very fast cpu, ~$7USD. Other cpus have been considered, I looked at the OMAP4 (it is expensive), but maybe someone else has another idea.

I'd like to include my 2 cents, based on working with interfacing between boards and machines and building embedded platforms.

- We should keep the existing ascii human readable console (and improve it if necessary). It is invaluable to be able to get help, type some commands and interact with the system using a terminal. I use one of these daily on an embedded system. I've used it dozens of times to help people with issues or help them get things in working order. We could also consider borrowing the console from u-boot or some other embedded project if it makes sense and the licenses are compatible.

- If we have the IO pins I think we should support the console and binary interfaces in parallel, one on each port. That avoids having to switch functionality on a given port back and forth.

- We should strongly consider putting the binary serial interface, and in fact the console interface as well, on usb as a USB device, maybe via an FTDI chip. Not only for prototyping (you could hook your pc to the evse without special cables or the like), but tons of boards like the Pi, BeagleBoard etc have usb support. Not a lot of boards have i2c. From reading the i2c specification I'm not convinced that it makes sense to have a series of devices on a bus given the signal requirements. Usb hubs are pretty cheap.

- I've programmed applications against an ascii text interface. It wasn't as simple as a binary framed protocol but it is doable. Its a bit more difficult to specify and it gets a little tricky when you start to revision commands because you forgot a parameter with the original one.

- It would be nice if the controller board had support for a lcd display and some buttons, perhaps just to cycle through a few display screens. Doing this without a separate board might bring costs down of building a base unit + display. For more advanced displays someone could use the binary interface and an external board and go nuts with a touch screen etc.

Chris

[Chris Morgan]

A minor note, Chris suggested we use the CPUs USB device. Not sure if the mega has one but the stm32 does. Freertos has code for a virtual serial port over USB. I'm not positive but I believe we could put multiple end points, if that is the correct term, and have one virtual serial for console and one for machine to machine.

[lincomatic]

the AT90USB1286 has USB, as well as some of the cheaper alternatives, like
the 16U2 used I the Arduino Leonardo.
There is also V-USB, a free library
http://www.obdev.at/products/vusb/index.html.
But USB virtual serial ports are for MCU->host comms.

For MCU->MCU comms, the UART is all we need.
There is also a SoftSerial library that can emulate a UART if we need more
than one,
but in my limited experience when playing with it, I was getting a lot of
lost packets.
The Mega has 4 UARTs but no USB.

I think they're probably overpriced, but the AT90USBxxxx chips have 1
hardware USB + 1 UART, which sounds like
they fit the bill to get rid of the FTDI, while saving all the CPU bandwidth
for the EVSE functions.

Hmm. I was just looking at Teensy 2.0 http://www.pjrc.com/teensy/index.html
If we can keep the code footprint small, the 32U4 has USB + 1 UART, and the
same RAM/Flash as the 328P.

I haven't played with the STM32 yet.. do you have experience with it?

--
You received this message because you are subscribed to the Google Groups
"OpenEVSE" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to openevse+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[lincomatic]

I just took a look at the specs for the STM32F103.  Very impressive.. 10x the RAM, 128K flash, 72MHz, for $7?

Debugging support is a huge gain, too.

It sounds pretty good.

 

From: open...@googlegroups.com [mailto:open...@googlegroups.com] On Behalf Of Chris Morgan
Sent: Friday, March 8, 2013 5:56 AM
To: open...@googlegroups.com
Subject: v5 and other discussion

 

 

- Switch to an alternative architecture. Chris mentioned the STM32F1 series, specifically the STM32F103. I'm quite familiar with these and they can have a ton of IO, the one I use has 5 serial ports and a boatload of gpio, I think STM32F105 is the particular part. The cpu is a Cortex-M3, 32bit armv7-m architecture. Its a very fast cpu, ~$7USD. Other cpus have been considered, I looked at the OMAP4 (it is expensive), but maybe someone else has another idea.

 

 

[Chris Morgan]

Hi.

I actually work with stm32 professors on a daily basis. It's very quick, 32 bit and they have variants with tons of io. Like most lower end processors though it lacks a mmu so it's a pain to debug.

Chris

[Chris Morgan]

On Saturday, March 9, 2013 6:10:56 PM UTC-5, lincomatic wrote:

the AT90USB1286 has USB, as well as some of the cheaper alternatives, like
the 16U2 used I the Arduino Leonardo.
There is also V-USB, a free library
http://www.obdev.at/products/vusb/index.html.
But USB virtual serial ports are for MCU->host comms.

I would imagine that in the cases we are referring to the raspberry pi would be the usb host and the openevse board would be the device. Virtual uarts bring a ton of nice features. The one that is most interesting to me is that you could do all of your prototyping on a regular pc, upload software to a Pi and then finish integration there. Usb also has defined cables, smaller connectors than db9 and as I've mentioned we could expose multiple virtual serial ports so we could preserve the console.

 

For MCU->MCU comms, the UART is all we need.
There is also a SoftSerial library that can emulate a UART if we need more
than one,
but in my limited experience when playing with it, I was getting a lot of
lost packets.
The Mega has 4 UARTs but no USB.

It might make sense to expose the binary interface on a uart as well. Some people may want to hook up really small systems that lack usb host functionality. Its more of an io/connector issue with the larger chips though. The state information necessary to maintain multiple interfaces would probably be quite small.

 Chris

[Chris Howell]

There is no need for a FTDI USB or a db9 cable. The pi has GPIO. The general purpose io is TTL so all that's needed is connecting wires. It would be a waste to convert TTL to rs232 transceiver to cable to rs232 transceiver to TTL or in the case of FTDI TTL to FTDI - cable to USB to emulated serial.

So in the case of Rpi to OpenEVSE the best connection choice would be OpenEVSE i2c to Rpi i2c or TTL URT to TTL URT. Note a voltage divider may be needed to go from 5v to 3.3v on the pi rx pin if it is not 5v tolerant.

--

[Chris Morgan]

For the avrmega board I agree that there isn't any use for an ftdi, it is a lot of stuff to add just to go between uarts on the two boards.

I was actually referring to the usb port on a stm32 variant of the board. Those have built-in phys for usb. We could also bring a serial port out to a header in case people wanted to do direct serial to serial interfacing. I think a lot of people would be interested in using the usb connection given its simplicity, no line level adjustment etc. The connector is also pretty inexpensive.

Chris

[Ben Franske]

On 3/10/2013 10:35 AM, Chris Morgan wrote:
> We could also bring a serial port out to a header in case people
> wanted to do direct serial to serial interfacing.

I like this. Personally I think that serial is much more flexible than
USB as converters between serial and just about anything else, Ethernet
for example, are readily available at low cost. I don't care about
having the line driver, just make it available as TTL. This allows
connectivity via USB, Ethernet, RS232/485/422, or direct TTL.

-Ben

[lincomatic]

Sorry, I don’t quite understand.. you want to connect the OpenEVSE board as a USB device to a Raspberry Pi as a USB host? I don’t see the advantage of that over just doing serial comms between them.  Also, does the Pi even work as a USB host?

[Ben Franske]

On 3/13/2013 12:11 AM, lincomatic wrote:

Sorry, I don�t quite understand.. you want to connect the OpenEVSE board as a USB device to a Raspberry Pi as a USB host? I don�t see the advantage of that over just doing serial comms between them.� Also, does the Pi even work as a USB host?

The Pi definitely works as a USB host, it's a full fledged ARM SoC which typically runs Linux. There are also people writing native ARM code though for more RTOS/MCU like capability. That said...I agree with you that serial is preferable for interfacing with a MCU for reasons I previously specified.
-Ben

[Mike Brown]

Please forgive and explain to me if this is an ignorant question. The recent reports of garbled LCD displays make me wonder if there would be value to providing isolation between the OpenEVSE controller and the Raspberry Pi. If so, whats the lowest cost way to use optical or wireless isolation?

Regards,
Mike

[Chris Howell]

Mike,

I believe the adafruit issue is due to an overall poor design by adafruit. There are a number of issues with that board including missing grounds, resistors way too close to the mounting holes. And there are ZERO capacitors on the adafruit unit which I believe is what is causing the issue.

This is the primary reason I designed the Open EVSE LCD. There is a .1uf cap very close to to the chip. So gar there have not been any reports of garbled text on the OpenEVSE version.

Chris

[Mike Brown]

Thanks Chris. Its reassuring that you've already thought thru these issues.

Mike

[jeanmiche...@gmail.com]

First of all, I'd like to thank very much Chris and Sam for the great work they have done.

Open EVSE is my first electronic project and the first time I use Arduino IDE and Atmel chip.
I've discovered, with a big interest, a very large community of users and a huge amount of hardware and software available. A fascinating travel throught Eagle, Digikey endless references, Arduino IDE, C++, components datasheets, soldering issues...

As I live in France, I first thought I couldn't use the OpenEVSE plus board upon our electrical standards. NB : I've discovered very late, but without regrets;), that I probably could.
So I started to modify code (from V1.0.9) and hardware (from DIY V4 PCB) since last november.
Since then, I've :
0. first modified PCB and software to support auto service level setting through off-peak-hours signal (AC relay on mains). In France, we use either single-phase (230 VAC) or 3-phase (380 VAC) current but not 2-phase current. So I reuse one of MID400 optocoupler to get in off-peak-hours AC current. Nota : I felt better to leak to ground only the one for ground and relay testing. The other one is connected to the neutral wire.
1. added code for energy monitor support (either current and voltage or current only monitoring) and display of energy consumed (kwh), instant real power (w)...
2. added code for electricity meter remote information support. In France, most recent electricity meters on mains reports informations (instant current, counters...) through an AC serial line. I use it to dynamically adjust the PWM signal to avoid meter's trip due to current consumption over current subscription. Only an optocoupler and a resistor are necessary, but I hardly found that I must use UART...
3. added code for 1wire thermometer support (DS18B20). I don't know if it's really a useful additional security, but for the fun ;)
4. solved defect number 4 (Changes in CLI not reflected in LCD Display until state change) ;) I still have issue number 5 despite use of LiquidTWI2 library last version.
5. modified the PCB to add components required for the above features, some wires (reset...), etc.
...
The last compile with Arduino IDE 1.0.4 shows a binary size of 30 986 bytes.

As I'm waiting for my future Renault Zoé to be delivered at the end of next week, right now, I couldn't fully test my software and hardware modifications, especially the 1wire mod (still expecting DS18B20 sensor ;)). Actually, I'm even not sure that OpenEVSE is compatible with this car...
Nevertheless, if you're interested in these modifications, I can post code and eagle files (.brd and .sch).

I would ask you two questions :
- May I use digital pin 9 (for the 1wire sensor in fact) ? I'm not sure I can, because PWM for pilot wire seems to use pins 9, 10 and 11 (seen in SetPWM function comments)
- How can I safely test GFCI ? What current leakage is enough to trigger it ?

Jean-Michel

[lincomatic]

Hi Jean-Michel,

I think the Zoe uses a Type 2 connector, but it should work OK if you can figure out the wiring. I believe it still uses the J1772 standard … but you should double check.

 

Is your board able to run the unmodified code without any issues?  Even though your code size is small enough to fit, the main problem we’ve been having is fitting into the 2K RAM constraint.

You may have to disable the LCD menus in order get it small enough.

 

If your energy monitoring code uses floating point, be careful about latency issues.. the GFCI is triggered via software.  Also, it might introduce delays which alter the timing of the handshake with the car.

 

I think you cannot use pin 9, since it outputs a PWM signal.

-Sam

From: open...@googlegroups.com [mailto:open...@googlegroups.com] On Behalf Of jeanmiche...@gmail.com
Sent: Wednesday, March 27, 2013 4:58 PM
To: open...@googlegroups.com
Subject: Re: v5 and other discussion

 

First of all, I'd like to thank very much Chris and Sam for the great work they have done.

--

[Chris]

Hi Jean-Michel,

 

Sounds like you have a great build. I would love to see your source code, a lot of people are interested in the power monitoring. I am working on a i2c board to measure voltage and current loosely based on openenergy.

 

You can use pin 9 in some instances but it is not recommended. Because it is tied to PWM you can't manipulate by normal means. You can try setting it as an input and then enabling either the pull up or pull down... It's pretty messy but you may be able to get some functionality from the pin.

 

To test GFCI I use a 24VAC sprinkler transformer. The trip current is set to 20ma. So to test I run 1 wire through the CT and then attach a 4800Ohm (5ma) resistor between the transformer leads GFCI should not trip. Change the resistor to 1000 Ohm to 1200 Ohm  (20ma) and GFCI should trip.

 

Chris

[jeanmiche...@gmail.com]

Hi Chris,

Here is the source code.

It seems to work fine without RAM issue (without DS18B20 sensor) and without the car ;)

Jean-Michel

Le jeudi 28 mars 2013 17:56:06 UTC+1, Chris a écrit :

Hi Jean-Michel,

 

Sounds like you have a great build. I would love to see your source code, a lot of people are interested in the power monitoring. I am working on a i2c board to measure voltage and current loosely based on openenergy.

...

Chris

[jeanmiche...@gmail.com]

Hi Sam,

You are perhaps (or certainly) right for responses times concerns.
Energy monitor requires half a second to measure and calculate RMS voltage and current.
Electricity Meter reading requires around one second to get useful informations (because of low flow rate - 1200 bauds).
However, I've added update delays to reduce latencies.

I think GFCI isn't a problem as it's triggered by hardware interrupt.

Jean-Michel

Le jeudi 28 mars 2013 04:36:19 UTC+1, lincomatic a écrit :

Hi Jean-Michel,

...

 

Is your board able to run the unmodified code without any issues?  Even though your code size is small enough to fit, the main problem we’ve been having is fitting into the 2K RAM constraint.

 

If your energy monitoring code uses floating point, be careful about latency issues.. the GFCI is triggered via software.  Also, it might introduce delays which alter the timing of the handshake with the car. 

...

-Sam

[jeanmiche...@gmail.com]

I've quickly merged this version with the development version from lincomatic github.

Without OneWire support, the program fits in flash memory. Not yet tested at all so I don't now if there are RAM space issues.

Jean-Michel

[lincomatic]

That’s great that you got the energy monitoring to fit in.

 

D’oh. I wrote the GFCI code and forgot that it was interrupt driven … it’s been a while.

 

I wonder if the EVSE polling could be moved to a software interrupt to reduce the impact of the energy monitor/electricity meter latencies.

-Sam

 

 

From: open...@googlegroups.com [mailto:open...@googlegroups.com] On Behalf Of jeanmiche...@gmail.com
Sent: Monday, April 1, 2013 9:06 AM
To: open...@googlegroups.com
Subject: Re: v5 and other discussion

 

Hi Sam,

--

[jeanmiche...@gmail.com]

The main concern about response times seems to be the specification 2 in table 6 from J1772 standard : delay from disconnect until the contactor opens and terminates AC energy transfer must be 100 ms maximum.
So it should be a good idea to trigger part of the J1772EVSEController::Update() code by a timer interrupt and maybe also BtnHandler::ChkBtn() function.

It a bit out of my knowledge at the moment, but it would be a good exercise...

Jean-Michel

[jeanmiche...@gmail.com]

Bug found with the car : need to replace (in constants, variables and functions names) KWh by Wh (and to add one digit to display values).