Mods for the Blink EVSE ! (was Fix)

My Nissan Leaf Forum

Help Support My Nissan Leaf Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Spies said:
snip ... In the mean time I have just been shutting off power to the unit when I am not charging. Hopefully doing this does not add undue wear and tear to the unit based on its design and perhaps it would be better just to leave the unit powered...
Eventually IMO you could weaken some soldered connections on the boards by heating and cooling, but what WILL wear out is your circuit breaker. They are not "switch rated", meaning they have the duty rating to be reset in the event of a trip, but is never intended to be a "snap switch". If you feel it start to get sloppy or mushy, it needs to be replaced.
 
While we're on the GPL and source request issue. Can everyone contact Ecotality and ask for the source?

I'm regenerating my own QT build, but I'm really interested in theirs to see the mods. My interest list is as follows:
Linux Kernel 2.6.20
BusyBox
QT (if its open source or licensed)
Python
 
From the support email...they asked their superior and they said "that we would not be releasing the source code."

I wasn't asking for source for the whole EVSE, just the open source components with respect to the GPL.
 
whoami said:
From the support email...they asked their superior and they said "that we would not be releasing the source code."

I wasn't asking for source for the whole EVSE, just the open source components with respect to the GPL.

See if you can get that (the decline) in writing.. email or a letter. EFF loves to chase this stuff down. The BusyBox author (Bruce P) in particular will put with none of it. When faced with a formal assertion by the authors and copyright holders, most companies "see the light".

The GPL is not unclear or flexible about these requirements: If you deliver a product with GPL code in it, you must deliver the source code to the end user.
It seems obvious that portions of the Blink firmware are GPL, and they have no choice in the matter but to deliver source code, with redistribution rights, to the owner.

(ie, you must pass on all the rights you had as a developer)

It's not a matter of "more people" demanding source from Blink, but the right person (EFF, a copyright holder, or someone with an interest in enforcing the GPL) making it clear that compliance with the license is required.
 
Rake said:
Eventually IMO you could weaken some soldered connections on the boards by heating and cooling, but what WILL wear out is your circuit breaker. They are not "switch rated", meaning they have the duty rating to be reset in the event of a trip, but is never intended to be a "snap switch". If you feel it start to get sloppy or mushy, it needs to be replaced.
Thanks for the tips however the breaker wearing out is not an issue for me since I am using an actual switch. The Blink replaced my old EVSE and this circuit still has an Intermatic 40 amp timer switch on it and I have been using that. The timer was used to charge off peak back when neither the cars nor the EVSE had timers built in.
 
sdbonez said:
Busybox looks straightforward. http://www.busybox.net/license.html - wonder how they go about proving they're in the Blink, though.
As whoami mentioned in his first post - the entire OS is on a SD flash card. I'm assuming he found evidence of at least the 4 GPL software projects he mentioned (Linux kernel, BusyBox, QT, Python) in his later post. whoami appears to be well versed in Open Source software development. I wonder what his day job is. :)
 
Spies said:
Rake said:
Eventually IMO you could weaken some soldered connections on the boards by heating and cooling, but what WILL wear out is your circuit breaker. They are not "switch rated", meaning they have the duty rating to be reset in the event of a trip, but is never intended to be a "snap switch". If you feel it start to get sloppy or mushy, it needs to be replaced.
Thanks for the tips however the breaker wearing out is not an issue for me since I am using an actual switch. The Blink replaced my old EVSE and this circuit still has an Intermatic 40 amp timer switch on it and I have been using that. The timer was used to charge off peak back when neither the cars nor the EVSE had timers built in.
That's good to hear :)
For other folks, it is possible to have a 2 pole snap switch installed, if that is your wish.
Your friendly union (yes, that was a shameless plug) electrical contractor will fix you right up.
cheers!
 
drees said:
sdbonez said:
Busybox looks straightforward. http://www.busybox.net/license.html - wonder how they go about proving they're in the Blink, though.
As whoami mentioned in his first post - the entire OS is on a SD flash card. I'm assuming he found evidence of at least the 4 GPL software projects he mentioned (Linux kernel, BusyBox, QT, Python) in his later post. whoami appears to be well versed in Open Source software development. I wonder what his day job is. :)
As drees says there is plenty of evidence that BusyBox exists in the Blink. I would be more than happy to provide an SD card image to busybox. This brings me to something else, I have full backups of the SD card for 1.2, 1.3. (just incase). I actually develop on another SD card just to keep things seperate.

You can all guess on my day job but I can confirm one thing I don't work for Ecotality :lol:
 
So, unplugging that top connector does not keep the EVSE from stopping prematurely.

I tried to charge normally, it ran 55 minutes and stopped.
Frustrated and planning to go to bed, I unplugged that connector and restarted the charge with the button in the car
Fortunately I got sidetracked and didn't go to bed, since I just got the email telling me it stopped just about 55 minutes later again.

I just restarted it yet again. Hoping I can get it topped off in the next hour cause now I'm really going to bed.

This tidbit is interested though...it would seem to indicate this particular problem is with the PIC board, not the main blink board...wonder if they can reflash the PIC firmware from the main board.

Looks like I might need to get my L1 EVSE modded to have reliable L2 charging.
 
turbo2ltr said:
Looks like I might need to get my L1 EVSE modded to have reliable L2 charging.

That's my plan...though not sure when a good time is to do it given the unreliability of the Blink unit (which still isn't powered in my case...SDG&E..grrr...)
 
turbo2ltr said:
So, unplugging that top connector does not keep the EVSE from stopping prematurely.
Which connector did you unplug? The 5 GPIO connector or the UART connector?

You have to drive the GPIOs in a certain state to achieve charging. The UART is optional :).
 
I unplugged this one as per the OP.

pic
 
turbo2ltr said:
I unplugged this one as per the OP.

Admittedly, I didn't try charging with the cable unplugged for a full cycle.

It may be that the GPIO inputs, when left floating, will float to a state that disables the EVSE. It should be an easy matter to poke some resistors in the the connector and pull them high/low as needed to keep the unit on.

Of course, you may be right, and maybe the bugs are actually in the EVSE code in the microcontroller!

If they are smart, they have a serial bootloader in the micro to facilitate ISP upgrades, but maybe this is why we haven't yet seen a proper fix!!!

-Phil
 
Thanks for all the great info! The Marvell processor has an ARM5 core. http://www.marvell.com/products/processors/applications/pxa_family/pxa_27x_emts.pdf

Wow, small world! I'm very familiar with the processor in the Blink. I was part of the team that did validation on this processor back in 2002-2003 timeframe. It actually uses the Intel XScale core architecture, which is an ARM 5TE compatible core. I bet that the Linux distro is most likely based on a MontaVista, Wind River, or a Debian ARM distro. I did quite a bit of testing under Linux for the XScale processors. I haven't cracked the case on my Blink to download the contents of the SD card, but I'm betting that some of the WiFi issues I've seen are due to a combination of the older kernel (2.6.20) being used and the WiFi management tools.

Modding the OS image for these is pretty straightforward. Build a new OS image with the same tools in the current image (Python, QT, BusyBox, etc.), then copy over any custom scripts or binaries for the charging hardware. I'm curious to see if all the charging is handled in Python scripts, which would make it very easy to debug. If it is all in Python, then we could add in some code to give us more diagnostic output when the charging fails. We could also add in sshd which would allow remote logging in to the units. The only debug output shown on the panel is the syslogd output, which isn't too helpful since none of the charging status is logged.
 
DarkDave said:
Thanks for all the great info! The Marvell processor has an ARM5 core. http://www.marvell.com/products/processors/applications/pxa_family/pxa_27x_emts.pdf

Wow, small world! I'm very familiar with the processor in the Blink. I was part of the team that did validation on this processor back in 2002-2003 timeframe. It actually uses the Intel XScale core architecture, which is an ARM 5TE compatible core. I bet that the Linux distro is most likely based on a MontaVista, Wind River, or a Debian ARM distro. I did quite a bit of testing under Linux for the XScale processors. I haven't cracked the case on my Blink to download the contents of the SD card, but I'm betting that some of the WiFi issues I've seen are due to a combination of the older kernel (2.6.20) being used and the WiFi management tools.

Modding the OS image for these is pretty straightforward. Build a new OS image with the same tools in the current image (Python, QT, BusyBox, etc.), then copy over any custom scripts or binaries for the charging hardware. I'm curious to see if all the charging is handled in Python scripts, which would make it very easy to debug. If it is all in Python, then we could add in some code to give us more diagnostic output when the charging fails. We could also add in sshd which would allow remote logging in to the units. The only debug output shown on the panel is the syslogd output, which isn't too helpful since none of the charging status is logged.
Nice to see we have some talent here in the forum! They're kernel is indeed based of the MontaVista work that was submitted to kernel.org and is based off a kernel.org 2.6.20 build. The charging logic is controlled by the python scripts by calling pxaregs (a simple console app to hit GPIO registers). They poll everything :evil: .

So I have a new SD card image almost complete, I've recompiled all of QT and its dependencies and busybox. I have the kernel source but haven't recompiled it. The item that I'm working right now is I'm writing a simple QT application (the right way ;) ) to display charging status and to turn off the backlight during inactivity. We will envolve the app over time to display cool things and maybe my first public rev will display the weather....From my preliminary versions its extremely responsive and works well. Oh yeah I've never had the charger crash or stop charging, like the Blink firmware did for me 3 times.

Just for those who know better and directed towards Ingineer the following are the GPIO mapping for the J1772 board. The GPIOs are numbered with respect to the PXA.

The first 3 GPIOs are outputs and driven by the PXA.
96 = "Reset" -- active high. Must reset the PIC once per boot.
97 = "Stop" -- active high. I leave this low always. I have verified this actually stops charging.
98 = "Enable -- active low. I leave this low always. I have yet to get this GPIO to do anything for me.

The next 5 GPIOs are inputs to the PXA.
95 = "Ready" -- active high.
101 = "Connected" - low = charge port not connected, high = charge port connected
99 = "Charging" - low = not charging, high = charging. This will toggle really quickly if you have a Leaf charging timer enabled.
100 = "Protection" - low = no issue, high = issue. Haven't been able to test. Want one of those testers that the installers have.
102 = "Error" - low = no error, high = error. Once again haven't been able to test.
 
I worked on XScale quite a bit back around that time, these days it's mostly Intel and Broadcom set-top box environments.
whoami said:
The charging logic is controlled by the python scripts by calling pxaregs (a simple console app to hit GPIO registers). They poll everything :evil:
Sound like a web app developer trying to do embedded work. If they had their heart set on Python for the GUI, they should have written a daemon in C/C++ to handle the time sensitive, mission critical functions, and just had their GUI send and receive events from that.

So, are you planning to have your rewrite talk to the Blink mothership, or just be a solid, feature laden, standalone EVSE?
 
We will envolve the app over time to display cool things and maybe my first public rev will display the weather.

Would your version mess with the "required" data reporting for EVP participants?
 
davewill said:
So, are you planning to have your rewrite talk to the Blink mothership, or just be a solid, feature laden, standalone EVSE?
Because the Blink firmware is so bad, I figured I would focus on the basics and get the charging, sleep mode and UI working correctly. Then afterwards I'll postback to the blink servers. Its quite simple what they do so I'm not really worried about it. The protocol is pretty bad so I would only communicate charging statistics but ignore the upgrade, timesync, and log upload part of the protocol.
 
Back
Top