Announcing: "NoSpark" firmware project

[Andre Eisenbach]

Meet NoSpark, an alternative firmware for the OpenEVSE board, written from scratch.
NoSpark aims to be a drop-in replacement for the existing firmware, developed in C++ for the AVR microcontroller.

Why develop NoSpark?
- AVR C++11
- No Arduino libraries/build dependencies
- Uses "make" build system
- Modular design
- Lightweight
- Why not?! That's what having an open source EVSE is all about :)

There are no fancy features planned for the initial version.
It will simply be a drop-in replacement to perform the basic functions:
- Charge state management and pilot generation
- Fault checking & relay control

- Current measurement
- LCD user interface & button menu
- Persistent settings (EEPROM)
- RTC control
- Serial console (+Bluetooth dongle)

The purpose is to get a nice modular framework up and running first.
Since I fully expect to have flash space left over after implementing the basics, there will be room for more advanced features down the road.

It all starts today, with an empty git repository...
https://github.com/int2str/NoSpark

I am not looking for contributions at this point, since I'm still tinkering with many of the details.
But of course, down the road I will open up the project to any contributions. And comments and criticisms are always welcome, especially as the program takes shape.

I will update this thread as things develop so you can follow along as "NoSpark" takes shape or goes up in flames :)

[Andre Eisenbach]

Development update 1

Please excuse me replying to my own post, but I'd like to given an initial development update.

After sifting trough the posted schematics, existing firmware and a million data sheets, I was able to setup my own Arduino UNO to be a stand-in development platform while my OpenEVSE is on order. With that, I was able to set up the framework and started coding up various features and get a first estimate at flash used etc.

Implemented (from scratch) so far:

- Setup event framework and initial project structure.

The idea here is that different "modules" will be able to post events that other modules can register for. For example, the "keyboard" module can generate a "keydown" event that the LCD user interface module can use to invoke a function.

- J1772 pilot wave generator

Nothing fancy here, just the AVR timer.

- I2C bus master (to drive I/O extender, read RTC etc.)

AVR only code. No "Wire.h" etc. Master only saves a little bit of space.

- Implemented LCD controller module

The LCD module will stand by itself and not mix key handling code etc.

Down the road the plan would be to make the UI easily replaceable. That is also one of the main reasons for the [partially] event driven approach.

- Watchdog

Again nothing fancy, simple AVR wrapper

- Serial console

Implemented through the hardware USART of course. No "Serial" library means no "Print" cruft means much smaller....

Got a basic prompt and help system going. Also completely event driven so serial I/O doesn't block very long to keep everything nice and responsive.

What's next?

- EEPROM read/write (this will add a few kb)

- RTC / date/time handling

Once these are in place I should have all the building blocks to control the OpenEVSE.

Then it's on to implement the "actual" guts:

- Maintain global state (charging, plugged in, kwh etc.)

- UI and menus....

As a little teaser, here's what compiling the program currently looks like and the current binary size with the above mentioned features in place:

$ make -s

[C++] mcp23008.cpp

[C++] lcd1602.cpp

[C++] mcp23017.cpp

[C++] pcf8574.cpp

[LIB] libdevices.a

[C++] j1772pilot.cpp

[C++] i2c_master.cpp

[C++] pin.cpp

[C++] keyboard.cpp

[LIB] libboard.a

[C++] serialconsole.cpp

[LIB] libui.a

[C++] event.cpp

[C++] loop.cpp

[C++] handler.cpp

[LIB] libevent.a

[C++] usart.cpp

[LIB] libserial.a

[C++] watchdog.cpp

[C++] timer.cpp

[LIB] libsystem.a

[C++] cpp.cpp

[LIB] libutils.a

[C++] main.cpp

[LNK] nospark.elf

   text    data     bss     dec     hex filename

   4340      96     186    4622    120e obj/nospark.elf

[HEX] nospark.hex

Here's an example of the code (j1772oilot.h):

// NoSpark - OpenEVSE charger firmware

// Copyright (C) 2015 Andre Eisenbach

//

// This program is free software: you can redistribute it and/or modify

// it under the terms of the GNU General Public License as published by

// the Free Software Foundation, either version 3 of the License

//

// This program is distributed in the hope that it will be useful,

// but WITHOUT ANY WARRANTY; without even the implied warranty of

// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the

// GNU General Public License for more details.

//

// See LICENSE for a copy of the GNU General Public License or see

// it online at <http://www.gnu.org/licenses/>.

#pragma once

#include <stdint.h>

#include "utils/cpp.h"

namespace board

{

// Uses timer1 for PWM, thus PIN 10 is automatically used,

// no need to abstract it.

class J1772Pilot

{

public:

    J1772Pilot();

    

    void high();

    void low();

    void pwmAmps(const uint8_t amps);

private:

    DISALLOW_COPY_AND_ASSIGN(J1772Pilot);

};

}

[lincomatic]

A good start. Looking forward to seeing what you come up with. Thanks for sharing.

Will you be checking code in during your initial development?

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

[Andre Eisenbach]

On the fence about it. Might wait until I have the unit in my hands so I can test the basics first.

Though having it checked in will working on it from various machines either, so I might.

[Andre Eisenbach]

Having fun with the LCD :)

https://www.youtube.com/watch?v=Tz6tLkTmYN0 

[Andre Eisenbach]

Development update 2

Received a DS3231 RTC in the mail today. This allowed me to implement the RTC code as well as temperature reading. Most libraries I've seen do BCD to decimal coding/decoding all the time. Where the temperature is only displayed, I'm actually printing off the raw buffer data to avoid unnecessary conversions. And of course no floating point for the temperature.

A "settime" command has been added to the serial console to allow setting the time. LCD UI to be added down the road.

The main charging workflow should be implemented at this point, including the pilot and relay control. So with only a few adjustments, the OpenEVSE should be able to charge with the current NoSpark firmware already.

Also implemented the relay and GFI power-on self tests.

This is probably as far as I can push it without actual hardware.

With the major items in place, including serial console, RTC & temperature reading and more, the firmware now sits at this sizs:

AVR Memory Usage

----------------

Device: atmega328p

Program:    9584 bytes (29.2% Full)

(.text + .data + .bootloader)

Data:        417 bytes (20.4% Full)

(.data + .bss + .noinit)

Not as small as I had hoped, but certainly small enough to leave plenty of room for features/improvements down the road.

Main items remaining:

- Ammeter including calibration storage

- LCD menu for various settings

- Testing...

[Danny ter Haar]

On Monday, March 2, 2015 at 12:19:16 AM UTC-8, Andre Eisenbach wrote:

Also implemented the relay and GFI power-on self tests.

This is probably as far as I can push it without actual hardware.

With the major items in place, including serial console, RTC & temperature reading and more, the firmware now sits at this sizs:

AVR Memory Usage

----------------

Device: atmega328p

Program:    9584 bytes (29.2% Full)

(.text + .data + .bootloader)

Data:        417 bytes (20.4% Full)

(.data + .bss + .noinit)

Not as small as I had hoped, but certainly small enough to leave plenty of room for features/improvements down the road.

Main items remaining:

- Ammeter including calibration storage

- LCD menu for various settings

- Testing...

Could you upload  a .hex somewhere ? I have a spare openevse, would like to test it out ;-)

[Andre Eisenbach]

On Monday, March 2, 2015 at 5:48:38 AM UTC-8, Danny ter Haar wrote:

Could you upload  a .hex somewhere ? I have a spare openevse, would like to test it out ;-)

A bit too early for that :) 

So far all the development I've done is based on the schematics, datasheets & existing source. My test platform is an Arduino Uno board with various peripherals hooked up.

I should get my OpenEVSE some time this week. Once I get it, I will be able to try it on an actual device.

Source and HEX files will go up as soon as I can successfully test it at least once :D

[Danny ter Haar]

Source and HEX files will go up as soon as I can successfully test it at least once :D

thanks, looking forward! 

[Andre Eisenbach]

Development update 3

With the firmware now running on the actual device, I was able to adjust the LCD driver for the one attached to the MCP23017. Also added the backlight color control. Fixed a few bugs here and there and now the control workflow seems to be solid.

Here's a video of the various J1772 states:

https://www.youtube.com/watch?v=F1NIV9EZpIE

The time (top left) is working. Since there's no battery in the RTC right now it resets to 00:00 of course. The temperature is also working and coming from the RTC chip.

In theory, the firmware would correctly control the charging process as is already.

Still lots to do however:

- Current meter

- Settings & menu handling

- Event de-bouncing (to avoid potential relay flutter etc.)

Things have grown a bit, but given the fact that it's nearly functional, I'm not too unhappy:

AVR Memory Usage

----------------

Device: atmega328p

Program:   10142 bytes (31.0% Full)

(.text + .data + .bootloader)

Data:        421 bytes (20.6% Full)

[EV@TucsonEV]

Very nice Andre,

 

Rush Dougherty

Tucson AZ

From: open...@googlegroups.com [mailto:open...@googlegroups.com] On Behalf Of Andre Eisenbach
Sent: Thursday, March 05, 2015 1:14 AM
To: open...@googlegroups.com
Subject: Re: Announcing: "NoSpark" firmware project

 

Development update 3

--

[Andre Eisenbach]

NoSpark v0.1

After a long delay caused by upload/programming issues with my board, I've finally made some progress and am pleased to announce the first open source code upload, aka. "NoSpark v0.1".

This is NOT a working firmware yet (though I think it technically would charge your car). Do NOT try it.

I'm only uploading the code to show off some of the progress and show the direction where I'm going with the firmware.

It's still missing a lot of features, but the framework is essentially in place now.

Next items to tackle:

- Current measurement

- Settings

- Complete charging UI

- Temperature limits

- etc. etc. etc.; lots to do...

Feel free to download the code, check it out, heck even compile it. But again, you probably don't want to run it on an actual device yet ;)

Comments / criticism etc. welcome!

Github link:

https://github.com/int2str/NoSpark

[Andre Eisenbach]

Development update 4

Since the initial upload to github, more cleanup & refactoring has gone in. Technically, there should be a focus on "getting it done" first, but the base of the firmware should be solid so that cruft doesn't already build up as we go along...

Highlight from the recent work is implementing the event queue/loop more aligned with C++11. By implementing iterators for the queue this previous event loop code:

void Loop::dispatch_impl()

{

    while (!q_event.empty())

    {

        const Event& event = q_event.front();

        Handler* handler = q_handler.front();

        while (1)

        {

            handler->onEvent(event);

            if (!q_handler.has_next())

            break;

            handler = q_handler.next();

        }

        q_event.pop();

    }

}

Could be turned into this:

void Loop::dispatch_impl()

{

    while (!events.empty())

    {

        auto event = events.front();

        for (auto handler : handlers)

            handler->onEvent(event);

        events.pop();

    }

}

Nice! I like C++11 :)

I've also started to change the way the LCD UI is handled, which once implemented, should enable me to finish up settings soon. After that the ammeter is next...

Here are the beginnings of the settings UI with custom made icons :) :

https://www.youtube.com/watch?v=VP02YhTghFA

Firmware is stating to get a little "chubby", but still plenty off room for expansion/features:

AVR Memory Usage

----------------

Device: atmega328p

Program:   13122 bytes (40.0% Full)

(.text + .data + .bootloader)

Data:        538 bytes (26.3% Full)

[Danny ter Haar]

On Saturday, March 28, 2015 at 12:22:17 PM UTC-7, Andre Eisenbach wrote:

Development update 4

Looks _very_ slick & nice!

update:

*wowzers*

was able to compile and flash it to my test setup and it boots ! 

*SWEET*

[Andre Eisenbach]

Development update 5

It's alive!

After finishing the build and installing a 240V outlet today, I am happy to report that NoSpark v0.01 has successfully charged a vehicle for the first time! To "celebrate" this milestone, I've tagged the current codebase as NoSpark v0.02. Baby steps, I know :)

Of course because the unit is hanging on the wall now development might be a bit harder. Then again, I can actually test charging now, which will help.

Next steps:

- Temperature based throttling/shut-off

- Charge timer

- Current measurement

I would still NOT recommend using NoSpark yet!

But we're getting closer :)

Source as always can be found here:

https://github.com/int2str/NoSpark

[Danny ter Haar]

On Saturday, April 18, 2015 at 9:23:34 PM UTC-7, Andre Eisenbach wrote:

Development update 5

It's alive!

After finishing the build and installing a 240V outlet today, I am happy to report that NoSpark v0.01 has successfully charged a vehicle for the first time! To "celebrate" this milestone, I've tagged the current codebase as NoSpark v0.02. 

Few points of feedback:

a)

I love how it boots and the character set. Very nice !

b)

I installed it on V2 hardware with a 12V relay setup.

But it never engaged the relay.

Is nospark specifically for V3 hardware and a 2x0 volt contactor ?

c)

I am able to set amps going through the menu

But I wasn't able to set time/date.

Is that correct ?

I will try and get my car charged tonight with 0.02 ;-)

[Andre Eisenbach]

Danny,

Yes, NoSpark is currently OpenEVSE v3 compatible ONLY!

That's the only hardware I have and I do not want to put hardware abstraction code in place yet. Especially since I can't verify it myself.

I made sure that the code is structured such that it can be tailored to other hardware easily down the road, but for now, it only compiles for v3, sorry.

If you have the 2 relay version, it will definitely not work right now, since NoSpark is only toggling one pin currently.

If you went through the settings, did you notice the custom icons? :)

I'm hoping to play more with animations (especially during charging) as well as scrolling text etc. down the road.

The firmware currently sits at 14.5k of flash and around 600 bytes of RAM.

That is including the current measurement code I just added.

So there is plenty of room to "play" with features etc.

With the current sensing in place, I can now implement kWh calculation etc. next.

Once I got the basics in place and will consider the initial version to be "complete", then I will go back and finalize the hardware modularization to allow for new boards to be added more easily. If you look at the source, you may have noticed that things are already modular and the controller logic is separated from the UI as well as the board hardware access. This should make porting to other boards easy down the road. But again, not yet, sorry...

My day job doesn't allow me too much time to tinker, but I will try to move forward as much as I can...

[chris1howell .]

Andre,

There is very little difference between all the versions on the boards, pin usage has remained constant since the first board. The v3 actually has everything you need to test DC relays, the 12v DC relay ports are still present on the v3. The only difference is the v3 has a single chip to test AC presence on one hot line and the v2.5 and below test both hot lines. 

Send me a private Email and I will give you my number. I will be happy to provide some information learned along the way...

Chris

--

[Danny ter Haar]

On Sunday, April 19, 2015 at 10:56:21 PM UTC-7, Andre Eisenbach wrote:

Danny,

Yes, NoSpark is currently OpenEVSE v3 compatible ONLY!

Shouldn't be too hard to make it compatible with the other versions ;-)

I see that Chris already responded ;-)

 

That's the only hardware I have and I do not want to put hardware abstraction code in place yet. Especially since I can't verify it myself.

More than happy to test stuff for you ;-)

 

If you have the 2 relay version, it will definitely not work right now, since NoSpark is only toggling one pin currently.

I have a single 12 volt relay in my V2 

But I charged with my portable V3 with contactor last night using your 0.02 code.
I adjusted it with some finer amps but was easy to modify.

 

If you went through the settings, did you notice the custom icons? :)

That is what I refered to as "character set".

Degrees symbol, lightning strike.

Very _very_ slick !!!  

I'm hoping to play more with animations (especially during charging) as well as scrolling text etc. down the road.

Looking forward.

 

The firmware currently sits at 14.5k of flash and around 600 bytes of RAM.

Yeah, only 22 seconds to program vs 51 seconds for the original 3.3.4 code ;-)

 

That is including the current measurement code I just added.

Wasn't working on my version last night.

Got up at 3.30 to check if it was working. Temp gone up to 27C inside the box.

 

So there is plenty of room to "play" with features etc.

yeah!

 

With the current sensing in place, I can now implement kWh calculation etc. next.

;-)

 

c)

I am able to set amps going through the menu

But I wasn't able to set time/date.

Is that correct ?

So am I correct that I can NOT change time/date with the current version ?

I will follow up in the thread about amperage calculation as well.

Thanks

Another EV charged with your code last night ;-)

[Andre Eisenbach]

Danny,

You are a brave man! :)
Very cool to see that it worked.

You can set time/date from the serial console.

But, now that I have the first official "user", I'll probably implement that next :D

[Danny ter Haar]

On Monday, April 20, 2015 at 9:08:17 AM UTC-7, Andre Eisenbach wrote:

Very cool to see that it worked.

yeah, me too !

 

You can set time/date from the serial console.

Will do that, I had the idea of flashing the official openevse firmware, than flash it back to NoSpark.

I put in a battery yesterday, so should not need to be set anytime soon anymore.

But, now that I have the first official "user", I'll probably implement that next :D

I have an FTDI converter, will use that to set it ;-)

[Danny ter Haar]

Some feedback for you:

Unfortunately I live in a rental with dryer outlet in the garage.

It is behind a 30 amp breaker and the size of the wire I am feeling comfortable only drawing 24 (or sometimes I cheat with 26) amps of power. (I measured/calculated voltage drop over the cable & breaker and I feel fairly confident that 26 amps is safe ;-) )

I used the menu button to limit the charging current to 24 amp 

I tried it on my EV without charging timers and using yesterdays v0.02 it shows the current is feeding into the EV.

Very cool.

However, it doesn't seem to store that setting for the current.

When I do a powercycle of the openevse with nospark on my other car (which has timer set)

it automagically is reset to 40 amps.

So when I would experience a power outage, and it would restart after power returns, when my car would start to  charge using its timers, it would draw 40 amps with all the possible consequences 

Is it possible to store the set max amps and re-read that on startup ? 

Oh btw

during bootup after the graphical intro, I see a red screen for a split second.

Is that okay /wanted ? 

https://www.youtube.com/watch?v=2GVUkPi6vRA

[Nick Sayer]

FWIW, the diffs for OpenEVSE II should be straightforward.

There's only one relay output (pin 7), and only one relay/ground test input (pin 3). Unlike Chris' board, the relay test / ground test pin is not inverted - that is, it should read the same as the charging pin (modulo a transition delay that should be under 100 ms). There is no need to sample, the hardware will take care of holding the peak for you. You can steal the voltmeter code from OpenEVSE. In short, you read the appropriate analog pin (A2) looking for the peak across a full cycle time, then you use a predefined scale and offset to convert the result to a millivolt value.

OpenEVSE II has an MCP9808 temperature sensor on the logic board, as well as a PT7C4311 real-time clock (it's compatible with a DS1307).

[Nick Sayer]

I wonder if you'd be interested in attempting to add support for the Hydra... at least, the EVSE variant of it perhaps.

The hardware isn't as different as it sounds.

Each car gets a relay pin, a pilot output pin, an ammeter pin, a pilot readback pin and a relay/ground test pin (the two relay/ground test pins are analog pins re-purposed to be digital inputs). The Hydra as a whole also has a single GFI and GFI test pin. There is no voltmeter. There is a PT7C4311, but no MCP9808.

[Danny ter Haar]

On Monday, April 20, 2015 at 10:03:18 PM UTC-7, Danny ter Haar wrote:

Some feedback for you:

and some more

It charged my car that is set on a timer (leave at  7am)  another night.

I get up and at 6:50 am walk to the car.

The car is basically done charging and 20 minutes before leaving time, it does some extra conditioning.

So it is drawing 3 amps from the wall.

I interrupt that, and move the J1772 plug over to my second EV (which doesn't have a timer so starts charging immediately) 

I rush back to the display to watch what is going on. I hear the click of the contactor.

Amp reading is 39 amps (see other thread about calculating amp reading) goes down to about 5.

Then I witnessed a spontaneous reboot of NoSpark and it came back with the (for me dangerous) 40amp setting.

Luckily the car didn't start charging right away this time. So I used the menu to set 24 amps.

walked to the car unplugged/plugged the j1772 and my 2nd EV is now happily humming charging at 24 amps

I need to setup logging of some kind, would be interesting to know why it actually rebooted.

[Andre Eisenbach]

Watchdog timer reboot....

Let me make the AMP rating persistent so it restores it on reboot.

[Andre Eisenbach]

I've uploaded a new patch that fixes a potential endless loop, which would cause a watchdog reboot.

Hopefully that's the one that caused your reboot.

I'll still make the current setting persistence the next priority.

[Danny ter Haar]

On Tuesday, April 21, 2015 at 9:17:49 AM UTC-7, Andre Eisenbach wrote:

I've uploaded a new patch that fixes a potential endless loop, which would cause a watchdog reboot.

Hopefully that's the one that caused your reboot.

I'll still make the current setting persistence the next priority.

Thanks! looking forward!

 root@lenovo520:/usr/src/NoSpark# git pull

remote: Counting objects: 8, done.

remote: Compressing objects: 100% (1/1), done.

remote: Total 8 (delta 7), reused 8 (delta 7), pack-reused 0

Unpacking objects: 100% (8/8), done.

From https://github.com/int2str/NoSpark

   b117d49..7dcd522  master     -> origin/master

Updating b117d49..7dcd522

Fast-forward

 board/ammeter.cpp | 36 +++---------------------------------

 test/test.cpp     |  8 ++++++++

 utils/math.h      | 26 ++++++++++++++++++++++++++

 3 files changed, 37 insertions(+), 33 deletions(-)

root@lenovo520:/usr/src/NoSpark# time make

make[1]: Entering directory '/usr/src/NoSpark/evse'

[C++] controller.cpp

[LIB] libevse.a

make[1]: Leaving directory '/usr/src/NoSpark/evse'

make[1]: Entering directory '/usr/src/NoSpark/ui'

make[1]: Nothing to be done for 'all'.

make[1]: Leaving directory '/usr/src/NoSpark/ui'

make[1]: Entering directory '/usr/src/NoSpark/event'

make[1]: Nothing to be done for 'all'.

make[1]: Leaving directory '/usr/src/NoSpark/event'

make[1]: Entering directory '/usr/src/NoSpark/serial'

make[1]: Nothing to be done for 'all'.

make[1]: Leaving directory '/usr/src/NoSpark/serial'

make[1]: Entering directory '/usr/src/NoSpark/devices'

make[1]: Nothing to be done for 'all'.

make[1]: Leaving directory '/usr/src/NoSpark/devices'

make[1]: Entering directory '/usr/src/NoSpark/board'

[C++] j1772status.cpp

[C++] ammeter.cpp

[LIB] libboard.a

make[1]: Leaving directory '/usr/src/NoSpark/board'

make[1]: Entering directory '/usr/src/NoSpark/system'

make[1]: Nothing to be done for 'all'.

make[1]: Leaving directory '/usr/src/NoSpark/system'

make[1]: Entering directory '/usr/src/NoSpark/utils'

make[1]: Nothing to be done for 'all'.

make[1]: Leaving directory '/usr/src/NoSpark/utils'

[LNK] NoSpark.elf

   text   data    bss    dec    hex filename

  15096    234    469  15799   3db7 obj/NoSpark.elf

[HEX] NoSpark.hex

real 0m0.320s

user 0m0.113s

sys 0m0.023s

[Andre Eisenbach]

Compile time of 0.3s, huh? :)
Sorry you had to wait that long :p

Next time:

"time make -s -j 20" ;)

[Andre Eisenbach]

Yes, absolutely.

The idea really is to make everything as modular as possible.

I can already see a problem with the way I implemented the pilot status reading. Porting to the Hydra setup would be a good incentive to clean that up and refactor.

However, still lots to do just to get it to stock firmware parity first....

Also my hope is once I get the "normal" work done and focus on modularization, the code will be clean and easy and allow others to port it easily as well.

[Andre Eisenbach]

One more patch posted...

[Danny ter Haar]

On Tuesday, April 21, 2015 at 10:55:56 AM UTC-7, Andre Eisenbach wrote:

One more patch posted...

Compiled and uploaded to my V3 openevse.

I am filming while my wife plugs it in the car (time: 5 seconds of the movie)

At 9 seconds you hear the car engage the contactors

at 10 seconds the openevse contactor is engaged

but the display doesn't change to "charging"

and after a timeout it resets....

https://www.youtube.com/watch?v=gQa_XLlpgbw 

[Andre Eisenbach]

Getting weirder!!!

The watchdog timeout is 8s. So, if it is a watchdog timeout, something is happening 8s before the reset.

The status doesn't seem to change to charging, so it's not the current sensing algorithm.

Hmm.... Will have to debug when I get home...

[Andre Eisenbach]

Oh, I turned the sound on and the relay is clicking. So it is entering charging state. But crashing even before the display updates!

[Andre Eisenbach]

Btw, after the reset, did it start charging, or is it a reboot loop where it resets every time 8s after "click"?

[Danny ter Haar]

On Tuesday, April 21, 2015 at 2:54:19 PM UTC-7, Andre Eisenbach wrote:

Btw, after the reset, did it start charging, or is it a reboot loop where it resets every time 8s after "click"?

Luckily not, because after the reboot it is back to 40 amps which would fry my wires.

The reason it is not charging is that my car is set to timed charging only.

So I manually have to override it to "start charging immediately" every time I want to try it.

That is in this case a nice safety feature ;-)

 

[Andre Eisenbach]

You can change the default AMPs in evse/state.cpp

I'll set it to 16 by default tonight as well though.

[Danny ter Haar]

On Tuesday, April 21, 2015 at 4:05:09 PM UTC-7, Andre Eisenbach wrote:

You can change the default AMPs in evse/state.cpp

I'll set it to 16 by default tonight as well though.

Thanks , will do

Btw: 

The movie I posted happened twice in a row.

I just compiled with the latest patch " One more optimization to square_root() and minor re-factoring..."

will flash and try again ;-)

[Danny ter Haar]

On Tuesday, April 21, 2015 at 4:05:09 PM UTC-7, Andre Eisenbach wrote:

You can change the default AMPs in evse/state.cpp

I'll set it to 16 by default tonight as well though.

I changed it to 26 to know it is "my version" ;-)

I started without problems this time.

It showed 9 amps charging for the time my car actually waits/checks before ramping up.

NoSpark showed at some point amps going down to 4 amp, and then went up and stopped at 27.

The display at my EV showed 25.9 

At least now, when/if a powercycle happens I won't trip breakers and/or smell molten wires ;-) 

[Andre Eisenbach]

Cool!

1 amp over is fine. Likely line losses etc.

But is it still reading way over (44A) sometimes??

[Danny ter Haar]

On Tuesday, April 21, 2015 at 6:47:44 PM UTC-7, Andre Eisenbach wrote:

Cool!

1 amp over is fine. Likely line losses etc.

 

I will probably need to calibrate my setup ;-)

 

But is it still reading way over (44A) sometimes??

Not with the last time, but I am still wondering why there is 0.01 amp flowing the display reads 9 for about 6 seconds,

than the display goes down as my EV starts to pull amps and then it finally syncs up with real life (TM)

[Andre Eisenbach]

Development update 6

Since the last development update, the following features have been implemented:

- Current measurement

- kWh accumulation and display on the LCD

- EEPROM stored settings (currently max. current only)

Based on a comprehensive survey of all current NoSpark user ;), it was determined that it was time to move the maximum charge current to the EEPROM for safety. The default current is now 16A until it is set in the settings. The EEPROM settings are stored as a binary blob, which should make the storing of additional settings in EEPROM easy down the road.

For the current monitoring, a new "ChargeMonitor" class has been created which tracks charge time, current etc.

Here is a quick video of the charge current/kWh display in action:

https://www.youtube.com/watch?v=sZdj9VRxPws

Known issues

- There is an issue with NoSpark hanging/crashing sometimes when the charge plug is removed. This is not very consistent and thus a bit hard to fix. I hope this is not caused by a current surge in the controller and instead is a simple programming error.

Upcoming features

- Export charge data on serial port

- Adjust time/date in settings

- Charge timers

- "stop charge" button

+ more (thought of a cool feature)

Current resource usage

   text    data     bss     dec     hex filename

  16306     250     507   17063    42a7 obj/NoSpark.elf

   text    data     bss     dec     hex filename

  16306     250     507   17063    42a7 obj/NoSpark.elf

Some questions:

- Should I keep updating thread in this way or reduce the number of update and post a new thread per update instead?

- I think all the "basics" for normal operation are now in place. Which feature is the most "necessary" for a Version 1.0?

[Andre Eisenbach]

Development update 7

I'm happy to announce "NoSpark v0.04"!
This has a big bug fix in it that fixes the watchdog timer when unplugging the device.

With that bug out of the way and all the main features in place, this should be a fully functional EVSE charger firmware!

Other updates/fixes in this release:

- End-of-charge display showing kWh and charge time after the charge ends

- Maximum current is now saved in EEPROM when set via serial console

- Added the ability to set fuses via "make fuses"

- Set EESAVE fuse to keep the EEPROM from being erased when uploading new firmware

Current resource usage

   text    data     bss     dec     hex filename

  16200     236     510   16946    4232 obj/NoSpark.elf

And, for the first time....

HEX file available here:

https://github.com/int2str/NoSpark/releases/tag/v0.04

NOTE: USE AT YOUR OWN RISK. ABSOLUTELY NO WARRANTY OR LIABILITY ON MY PART!

[Andre Eisenbach]

Development update 8

Yet another NoSpark release :)

v0.05 is out which adds kWh statistics.

Video:

https://www.youtube.com/watch?v=x6GfJjRR9Fc

Figured I'd release this one early since NoSpark charges well now and it's good to keep track of the "odometer".

Stats have been added for the week/month/year and overall. Single press the button to go through the stats. Press & hold gets you into settings as usual.

Also added a 15min LCD sleep timer. So don't be alarmed if the LCD turns off on you.

Any event (plugging in car, removing plug, charge complete etc.etc.) will wake the screen or reset the timeout. A single button press will also wake the screen.

Current resource usage

   text    data     bss     dec     hex filename

  17672     252     515   18439    4807 obj/NoSpark.elf

Resource usage has gone up a little, but largely due to the amount of strings added.

Note that I have not done "string optimization" yet and duplicate things like "This" a lot.

Overall, still enough room to grow. We have filled about half of the available space now.

Finishing more of the Settings will probably take the biggest chunk since again, there will be more strings.

Download

Source:

https://github.com/int2str/NoSpark

HEX file:

https://github.com/int2str/NoSpark/releases/tag/v0.05

[Danny ter Haar]

On Sunday, April 26, 2015 at 4:30:41 PM UTC-7, Andre Eisenbach wrote:

Development update 8

Yet another NoSpark release :)

v0.05 is out which adds kWh statistics.

Am trying 0.05 out tonight with my car !

Looks very slick ! 

[Danny ter Haar]

On Sunday, April 26, 2015 at 4:30:41 PM UTC-7, Andre Eisenbach wrote:

Development update 8

Yet another NoSpark release :)

v0.05 is out which adds kWh statistics.

*nice*

Also added a 15min LCD sleep timer. So don't be alarmed if the LCD turns off on you.

Looks scary but is a nice feature !

 

Any event (plugging in car, removing plug, charge complete etc.etc.) will wake the screen or reset the timeout. A single button press will also wake the screen.

I was charging my EV, at setting of 26 amps. 

I unplugged and plugged in again.

And this is what happens next:

While my car is still thinking about it, the amp meter shows 70+ amps.

and then when it finally starts drawing power, it shows only 1 amp

I have been getting "strange" readings with the experimental official branch of the openevse software as well , regarding to the amp meter reading. 

I am starting to wonder if this is a hardware issue.

 https://www.youtube.com/watch?v=EJiXivQyc5k

[Andre Eisenbach]

On Monday, April 27, 2015 at 9:23:26 AM UTC-7, Danny ter Haar wrote:

Also added a 15min LCD sleep timer. So don't be alarmed if the LCD turns off on you.

Looks scary but is a nice feature !

Do you think the LCD should stay on while charging?

Torn on this. Also couldn't find how prevalent burn-in is on LCD displays.

I have been getting "strange" readings with the experimental official branch of the openevse software as well , regarding to the amp meter reading. 

I am starting to wonder if this is a hardware issue.

NoSpark essentially uses the same code to read the current, even uses the same default calibration value.
Only difference is NoSpark uses a continuous moving average vs. a 32-sample average on the OpenEVSE firmware. But that should not change the display much. So yes, you should see the same thing on NoSpark as you see on OpenEVSE. And yes, I'd be double checking my wiring and making sure you have the correct current sensor.

[Danny ter Haar]

On Monday, April 27, 2015 at 10:44:07 AM UTC-7, Andre Eisenbach wrote:

Do you think the LCD should stay on while charging?

Best of course: make it configurable.

I would like it to stay on while charging because it provides info about amps etc.

But when "standby" , I see the LED of the button to know there is power, and the display can turn off.

 

Torn on this. Also couldn't find how prevalent burn-in is on LCD displays.

I doubt it much in these displays ;-)

 

I have been getting "strange" readings with the experimental official branch of the openevse software as well , regarding to the amp meter reading. 

I am starting to wonder if this is a hardware issue.

NoSpark essentially uses the same code to read the current, even uses the same default calibration value.
Only difference is NoSpark uses a continuous moving average vs. a 32-sample average on the OpenEVSE firmware. But that should not change the display much. So yes, you should see the same thing on NoSpark as you see on OpenEVSE. And yes, I'd be double checking my wiring and making sure you have the correct current sensor.

It is not always doing this, just before I took this movie it _was_ charging and showing 26 amps like it is supposed to.

I will try and finish a second V3 build today, so I will have different hardware to compare stuff ;-)

Life is Good (TM) ;-)

 

[lincomatic]

Burn-in is not an issue, so and the LCDs draw very little power, so the only use for blanking is if the user doesn’t like having a continuous bright display in their garage.

[Andre Eisenbach]

Development update 9

You can now set time & date from the settings menu!
Everything currently implemented in NoSpark should now be working as expected.

I've also spent a little time reducing compile size a little. Not because I needed to (still around 15kb left), but just checking for obvious "hogs". And I found some...

Changes since v0.05

- Set time & date from settings

- LCD only turns off in state "A" (not connected)

- Change kWh statistics roll-over behaviour

- Compile size reduction

Not sure what to focus on next.

Bluetooth data download maybe?

[Danny ter Haar]

On Friday, May 1, 2015 at 3:09:27 AM UTC-7, Andre Eisenbach wrote:

Development update 9

You can now set time & date from the settings menu!
Everything currently implemented in NoSpark should now be working as expected.

Great !

Compiled and will run it tonight to charge my car 

Not sure what to focus on next.

a)

 v1/v2 hardware support

b)

 timer support 

People like me with Time-of-Use from their utility company want to only charge between eg 10pm and 8 am.

Set the car to  "charge directly when plugged in" and let the EVSE do the rest with the timer

c)

related to b)

 Help stupid cars like my rav4ev to be able to manipulate the proximity signal like lincomatic has done in the openevse software:

When my car is set to charge using his timers, it assumes everything under 30 amps to be 120 volt instead of probing for 240. So it starts way to early meaning it might actually start outside ToU time frames.

When the EVSE doesn't start charging/pilot signal because it is on a timer, the car tries and tries, activates the internal contactor for the HV battery and starts to draw 700+ watts from the battery pack while waiting for the chargers to kick in.

With an additional hardware hack (described below) we can invalidate the proximity signal so my brain dead car won't even attempt to start charging and thus depleting the battery.

#define SLEEP_STATUS_PIN 12

in open_evse.h.

Pin 12 in Arduino parlance refers to pin PB4/MISO/PCIN4 on the MCU. It’s

pin 1 on the 6-pin ISP header.

If SLEEP_STATUS_PIN is enabled, the pin will go HIGH when the EVSE is sleeping and LOW otherwise.

You can use this pin to drive the proximity circuit.

See original openevse source.

Bluetooth data download maybe?

d)

How about implementing the RAPI interface of the official openevse project  ?

 

[lincomatic]

1)      Make sure your safety checks are all doing what they should in terms of retries/timeouts, etc. Also, make sure to add any extra checks mandated by UL (see my UL_XXX defines, or I can discuss w/ you)

2)      RAPI?

 

From: open...@googlegroups.com [mailto:open...@googlegroups.com] On Behalf Of Danny ter Haar
Sent: Friday, May 1, 2015 8:57 AM
To: open...@googlegroups.com
Subject: Re: Announcing: "NoSpark" firmware project

 

On Friday, May 1, 2015 at 3:09:27 AM UTC-7, Andre Eisenbach wrote:

Development update 9

 

You can now set time & date from the settings menu!
Everything currently implemented in NoSpark should now be working as expected.

 

Great !

Compiled and will run it tonight to charge my car 

 

Not sure what to focus on next.

.

[chris1howell .]

I second the RAPI nomination. It would be very cool if external apps developed were compatible with both firmware without modification.

[chris1howell .]

Lincomatic beat me to it... I third the RAPI nomination.

I am working on a new testing guide, that goes into detail validating each safety feature. Hopefully this will help developers validate firmware and hardware mods...

[Danny ter Haar]

On Friday, May 1, 2015 at 3:09:27 AM UTC-7, Andre Eisenbach wrote:

Development update 9

I just pulled the last patches and it compiled without problems.

But it just loops the begin animation over and over again.

It never checks the relay or anything.

Seen this before ?

 

[Andre Eisenbach]

Nope.

Can you flash it again with verify enabled to make sure the flash is good?

Does it reboot immediately after the beginning animation or is there an 8s delay before it shows it again?

[Danny ter Haar]

On Friday, May 1, 2015 at 8:46:20 PM UTC-7, Andre Eisenbach wrote:

Nope.

Can you flash it again with verify enabled to make sure the flash is good?

That is standard in my setup afaik.

 

Does it reboot immediately after the beginning animation or is there an 8s delay before it shows it again?

constant loop, no delay

 

video   https://www.youtube.com/watch?v=aWYZ4OQWAYI

after this I typed :

make, did nothing.

Programmed & verified the image to the openevse hardware:

and of course it "just worked"

Jeez....

[Andre Eisenbach]

So it's working now?!

Btw. are you loosing the EEPROM content every time you program?

If you do, do "make fuses" once and then upload again as normally. You won't loose the EEPROM content anymore.

[Danny ter Haar]

On Saturday, May 2, 2015 at 10:25:59 AM UTC-7, Andre Eisenbach wrote:

So it's working now?!

yeah!

 

Btw. are you loosing the EEPROM content every time you program?

don't think so.

 

If you do, do "make fuses" once and then upload again as normally. You won't loose the EEPROM content anymore.

will try and let you know.

It successfully charged my EV again last night ;-)

[Andre Eisenbach]

Development update 10

Alright, because some people asked and a lot has happened since update 9 (around NoSpark v0.06), I will give another (final?) development update:

NoSpak has made tremendous progress since update 9. It's been charging my car well for many cycles now and has added quite a few features as well.

Since there's too much changed for me to list, let me direct you at the highlights:

LCD sleep mode clock

Somewhere around 0.07 the ability was introduced to configure what your LCD does after a 15min idle timeout. It can either do nothing (stay always on), turn off or act as a wall clock, showing a large font clock. Since the OpenEVSE is permanently mounted in my garage, this has been a nice feature for me. Here's a quick video showing the settings & feature:

https://www.youtube.com/watch?v=qgaX9ag6rEM

kWh limiting and charge timer

I get to charge for free at work. So every kWh that I charge before going to work is "wasted" for me. But, I do need to make sure that I have enough juice in the battery to make my commute. So, a feature was added to add a per-charge kWh limit. So after charging 10kWh for example, charging is suspended. This may also be useful for EV owners with battery backed solar panels etc.

And, since charge suspending now works with NoSpark, I added the charge timer feature in as well.

Both features will show an icon on the main charging screen and also have API support. Speaking of.....

Serial API support

As you may have noticed, I've been having a lot of fun playing with Bluetooth and the new serial API in NoSpark:

https://groups.google.com/d/msg/openevse/k5TCAskKgpY/QFFzB5OpS9MJ

No, the API is not compatible with OpenEVSE right now.

Cost per kWh support

This feature allows you to set an average cost per kWh and will automatically add the total price to the kWh statistics as well as the in-progress charging screen.

To make this work on the 16x2 display, scrolling text has been added. Here's a demo of the feature including the settings:

https://www.youtube.com/watch?v=ZJ89OCU32qs

Bug fixing

A bunch of bugs were squashed including a HUGE one that would prevent the GFI from working past the self test. This is obviously a huge issue. So if you're running a pre v0.09 release of NoSpark, please update immediately.

The GFI is now checked every time before closing the relay as well.

General development

Overall, the code has been simplified in some areas, removing unnecessary singletons etc. To make the scrolling text work, the code moved from direct lcd/uart access to a new OutputStream class and stream based approach. Some code size reductions have been made, however, all these efforts were eclipsed by the addition of the serial API and additional strings etc.

Unfortunately NoSpark is now up to 25k. The good news is that it's largely feature complete at this point and I can't even think of anything left to add right now. The bad news is that many of the recent feature additions really pushed the size more than expected. Going forward, I'll make another few passes to see where the biggest size offenders are hiding and will try to trim a bit more. But of course, code readability etc. still trump compiled size at this point, so I won't sacrifice that just yet ;).

Features

- Charge controller

- Temperature monitoring + charge rate back-off on over-temperature

- Ammeter monitoring

- Charge scheduling

- Per-charge kWh limiting

- Cost per kWh feature

- LCD sleep mode including "wall clock" mode

- Multi language and currency support (in it's infancy)

- Serial console and serial API (concurrently)

Source code etc. is available here:

https://github.com/int2str/NoSpark

Binaries are available here:

https://github.com/int2str/NoSpark/releases

I don't post updates anymore and have not posted them anywhere else, so the best way to keep up with NoSpark is probably to check the github site.

[Danny ter Haar]

On Thursday, May 14, 2015 at 12:33:42 PM UTC-7, Andre Eisenbach wrote:

Development update 10

Wow, that is certainly *impressive* 

One man army at work ;-)

Is it relatively simple to add support for the relay output as used in v1-v3 openevse hardware so it can used on other hardware apart from the V3 with contactor as well ?

[Andre Eisenbach]

Thanks Danny!

Yes, I think I can add support for the 12V relays pretty easily.

Hate to check in code that I can't really test, but I'll give it a shot.

[Craig Kirkpatrick]

Andre, I encourage you to keep updating us here.  Your project is at 90% you think?  Keep us updated and maybe I'll find time this weekend to test it thoroughly.  Also I have both v3 contactor and v3 relay systems to test upon.

[Craig Kirkpatrick]

I flashed my OpenEVSE v3 on the bench.  This is the one with relays so I had to work around that missing but I did.

I admire your eye for design.  I like the menus.  I really like the quick button press to review consumption per week, month, year, and lifetime.  That was clever and I dreamed of doing that but had nowhere near the skills you have in coding things.  I also admire the user-entry of $ per kWh and display of both $ and consumption - and international currency units was clever too.

The very minor criticism is that the scrolling looks more like a blinking display.  I do not know if there is a way to simply slow down the scroll rate or some other method but the scrolling bugs me.  That is just my opinion for what little it is worth.  I see the value in the scrolling.  Just visually it bothers me.

I'm excited to try it on my OpenEVSE v3 contactor that charges my Ford Focus.  That way I don't have to "work around" the relay error I ran into on my 30A OpenEVSE relay kit on the bench.  It will be interesting to see the amperage calibration you have and overall behavior with a real EV instead of my simulator.

I do not need the charge limit feature but that was super clever of you and I can see how a portion of OpenEVSE users will find that very valuable.

I don't even use delay timers on the OpenEVSE code so I haven't really used any of that ever.  I can set delayed charge for my Fords from an app on my iPad that the cars obey thanks to Ford.

I like that you adopted the idea of over-temperature monitoring for safety.  Cool, stay cool, and stay safe.

I'm and old dude getting back into C after being away for too many years.  I need to setup the GCC compiler so I can do a better job working with your code than just consuming your hex files.  Any pointers for a GCC noob like me will be appreciated.  I'm not asking for you to spend more than five minutes, just if you know of anything you can point me towards that I can follow it will save me a bunch of push-ups.  Thanks.

Congratulations on a very functional software written from the ground up!  I remember when you first appeared here I thought you were completely joking or some internet troll.  You proved you are more than capable.  Very good.

-Craig K

[Andre Eisenbach]

Thanks for testing and the feedback!

I totally agree on the scrolling part. Bugs the heck out of me. I think the overall problem is the frame rate. I think either the LCD refresh is not happening quickly enough (likely) or the LCD just can't handle updates at that rate. Either way, I think one of my next steps is to try to speed everything up a bit again to get the refresh rate up. I think that that will make it scroll much smoother. Also might experiment with double-buffering or not redrawing the whole screen every time. Not sure yet.... But yes, I'll fix that...

For the week/month/year stats, I think I'll actually change the way the data is stored a bit. I might store the last 52 weeks instead and then accumulate on the fly. That way I might be able to draw a bar graph even :).

Anyway, tons of fun playing with this :)

[Craig Kirkpatrick]

I wasn't sure from your description that I would like the big clock after idle for 15 minutes. But I do have to say now that I love it. I need to study how you customize the display since you know something about the LCD controller that I surely do not know. Nifty to say the least.

[Andre Eisenbach]

Btw. the "SCK" pin on the ISP connector has a "heartbeat" that will toggle once for every main loop iteration. I think it's as low as 8 Hz right now. You should be able to see that on your scope or multi-meter. I'd like to get that over 10-15 again...

[chris1howell .]

I too hope you keep posting updates. You UI is very impressive. I am looking forward to seeing updates no your App as well...

I will send you a v2.5 board to play with. Adding support should be simple just bring 2 more pins the the same state as the current AC_relay pin. Really nothing to 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/d/optout.

[Danny ter Haar]

On Thursday, May 14, 2015 at 12:33:42 PM UTC-7, Andre Eisenbach wrote:

Development update 10

Hi Andre

I synced, compiled and flashed v0.12 today and when I power it on, I see the great graphical intro and then a red "GFI ERROR" screen.

I then downloaded your hex file: same behavior.

To make sure it is not a hardware issue, I synced/compiled lincomatics 3.7.9 development branch software and uploaded it:

That seems to work just fine.

Any idea how I could debug why NoSpark is giving me the GFI condition ?

btw: I ordered a couple of HC-06 so I should be able to use wireless serial console soon-ish "Estimated delivery Wed, May 27 - Wed, Jun 10" ;-)

[Nick Sayer]

Andre, can you fill in a little on how you’re doing (if you’re doing) the GFI self test? Is that, perhaps, the error he’s seeing? I’d have to assume it has something to do with the GFI self-test, since Danny is not reporting that it’s happening after charging begins.

If the message is indicative of a GFCI fault rather than a self-test error, then it’s conceivable that this is the peak-hold cap outlasting the delay-after-test-end.

On May 15, 2015, at 9:43 PM, Danny ter Haar <from...@gmail.com> wrote:

On Thursday, May 14, 2015 at 12:33:42 PM UTC-7, Andre Eisenbach wrote:

Development update 10

Hi Andre

I synced, compiled and flashed v0.12 today and when I power it on, I see the great graphical intro and then a red "GFI ERROR" screen.

I then downloaded you hex file: same behavior.

To make sure it is not a hardware issue, synced/compiled lincomatics 3.7.9 development branch software and uploaded it:

That seems to work just fine.

Any idea how I could debug why NoSpark is giving me the GFI condition ?

btw: I ordered a couple of HC-06 so I should be able to use wireless serial console soon-ish "Estimated delivery Wed, May 27 - Wed, Jun 10" ;-)

--
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/UQZl2vjyC8M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openevse+u...@googlegroups.com.

[Andre Eisenbach]

Nick,

The GFI test sends 50 pulses every 8.333ms.

Then tries to wait for the pin to go low again and then waits an additional 300ms.

You can see the code here:

https://github.com/int2str/NoSpark/blob/master/board/gfci.cpp

Danny,

I've uploaded an additional delay based on what nick wrote in other threads about the peak hold cap.

Can you pull the latest code and try again?

Thx

[Danny ter Haar]

On Friday, May 15, 2015 at 11:26:17 PM UTC-7, Andre Eisenbach wrote:

Danny,

I've uploaded an additional delay based on what nick wrote in other threads about the peak hold cap.

Can you pull the latest code and try again?

Thx

 -#define GFCI_RESET_DELAY_MS  300

+#define GFCI_RESET_DELAY_MS  500

No change, still GFI error after POST , no EV attached

My first EV charged tonight without a problem with the "official" 3.7.9 code

So if there is an GFI condition, that code is not picking it up or your code is over sensitive ;-)

[Danny ter Haar]

Andre,

your "Relax GFI check even more; only trigger on rising edge" change made it work again on my hardware.

I have been running your versions on this hardware for a long time. 

But have been flashing it back and forth to the "original openevse" firmware as well.

I am pretty sure I had NoSpark v0.10 succesfully running at one time.

But I went back from version v0.12 down to 0.09 and it would give me the GFI error after POST.

Could it be that there is/was some "old data" in NVR somewhere that would trigger this behavior ?

Kind of as a last resort I pulled the latest version, compiled it and low and behold: 

It's working. was able to set amps, timer and will use it tonight to charge at least one of my EV's .

I think it is kind of weird it was working, and wouldn't work now with same old version.

Anyway, thanks for whatever you did.

Made it work again at this end. Will keep you posted

[Danny ter Haar]

On Saturday, May 16, 2015 at 7:05:43 PM UTC-7, Danny ter Haar wrote:

It's working. was able to set amps, timer and will use it tonight to charge at least one of my EV's .

 Will keep you posted

My first EV charged on it's own timer and went to 8x% full 

Got message and switched to second EV.

Charge session was ended by NoSpark at 8am like it was supposed to.

thanks all involved for great hard & software  !

[Ragnar Þór Valdimarsson]

Interesting.

I like what you are doing.  I will follow your work and offer contribution if needed.

I am a professional software engineer, using electrial design as a hobby and fun.

I have developed a very simple serial comunication API between openevse and another micro controler boards.  I use Arduino Nano.

I find the serial API very important and found it to complex to use in the current openEVSE project.

I have not yet published my source open as I like to do more testing.  It is however doing well on 5 station I have built

I like to have one module for the basic controller which would be the core including all safty features (Ground Check, GFCI, Dioad check, Relay check)

Other modules would contain user features using serial API for communication.

Hope you do well.  Good luck.

Ragnar

On Tuesday, 24 February 2015 10:19:39 UTC, Andre Eisenbach wrote:

Meet NoSpark, an alternative firmware for the OpenEVSE board, written from scratch.
NoSpark aims to be a drop-in replacement for the existing firmware, developed in C++ for the AVR microcontroller.

Why develop NoSpark?
- AVR C++11
- No Arduino libraries/build dependencies
- Uses "make" build system
- Modular design
- Lightweight
- Why not?! That's what having an open source EVSE is all about :)

There are no fancy features planned for the initial version.
It will simply be a drop-in replacement to perform the basic functions:
- Charge state management and pilot generation
- Fault checking & relay control

- Current measurement
- LCD user interface & button menu
- Persistent settings (EEPROM)
- RTC control
- Serial console (+Bluetooth dongle)

The purpose is to get a nice modular framework up and running first.
Since I fully expect to have flash space left over after implementing the basics, there will be room for more advanced features down the road.

It all starts today, with an empty git repository...
https://github.com/int2str/NoSpark

I am not looking for contributions at this point, since I'm still tinkering with many of the details.
But of course, down the road I will open up the project to any contributions. And comments and criticisms are always welcome, especially as the program takes shape.

I will update this thread as things develop so you can follow along as "NoSpark" takes shape or goes up in flames :)

[Andre Eisenbach]

Development update 11

NoSpark is at a stage where all features are essentially in place and I'd consider it a "complete" firmware. It does everything it's supposed to do and all the things I [currently] want it to do. Firmware size hovers around 26k currently with about 1k of RAM used (+dynamic allocations). So overall things are good. However...

With the modular, event based approach, the main loop was starting to slow down. While idle, the main loop was executing about every 62.5ms, while charging (and reading the Ammeter), this would drop down to as low as 84ms per loop. What that means is that worst case if you pull out the plug at the right instance or a safety issue would occur, it could take up to 85ms until the command to shut off the relay was even sent, let alone the relay be shut off. Not good.

The main issues are that sampling the analog-to-digital converter takes time. Not just the time to read it itself (the atmega328p can do this in 12us or faster), but that you actually need to read enough to get the whole 50/60Hz sine wave for the ammeter or 5-10 cycles of the 1kHz wave of the J1772 pilot to get useful data out of it. And you cannot do both at the same time. Reading the J1772 pin takes about 11ms, reading a sine wave for the ammeter around 25ms. So, 35ms just for that. Then update the LCD, read the serial port, read the time, check charge timer, etc. etc.

Interrupts to the rescue! The AVR microcontroller has an analog-to-digital converter (ADC) interrupt that can let the main program know when a reading has completed. Furthermore, the interrupt routine can also do the boring things like monitoring the J1772 for a few cycles and add up the values for the ammeter etc. And it can be "multiplexed" to alternate between reading the J1772 and the ammeter.

Long story short, NoSpark v0.13 now does interrupt driven ADC reading. This un-blocks the main thread to do all the other good stuff and means that currently the main thread executes at least once every 50ms and often much faster than that. On the bench I got down to 20ms per update in some conditions. The 50ms rate is much better than before, but there might still be room for improvement there. The I2C code might be the biggest hold-up now and maybe I can reduce how often the RTC is queried for example or optimize other code further. But for now, things are chugging along nicely.

Another minor addition is the ability to use the "backspace" key in the serial console. This makes using the serial console a lot nicer in my opinion. Small change, big usability impact.

At this point the serial API is still lacking checksum support. Also some of the UI features need a timeout (Settings auto closes if you're idle, but some of the other pages do not) and I'm not super happy with the scrolling text yet, so I might revise the UI a little more.

But otherwise, I'm nearing "1.00" status rapidly and can't think of any more cool features at this point.

If you have any, suggestions/comments/criticisms, let me know.

And yes, I'll work on 12V relay compatibility soon.

Also the Android app has been working great. I've not had time to really work on it though. So don't hold you breath on updates for that one :)

Release v0.13 is available on Github as always:

https://github.com/int2str/NoSpark/releases

[Ragnar Valdimarsson]

I just clone the repository and plan to compile it and look into it tomorrow.

Do you have any preferred Development environment or just plain vanilla emacs and make files.  I use Eclipse most of the time as most of my work is in java.  I have use the Arduino plugin and it is fine.  The c++ support is also very good.

Thanks,

Ragnar

[Andre Eisenbach]

Emacs?!!11!

Vi all the way :p

But yes:

make

make upload

See Makefile.inc to set it to what programmer/serial port you're using.

make will work as long as you have avr-g++ etc. in your path. I am successfully using it on Linux, MacOS and Windows (cygwin).

[Ragnar Valdimarsson]

:)  I am now developing on MacOS.  I will compile it and upload.  Perhaps I should first just upload your hex file.

I let you know how it goes.

[Alan Kirk]

Great writeup! I greatly enjoy your detailed and well written descriptions.
Any chance you'd publish your Android App?

[Danny ter Haar]

On Sunday, May 24, 2015 at 7:30:51 AM UTC-7, Alan Kirk wrote:

Great writeup! I greatly enjoy your detailed and well written descriptions.
Any chance you'd publish your Android App?

Just a place to download the .apk would be very much appreciated  

[Ragnar Valdimarsson]

compiled code with make and got the hex.

uploaded it to one of my openEVSE board with my USBAsp programmer.

Got expected GFI test failure when I did not have the coil plugged.

Plugged in coil and display showed 

00:00 17 | 16A

ERROR

I had the mono no clock display plugged in.

Code certainly looks modular and well designed.  I have only skimmed it and as a software developer I like how it is structured.   

What next?   I have not connected contactor or relay.  Should I connect a contactor and even plug it to my experimental kit which I use to test charging my car with openEVSE.  At what stage is the software?  Do you expect it to work if I connect a button and try out configuring settings and even try charging my car with my development kit, or is the software still in preliminary stage and not yet functional for experimental usage.

 At least the code is in my opinion very well written.  I just don’t know if it this version is expected to work or if it has not yet reached that state yet.  

If you like me to do some testing, reviewing of source, or any other work you think is helpful, I am happy to do so.

I have not spent much time yet on this.  I just skimmed code, compiled it and uploaded, so my knowledge is limited.  I did however create an Eclipse c++ project and can use the environment for code completion, jump between methods with one mouse click and quickly get the code structure in my head.  I am used to work on very large higher level projects (over millions of lines of code and hundreds of libraries) therefore I always take as much advantage of development environment as possible.  I realise that micro controller programming is different, with lower level code and therefore tools not as important.  But I find it easier for my to get code structure in my head when I can use tools like Eclipse where I can see all references to functions and dependencies with a mouse click.

Let me know if I can be of any help.  Nice job on separation of modules.  I really like it.  I know that original electrical engineers usually do not go this way, but create one large file with sequential code.

All the best,

Ragnar

On 24 May 2015, at 00:33, Andre Eisenbach <int...@gmail.com> wrote:

[Craig Kirkpatrick]

Ragnar, on the bench without the built and tested configuration of contactor and RGB LCD I found I could play with the software with an EV simulator by putting the simulator in state C and then powerup the EVSE. That got me past the boot self test error where NoSpark wants to test the contactor.

I think fully build OpenEVSE v3 with contactor is fully tested by Andre and is working to charge his EV.

[Ragnar Valdimarsson]

thanks.

In that case I will continue and plug in a contractor and do some playing around. My test board is V3. Perhaps try to charge my EV if I get to the stage if all goes well.

Thanks,
Ragnar.

> On 24 May 2015, at 22:24, Craig Kirkpatrick <crai...@comcast.net> wrote:
>
> Ragnar, on the bench without the built and tested configuration of contactor and RGB LCD I found I could play with the software with an EV simulator by putting the simulator in state C and then powerup the EVSE. That got me past the boot self test error where NoSpark wants to test the contactor.
>
> I think fully build OpenEVSE v3 with contactor is fully tested by Andre and is working to charge his EV.
>

[Andre Eisenbach]

Yes, NoSpark is fully functional.

So if you have the 50A kit (v3 board, RGB LED + RTC, contactor) it should work great.

If you press & hold the button you can set the time and settings on the LCD. The 16A limit is standard, you can raise it in the settings. Also, if you want, the serial console should work (connect at 57600, press enter a few times, you should see the "nospark>" prompt; type "help"). Serial API is also enabled by default.

[Andre Eisenbach]

If you want to check in the Eclipse project or any changes you had to make it work, send me a pull request.

Btw. I also just commited a ninja build file.

With that, code compilation is even faster (and that's on my Windows machine):

$ time ninja
[56/56] HEX NoSpark.hex

real    0m0.960s
user    0m0.301s
sys     0m0.647s

For comparison:

$ time make -s -j 10

real 0m1.890s
user 0m1.264s
sys 0m3.024s

The Makefile won't go away yet though since I still have to keep a way to upload the file.

Also, the build.ninja file is hard-coded right now. I'll look into "gn" next.

[Andre Eisenbach]

Development update 12

Ok, hate to update this frequently, but NoSpark has hit another milestone I'd like to share and get feedback on - DC relay support.

If you download NoSpark v0.14 (https://github.com/int2str/NoSpark/releases/tag/v0.14; or later), you should now be able to use it with your OpenEVSE 2.5 board.

Note that this is completely untested since I don't have the hardware.... I *hate* to release this untested like this, but you guys asked, so here it is...

Let me know if it works for you.

In addition to the Ninja build system support, I've also added a serial console command ("energy") and serial API command ("$E3") to read the energy statistics.

[Ragnar]

I have one v2.5 board  I will upload the firmware and connect 12v relays and give it a try. 

Sent from my iPhone

--

[Ragnar]

I will send a push request tomorrow. I'm not sure if the eclipse env. Is for interest for others.  I will make it clean and separated in another folder.  It's just some minor config and perhaps personal preferences for dev env. Should not be part of the repository. But if you like to include it, I will keep it upto date.   I like the nija build file.   I still think the plane old make file must be supported as well.  

It always gives comfort feeling to just run make and all works.  This is one of the many things that impressed me with your project.  

Keep up your good work.  The code is exceptionally well written.  

Sent from my iPhone

[chris1howell .]

Andre,

You do have access to the hardware, the v3 board has both AC and DC relays on the board.

Chris

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.

[Craig Kirkpatrick]

Andre,

I have a v3 controller with relays.  I loaded NoSpark and have done a little bit of testing.

• Enhancement request, let the user set $ to tenth of a cent.  I'd like to set $0.105
  
• I tested the GFCI looping an extra wire thru the GFI coil and touching the wire leads to a battery.  Works as expected and instantly opens the relays.
  
• I pulled the ground connection from the AC mains and booted.  The EVSE says a relay test failed when I should say missing ground.
  
• I find I can connect to my EV simulator in state C with the AC mains ground not connected, it boots skipping the ground check, and then I can go from state C to A and back to C still with the ground still not connected and no error ever thrown about the missing ground.  Take a look at the v3.7.8 and how it handles the ground check continuously during charging.  I think this was something UL required and was changed since January in the OpenEVSE firmware.
  
• I like how you fit so much on the display, showing the clock and the ambient temperature.
• I think you must have made some improvement on the scrolling display since it didn't bug me looking at it this morning.

Keep up the good work.  And ask questions here about the UL required behavior and I'm sure Chris and Lincomatic understand it better than I do and can offer good advice. 

[Craig Kirkpatrick]

I tried the serial console, I get the nospark> prompt, I type help, and it echos back he.  It seems to want to parse only two characters.  I type $E3 and it echos $E.

Double check it still works on your end.  Maybe I have something wrong in my serial setup but I have it working with the other firmware so I am not sure what is the problem.

[Nick Sayer]

> On May 25, 2015, at 8:32 AM, Craig Kirkpatrick <crai...@comcast.net> wrote:
>
> Andre,
> I have a v3 controller with relays. I loaded NoSpark and have done a little bit of testing.
> • Enhancement request, let the user set $ to tenth of a cent. I'd like to set $0.105
> • I tested the GFCI looping an extra wire thru the GFI coil and touching the wire leads to a battery. Works as expected and instantly opens the relays.
> • I pulled the ground connection from the AC mains and booted. The EVSE says a relay test failed when I should say missing ground.

The latest behavior, which I believe is what UL wants to see, is that a ground failure is not actually detected until charging begins. I think the old SPST relay closing behavior at boot has been deprecated. This means no more auto L1/L2 detection (except for OpenEVSE II, which uses the voltmeter for that), but it also means no more electrifying the J1772 connector when it’s not plugged in either.

The AC test lines are supposed to indicate no voltage when charging is not taking place, otherwise it’s a relay test failure. They are supposed to indicate a voltage exists when charging is taking place, otherwise it’s a GMI failure. They should be being polled for one condition or the other continuously.

This is ok because the absence of ground is not unsafe in states A and B. I used to think that early detection of ground failures was beneficial, but Chris changed my mind. The problem is that you should have a way to disconnect the GMI test circuit when a failure is detected, otherwise you wind up with a high voltage between the chassis and *real* ground. That means adding a second small relay just for that… or else powering the GMI from the load side of the contactor, which is simpler, but means being unable to perform GMI in states A and B.


> • I find I can connect to my EV simulator in state C with the AC mains ground not connected, it boots skipping the ground check, and then I can go from state C to A and back to C still with the ground still not connected and no error ever thrown about the missing ground. Take a look at the v3.7.8 and how it handles the ground check continuously during charging. I think this was something UL required and was changed since January in the OpenEVSE firmware.

[Craig Kirkpatrick]

Nick, The one thing I would correct from what you said is that the OpenEVSE v2.5 when set to AUTO detect L1 vs L2 still will cycle the relays to detect that at boot time if the EV is not connected.  Actually the OpenEVSE V3 does it too but really the V3 is for L2 operation.  The V3 left set to AUTO detect L1 or L2 will sense it is L2 since it is designed for L2 operation with either contractors or relays.

I have an OpenEVSE v2.5 relay build I can do some testing upon but it has the mono LCD which could be troublesome for NoSpark testing at this point in time.

[Andre Eisenbach]

Thanks for testing.

The serial console/API is working in v0.14. But I assume you're using the Arduino serial monitor?

If so, I've fixed the problems with that and just uploaded a fix to switch to interrupt driven serial RX. Also switched to CR/LF on the output, so it should all work well now. Set the output to "Carriage return". If you send API commands, you will not get a newline, this is by design.

And yes, I fixed the scrolling a bit. I didn't explicitly change anything in the scrolling code, but I did the interrupt driven ADC change and sped up the number of times the display is refreshed in essence to make the drawing faster. I've also tweaked the I2C and LCD code even further to drive the LCD pretty much as fast as it can be driven. All that helped.

I don't differentiate relay failure modes currently, since the outcome is the same.

I'm also a bit dubious on the "ground failure" error. I don't think that the relay test as is can make judgement about whether a ground is connected or not.

In any case, I'll read what Nick wrote a few more times in the hope of understanding it better :D and then I'll likely rewrite the code based on what he wrote. Sounds like instead of a self test like currently, more permanent monitoring is required.

[Andre Eisenbach]

Understood, but my V3 unit is on the wall, charging my car :D

I just ordered a v2.5 board, am RGB LED and a monochrome display.

I didn't need another unit, but that way I can test the other components and make sure NoSpark is more compatible.

On Monday, May 25, 2015 at 7:51:18 AM UTC-7, Chris wrote:

[chris1howell .]

Craig is correct, set to "Auto" and L1/L2 detection works like before.

Ground detection and Stuck Relay have not changed for UL, in fact UL did not even check GMI as it is not required. The UL changes were GFCI self test at boot and EVERY time before closing the contactor's including after a fault reset.

V3 will always detect L2 as the Mid400 is tied to both inputs.

[Andre Eisenbach]

Actually, DONT'T run the latest code right now.
I introduced a crash bug on the serial code. Will fix shortly...

[Nick Sayer]

Sent from my iPhone

On May 25, 2015, at 11:06 AM, Craig Kirkpatrick <crai...@comcast.net> wrote:

Nick, The one thing I would correct from what you said is that the OpenEVSE v2.5 when set to AUTO detect L1 vs L2 still will cycle the relays to detect that at boot time if the EV is not connected.  

I'm surprised that that is something UL permits. I would have expected them to insist on not allowing the hot lines to be energized when not in a vehicle.

[Craig Kirkpatrick]

I'll let other experts explain how the OpenEVSE and OpenEVSE II detect missing ground on the AC mains side.

The behavior I see with OpenEVSE firmware on V3 with no ground is it boots without complaining, but within a second of beginning charging it detects the missing ground and faults.