User avatar
turbo2ltr
Posts: 1376
Joined: Fri Jul 30, 2010 11:13 pm
Delivery Date: 04 Feb 2011
Leaf Number: 185
Location: Phoenix, AZ

Re: Mods for the Blink EVSE ! (was Fix)

Wed Apr 13, 2011 12:08 am

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.
Silver SL-e
Ford F450 Crew Cab Hybrid Conversion

User avatar
sdbonez
Posts: 468
Joined: Tue Sep 28, 2010 11:44 pm
Delivery Date: 26 Jun 2015
Location: San Diego, Ca (San Marcos)

Re: Mods for the Blink EVSE ! (was Fix)

Wed Apr 13, 2011 12:40 am

turbo2ltr wrote: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...)
EV Prj: prereg 4/19 11:21a, appvd 7/22 11:34a, on-site eval 8/27 1pm, installed 3/30
Leaf: Red eTec resvd 4/20 2:33p, order open 8/31 11:30a, confirmed 9/3 2:00p, Carwings 3/9
Dash@Delivery 4/8, 7-day on 3/23, Delivered 03/30, Carwings: 'Bonez' VIN#728

whoami
Posts: 41
Joined: Fri Apr 08, 2011 8:41 pm

Re: Mods for the Blink EVSE ! (was Fix)

Wed Apr 13, 2011 8:47 am

turbo2ltr wrote: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 :-).

User avatar
turbo2ltr
Posts: 1376
Joined: Fri Jul 30, 2010 11:13 pm
Delivery Date: 04 Feb 2011
Leaf Number: 185
Location: Phoenix, AZ

Re: Mods for the Blink EVSE ! (was Fix)

Wed Apr 13, 2011 9:18 am

I unplugged this one as per the OP.

Image
Silver SL-e
Ford F450 Crew Cab Hybrid Conversion

User avatar
Ingineer
Posts: 2741
Joined: Fri Oct 15, 2010 1:09 pm
Delivery Date: 13 Jul 2011
Leaf Number: 6969
Location: Berkeley, California
Contact: Website

Re: Mods for the Blink EVSE ! (was Fix)

Wed Apr 13, 2011 10:48 am

turbo2ltr wrote: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
Easily Learn Electricity HERE! - - - - Website: http://evseupgrade.com/ - - - - Like us on Facebook: EVSE Upgrade

DarkDave
Posts: 32
Joined: Fri Jan 14, 2011 12:49 am
Delivery Date: 31 Mar 2011
Leaf Number: 0714
Location: Chandler, AZ

Re: Mods for the Blink EVSE ! (was Fix)

Thu Apr 14, 2011 12:26 am

Thanks for all the great info! The Marvell processor has an ARM5 core. http://www.marvell.com/products/process ... x_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.
2011 Glacier Pearl SL-e
Leaf delivered: 3/31/11
25,450 miles, all Arizona desert
Lost 4th bar Jan 5th, 2015 at 24532 miles
New "Lizard" battery installed 2/26/2015

whoami
Posts: 41
Joined: Fri Apr 08, 2011 8:41 pm

Re: Mods for the Blink EVSE ! (was Fix)

Thu Apr 14, 2011 9:48 am

DarkDave wrote:
Thanks for all the great info! The Marvell processor has an ARM5 core. http://www.marvell.com/products/process ... x_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.

User avatar
davewill
Posts: 4976
Joined: Thu Mar 17, 2011 6:04 pm
Location: San Diego, CA, US

Re: Mods for the Blink EVSE ! (was Fix)

Thu Apr 14, 2011 10:09 am

I worked on XScale quite a bit back around that time, these days it's mostly Intel and Broadcom set-top box environments.
whoami wrote: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?
2014 Rav4 EV, Blizzard Pearl White
2011 LEAF SL w/QC, Blue Ocean, returned at end of lease

User avatar
turbo2ltr
Posts: 1376
Joined: Fri Jul 30, 2010 11:13 pm
Delivery Date: 04 Feb 2011
Leaf Number: 185
Location: Phoenix, AZ

Re: Mods for the Blink EVSE ! (was Fix)

Thu Apr 14, 2011 10:23 am

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?
Silver SL-e
Ford F450 Crew Cab Hybrid Conversion

whoami
Posts: 41
Joined: Fri Apr 08, 2011 8:41 pm

Re: Mods for the Blink EVSE ! (was Fix)

Thu Apr 14, 2011 10:25 am

davewill wrote: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.

Return to “Blink”