Open EVSE NG

[Andrew Kornev]

Hello!

A few days ago I start a project with temporary name - "Open EVSE NG", based on STM32-series MCU.
Hardware partially based on Open EVSE II.

Schematics of control board:
https://drive.google.com/file/d/0B0cdiq3qZemmMllFVGNFV0oyaE0/view?usp=sharing

Features:
STM32F373xx MCU
16x2 RGB LCD over I2C, GLCD over SPI - optional
RTC with backup battery
Integrated temperature sensor, external temperature sensor - optional
GFI
Current sensor (up to 3 sensors) with true differential input and PGA
CAN or RS-485 for comms with up-level controller, USB and TTL-UART optional.
ESP8266 WiFi module - optional
Mifare reader - optional

HomePlug Green Phy over SPI - optional
Driver for lock actuator - optional

FreeRTOS

Advantages:
Powerful MCU
Not need for RTC and temperature sensor - both embedded in MCU
More precise energy measurement (thanks to 16-bit Sigma-Delta ADC)
Rugged interfaces (CAN or RS-485)
Rugged multitask OS
Great opportunities for extensions

Disadvantages:
A bit more expensive than ATmega-based Open EVSE

Any suggestions and comments are welcome!

Best Regards.
Andrew
P.S. I'm sorry for my English.

[Alan Kirk]

First:  Welcome!   Your English is excellent (better than many American posters). 

Keep up the good work and let this group know how they may help. 

Good to see you have included the WiFi module as that is becoming more popular, as will the MiFare addition.

What are your plans to layout and fabricate boards?

[Andrew Kornev]

Hello, community!

On 21.09.2015 19:35, Alan Kirk wrote:

First:  Welcome!   Your English is excellent (better than many American posters). 

Keep up the good work and let this group know how they may help. 

Good to see you have included the WiFi module as that is becoming more popular, as will the MiFare addition.

What are your plans to layout and fabricate boards?

Now I have a own OpenEVSE II compatible EV charger based on ATMega. Schematics and PCB is slightly different as original.

I porting OpenEVSE software to the Arduino-STM32 and it working properly on demo board.
But I don't quite like the Arduino, and I start to develop own software based on FreeRTOS. Most of the code ported without problems, but I need the help of the community.
Eventually, I want to make a working PCBs based on STM32F373xx before Christmas.

Best Regards.
Andrew

 

[lincomatic]

Andrew,

 

Welcome! I have been interested in the possibility of an ARM-based implementation for a while.

Your project looks very interesting. Please keep us posted of your progress. I’m sure there are plenty of people

here who can help you.

 

I am waiting to receive a Maple mini compatible STM32 board that I ordered last week to experiment with for other projects. Besides the bad IDE, what don’t you like about Arduino-STM32? Also, would you be willing to share your port of the OpenEVSE firmware? I am interested to see how much modification it needed. Also, I would be interested in hearing what the advantages are of using FreeRTOS.

 

-Sam (lincomatic)

--
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/d/optout.

[EV@TucsonEV]

The link doesn’t work for me…

 

Rush Dougherty

www.TucsonEV.com

 

--

[Andrew Kornev]

Hello, everybody!
I'm still don't have any hardware based on STM32F373xx.
Now I use STM32F103-based demoboard. And I have STM32F3-Discovery for further development.

Arduino-STM32 I use only with STM32F103.
A few words about porting Arduino code:
https://docs.google.com/document/d/1U7SBKzmZym7QbmxbQcMchSThQ0kHS8iAqCXhIJF9sow/edit?usp=sharing

The main thing for me now is to resolve all questions about the schematics - use LQFP48 -light version or just build around LQFP64 - full version. So, now hardware is more important than software for me.

Best regards
Andrew

You received this message because you are subscribed to a topic in the Google Groups "OpenEVSE" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openevse/LMwetY4up4A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openevse+u...@googlegroups.com.

[Glenn Drayer]

You might consider changing the name. In English NG is commonly used for no good!

-------- Original Message --------
Subject: RE: Open EVSE NG
From: "EV@TucsonEV" <E...@TucsonEV.com>
Date: Mon, September 21, 2015 4:10 pm
To: <open...@googlegroups.com>

The link doesn’t work for me…

 

Rush Dougherty

www.TucsonEV.com

 

From: open...@googlegroups.com [mailto:open...@googlegroups.com] On Behalf Of Andrew Kornev
Sent: Monday, September 21, 2015 3:42 AM
To: OpenEVSE
Subject: Open EVSE NG

 

[chris1howell .]

You may also want to consider adding stuck relay detection and ground monitoring. There are essential for safety certifications.

[Danny ter Haar]

On Tuesday, September 22, 2015 at 10:17:28 AM UTC-7, Glenn Drayer wrote:

You might consider changing the name. In English NG is commonly used for no good!

 http://www.abbreviations.com/NG

Given the context, I automatically assumed new/next generation to be honest.

[Andrew Kornev]

Hello!
On the control board you can see an a inputs named "RELAY_TEST" and "GFI" in conjunction with "GFI_TEST" outputs. This part of schematics like Open EVSE II.

You received this message because you are subscribed to a topic in the Google Groups "OpenEVSE" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openevse/LMwetY4up4A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openevse+u...@googlegroups.com.

[Andrew Kornev]

On 22.09.2015 20:33, Danny ter Haar wrote:

On Tuesday, September 22, 2015 at 10:17:28 AM UTC-7, Glenn Drayer wrote:

You might consider changing the name. In English NG is commonly used for no good!

 http://www.abbreviations.com/NG

Given the context, I automatically assumes new/next generation to be honest.

Yes, I mean OpenEVSE - Next Generation

[Andrew Kornev]

Hello!

I finished the schematics and PCB, and ready to order manufacturing.
Maybe the layout is not very optimal but enough for development.
I will be ordering 10 pieces for myself. If someone is interested of PCB - send me a message.

Schematics of the control board:
https://drive.google.com/file/d/0B0cdiq3qZemmV0E5MEc2Mmh0MG8/view?usp=sharing
3D visualisation of the PCB:
https://drive.google.com/file/d/0B0cdiq3qZemmSUlZQ3pUZ1JGYms/view?usp=sharing

Best regards
Andrew

[Danny ter Haar]

How about this as basis for new openevse ?
http://www.up-board.org/

specs: http://www.up-board.org/specifications/

Might be a little pricy and overpowered.

But I like the concept.

[Craig Kirkpatrick]

Danny, It looks like an Intel Galileo in a Pi format.  

A friend gave me a Galileo.  I power it with 12V as suggested, the processor with no heat sink gets too hot to safely touch running some do-nothing loop, maybe consuming 3W I suppose.

I have a few Raspberry Pi2's and they get warm, not hot.

Lately my thinking is that the existing OpenEVSE V4 is a very mature and a great real-time processor for what needs handling in real-time with OpenEVSE.

The existing OpenEVSE RAPI interface means that any coprocessor or WiFi coprocessor can command anything possible with the OpenEVSE since such commands and reactions work fine occurring in 100ms of time or more.

I sort of dropped off of the ESP8266 discussion because of some of my life's distractions.  I need to get back on board with that work.  It has a lot of promise as an inexpensive WiFi coprocessor.

Another thought is a new LCD display with a processor that bridges to WiFi and communicates with RAPI and unloads all of the menu code strings from OpenEVSE probably giving back >4K to the realtime processing on OpenEVSE.  It could be a 100% compatible drop-in replacement for the existing LCD module.  Give that a thought for a moment.

These are just my thoughts and dreams, worthy of a good debate.

-Craig K.

[Danny ter Haar]

On Sunday, October 18, 2015 at 3:09:46 PM UTC-7, Craig Kirkpatrick wrote:

Danny, It looks like an Intel Galileo in a Pi format.  

A friend gave me a Galileo.  I power it with 12V as suggested, the processor with no heat sink gets too hot to safely touch running some do-nothing loop, maybe consuming 3W I suppose.

This unit runs of 5 volt

cpu is 2 watt

http://ark.intel.com/products/87383/Intel-Atom-x5-Z8300-Processor-2M-Cache-up-to-1_84-GHz

I have a few Raspberry Pi2's and they get warm, not hot.

I have 3 pi's and they are independable.

I had one in a shed with wifi and longest it would run was 14 days.

Maybe I am unlucky with uptime ;-)

 

Lately my thinking is that the existing OpenEVSE V4 is a very mature and a great real-time processor for what needs handling in real-time with OpenEVSE.

The existing OpenEVSE RAPI interface means that any coprocessor or WiFi coprocessor can command anything possible with the OpenEVSE since such commands and reactions work fine occurring in 100ms of time or more.

But being within the IoT era, I think the openevse NG should have some more flexibility and capability.

The current setup, although cheap and stable, is becoming a limitation.

 

I sort of dropped off of the ESP8266 discussion because of some of my life's distractions.  I need to get back on board with that work.  It has a lot of promise as an inexpensive WiFi coprocessor.

Another thought is a new LCD display with a processor that bridges to WiFi and communicates with RAPI and unloads all of the menu code strings from OpenEVSE probably giving back >4K to the realtime processing on OpenEVSE.  It could be a 100% compatible drop-in replacement for the existing LCD module.  Give that a thought for a moment.

adds (imo) complication.

who does what, rapi to the display with internal rapi to the openevse controller.

lots of overhead and timing loops.

(just my feedback)

 

These are just my thoughts and dreams, worthy of a good debate.

-Craig K.

Absolutely

 

[Craig Kirkpatrick]

Nice discussion.  Thanks.

Already if I comment out #define DELAYTIMER_MENU I get 3,254 bytes of code space freed up and I can still set the delay timer via RAPI.  That is one example of offloading things to a RAPI coprocessor.  Think of the coprocessor as handling things that are user interface related in human-time and the existing OpenEVSE controller handling real-time communications and protocol with the EV.

I understand the concern of the complication having two processors.  What is needed between two processor is a well-defined interface specification.  Actually we have that with RAPI, but I can imagine that RAPI could need to expand a bit possibly as we dream up new features.

I think Intel is headed off of the deep-dive with IOT, wanting to provide blot-out-the-sun IOT performance and ability.  When really what is needed is not over-engineering, but just enough engineering.  I like the less than $10 Esp8266 since it is just enough engineering to get the Thing onto the Internet and then other powerful clients use the data.  Emoncms is a good example of that, working nicely and having no benefit from a 1GHz coprocessor burning 2W of power when doing next to nothing.

By the way Danny, have you played with your RC522 NFC card readers yet?  I got a few of them and mine work nicely.  I can imagine a 100% OpenEVSE RAPI drop-in that would validate NFC cards to enable charging.

-Craig K.

[chris1howell .]

Last time I checked, If LCD, RTC, Timers, Button Menu, etc was all turned off and only core code was left + RAPI was enabled it was about 6k/32k. The LCD/UI is the majority of the code.

--

[Danny ter Haar]

On Sunday, October 18, 2015 at 3:46:53 PM UTC-7, Craig Kirkpatrick wrote:

I understand the concern of the complication having two processors.  What is needed between two processor is a well-defined interface specification.  Actually we have that with RAPI, but I can imagine that RAPI could need to expand a bit possibly as we dream up new features.

Why not everything on 1 processor that has so much computing power that it doesn't matter what you add to it ?

10" touch screen ? no problem.

IPV6 connectivity (sorry, know that a lot of people still don't take it seriously, but I've been fully ipv6 enabled now for 6 years, it is possible and necessary!)

I think Intel is headed off of the deep-dive with IOT, wanting to provide blot-out-the-sun IOT performance and ability.  When really what is needed is not over-engineering, but just enough engineering.  I like the less than $10 Esp8266 since it is just enough engineering to get the Thing onto the Internet and then other powerful clients use the data.  Emoncms is a good example of that, working nicely and having no benefit from a 1GHz coprocessor burning 2W of power when doing next to nothing.

From
https://github.com/nodemcu/nodemcu-firmware/issues/302

The IPv6 stack will probably leave the current ESP8266 with little or no available RAM. 

On the next generation of IoT devices with 256KB RAM it will be a good idea, but so would decent security and a more functional OS.

 

By the way Danny, have you played with your RC522 NFC card readers yet?  I got a few of them and mine work nicely.  I can imagine a 100% OpenEVSE RAPI drop-in that would validate NFC cards to enable charging.

-Craig K.

Sorry, didn't have any opportunity playing with them.

I have all the hardware/intentions, but not enough hours in the day ;-)

 

[Danny ter Haar]

On Sunday, October 18, 2015 at 3:46:53 PM UTC-7, Craig Kirkpatrick wrote:

  Emoncms is a good example of that, working nicely and having no benefit from a 1GHz coprocessor burning 2W of power when doing next to nothing.

The 2 watt is maxium what the quad-core cpu _can_ use.

According to:
http://www.intel.sg/content/dam/www/public/us/en/documents/product-briefs/atom-x5-processor-z8300-product-brief.pdf

it has:  

Intel® Power Optimizer and Processor C-States

Helps to reduce power consumption through more and longer silicon sleep states across the CPU,

chipset, and third-party system components. Processor C-states (C7) provide low idle power

According to this:

http://www.cpu-world.com/CPUs/Atom_x5/Intel-Atom%20x5%20Z8300.html

Low power features

Core C1/C1E, C6, C6C and C7 states

Package C1/C1E, C6 and C7 states

Enhanced SpeedStep technology

Other thing _I_ like is that it suports virtualisation.

I can imagine one vm handling the screen/buttons,

another internet communication

another the loop with the interfaces and communication with EV

I can imagine another with environmental controls, garage door openers, temp/humidy measuring etc.

Development on normal pc hardware.

Oh well, i can dream, right ? :-)

[lincomatic]

It might fit in directly with DELAYTIMER_MENU turned off, but I haven’t tried it yet.

 

From: open...@googlegroups.com [mailto:open...@googlegroups.com] On Behalf Of Danny ter Haar
Sent: Sunday, October 18, 2015 8:52 PM
To: OpenEVSE
Subject: Re: Open EVSE NG

 

By the way Danny, have you played with your RC522 NFC card readers yet?  I got a few of them and mine work nicely.  I can imagine a 100% OpenEVSE RAPI drop-in that would validate NFC cards to enable charging.

 

-Craig K.

 

[Andrew Kornev]

Hello!
In the last week I got a few PCBs from manufacturer and assembled one of them for software development.
I'm on "vacation" now and I have a lot of time to develop the software.
Best regards.
Andrew

[Danny ter Haar]

Anyone seen this ?

https://www.thurrott.com/mobile/62587/raspberry-pi-introduces-a-5-computer

Together with a usb wifi module that really looks like a lot of fun.

[chris1howell .]

Saw that this morning... I wish they had a $10 version with built in Wifi...Adding network would need a USB OTG cable plus USB WiFi.

[Danny ter Haar]

On Thursday, November 26, 2015 at 2:33:13 PM UTC-8, Chris wrote:

Saw that this morning... I wish they had a $10 version with built in Wifi...Adding network would need a USB OTG cable plus USB WiFi.

I am going to EV meeting in Santa Ana on Saturday, will be close to supermicro center.

Will pick one or 2 up ;-) 

[lincomatic]

Were you actually able to get one? They seem to be out of stock everywhere.

 

From: open...@googlegroups.com [mailto:open...@googlegroups.com] On Behalf Of Danny ter Haar
Sent: Thursday, November 26, 2015 2:46 PM
To: OpenEVSE
Subject: Re: Open EVSE NG

 

I am going to EV meeting in Santa Ana on Saturday, will be close to supermicro center.

Will pick one or 2 up ;-) 

--

[Danny ter Haar]

On Thursday, December 3, 2015 at 6:49:28 PM UTC-8, lincomatic wrote:

Were you actually able to get one? They seem to be out of stock everywhere.

Nope, sold out the day before :-( 

[Nick Sayer]

I got a pi zero and made a stratum 1 NTP server out of it.

FWIW, I sell a thing called "Pi Power" in my Tindie store - it's a high quality, 2A power supply that plugs into the GPIO ports rather than the µUSB power jack. It in turn has a 2.1mm barrel connector for 6-14 VDC power input. Getting 800 mA or so at 12 volts from a wall wart is a lot easier and cheaper than getting a really high quality 2A@5V. But I digress.

The zero itself is cheap, but when you start adding up what you have to connect to it to make it useful, that savings starts to disappear. That said, it is a pretty good way to embed a VGA (or better) display into projects. I could imagine setting one up to be an i2c slave connected to OpenEVSE and having it display all sorts of status stuff with very high quality graphics.

[Martii]

Hi,

Interesting project - I like you used KiCad my favorite PCB editor.

What is the status of your project?

Regards,
Martin