Chargepoint CT2003 transformation

Introductions, general chit chat and off-topic banter.
User avatar
Smoogus
Noobie
Posts: 3
Joined: Sun, 06 Jun 2021, 18:01
Real Name: Lester Dale

Chargepoint CT2003 transformation

Post by Smoogus »

[ Moderator note: this topic has been split off from the CT500 repair topic, as it's a slightly different unit, and has a new owner. ]

Hi Guys and Gals, I just picked up my Leaf this week, waiting for my Vicroads appt , meanwhile I have a Ct2001 Chargepoint Wall Mount which was previously setup for fleet.
Without having to Frankenstein it with an OpenEVSE kit, does anyone have any knowledge of how to factory reset it , or reprovision it, so it goes into this "Just charge" mode as described below ? This unit has been off the air for a few years as someone had driven over the J1772 Plug... :shock: , so Im guessing it didnt get decommissioned automatically on feb 1 , 2020.
It boots up, but i dont have a chargepoint card.
Anyway, the guts looks just like a ct500,
  • Per the Driven, (https://thedriven.io/2020/07/21/confusi ... v-chargers)
    A letter obtained by The Driven that was sent to ChargePoint Australia site owners in November 2019 confirms that “the distribution agreement between ChargePoint Inc. (USA) and ChargePoint Pty Ltd (Australia) will come to an end in May 2020”.

    It says that customers with expired software licenses from February 1, 2020, and who did not express interest in renewing plans, would have their sites decommissioned from the network and placed into a ‘just charge” mode.

    “A decommissioned or “just charge” station, while disconnected from the ChargePoint Network, can still charge an electric vehicle. The station’s holsters will be able to unlock using any standard RFID card, such as the ChargePoint RFID card or a credit card, however will not be able to unlock using the ChargePoint App,” wrote Chargepoint in the email.

    “Furthermore, a “just charge” station will no longer have the functionality offered by the network services, such as station management, usage monitoring, reporting and analytics – amongst other features.”
Cheers, and thanks in advance to anyone assisting :D

Image
Image
User avatar
Smoogus
Noobie
Posts: 3
Joined: Sun, 06 Jun 2021, 18:01
Real Name: Lester Dale

Re: Chargepoint CT2003 transformation

Post by Smoogus »

Hmmm. Image Links didnt work... here is the Album Link
https://photos.app.goo.gl/PaaEk4fBxCJsA6jH9
User avatar
coulomb
Site Admin
Posts: 6357
Joined: Thu, 22 Jan 2009, 20:32
Real Name: Mike Van Emmerik
Location: Brisbane
Contact:

Re: Chargepoint CT2003 transformation

Post by coulomb »

Smoogus wrote: Thu, 10 Jun 2021, 15:51 Hmmm. Image Links didnt work...
It can be a pest to get the actual URL of the images. In this case, not too hard. I clicked on one of the images, to get it into a mode where Google Photos shows one photo at a time, then used "copy image address" (or similar).

Image

Image
MG ZS EV 2021 April 2021. Nissan Leaf 2012 with new battery May 2019.
5650 W solar, 2xPIP-4048MS inverters, 16 kWh battery.
Patching PIP-4048/5048 inverter-chargers.
If you appreciate my work, you can buy me a coffee.
User avatar
coulomb
Site Admin
Posts: 6357
Joined: Thu, 22 Jan 2009, 20:32
Real Name: Mike Van Emmerik
Location: Brisbane
Contact:

Re: Chargepoint CT2003 transformation

Post by coulomb »

Smoogus wrote: Thu, 10 Jun 2021, 14:27 It boots up, but i dont have a chargepoint card.
Per the article by The Driven, you should be able to use any RFID card, such as a credit card. It doesn't have to be registered or anything. Did you try that?
Anyway, the guts looks just like a ct500,
It looks very similar, though more compactly arranged. [ Edit: I see that they both have "Coulomb TechnoIogies (c) 2010" near the power transformer! ] I have no experience with this variant. The one I worked on (still working fine at Suzi Auto in Brisbane) may have been properly decommissioned before it became available, as you suggest. I note though that the CT500 took a fair while before it was ready to charge; maybe you just weren't waiting long enough? I know when you have exposed mains on equipment that is of unknown origin, the temptation to turn it off fairly soon is strong.

As a point of interest, if you're willing to share, where did you get this one? Is it possible that there are many more units out there, possibly already in "just charge" mode, for reasonable money? I'm on the lookout for a reasonably priced type 2 EVSE. I assume that ChargePoint also make type 2 units, though if this gear all came from the USA, that might not be the case.
MG ZS EV 2021 April 2021. Nissan Leaf 2012 with new battery May 2019.
5650 W solar, 2xPIP-4048MS inverters, 16 kWh battery.
Patching PIP-4048/5048 inverter-chargers.
If you appreciate my work, you can buy me a coffee.
User avatar
Smoogus
Noobie
Posts: 3
Joined: Sun, 06 Jun 2021, 18:01
Real Name: Lester Dale

Re: Chargepoint CT2003 transformation

Post by Smoogus »

Thanks Mike. I tried the Credit card, and also an NFC enabled smartphone with Gpay... No Dice :( ... it had been up for a few minutes...
I might leave it on a bit longer and see if it will phone home to the mothership..Albeit the sim inside the multimodem is potentially out of date/expired... not sure how often it pings CP.
I'll see if I can get hold of a chargepoint card to see how it behaves... It was a Local Council that had planned to set it up again once the Busted J1772 Connector had been replaced(someone drove over it !) , but they never got around to it. I'll put the feelers out to ascertain if there are any more/in use etc.
Cheers
2015 Zeo Leaf G Spec Aero
7.7 KW via 21Jinko Mono 370W Half Cell
6Kw SUN2000-6KTL-L1 Huawei Hybrid Dual Tracker 1ph
Saving for batteries ;)
User avatar
coulomb
Site Admin
Posts: 6357
Joined: Thu, 22 Jan 2009, 20:32
Real Name: Mike Van Emmerik
Location: Brisbane
Contact:

Re: Chargepoint CT2003 transformation

Post by coulomb »

Smoogus wrote: Fri, 11 Jun 2021, 08:28 I tried the Credit card, and also an NFC enabled smartphone with Gpay... No Dice :( ... it had been up for a few minutes...
I'll see if I can get hold of a chargepoint card to see how it behaves...
Well, I'm the new owner of this "charger", and it so happens that I have a ChargePoint card and account already set up. When I put the chargepoint card near the reader, it said "authorising", and a little later, something like "Authorised. Remove plug from the holder and insert into EV".

That's not quite what I was hoping for; I was hoping for "free vend" with no delays. It seemed to be making calls over the 3G network, and that network starts shutting down next month (Optus: April 2022), 2023 for Vodafone, and in 2024 for Telstra. So despite all that gorgeous over-engineered hardware, I'm probably going to have to do the OpenEVSE transplant. I think I can keep the display and with a little hacking I can keep the three LEDs (all are red-green dual LEDs, common cathode). The middle one has a dual transistor with resistors to drive it, so that seems usable with minimal hacking. The display itself is compatible with OpenEVSE. It has a PIC micro on the back; if I can find my PickIt, I might have a poke at it.

The main contactor is buried inside the lower section of the unit, where there is another processor. It would all be controllable via RS-232 I imagine, but I don't have the appetite to reverse engineer the protocol. A quick search found only this OpenEVSE conversion, where the OpenEVSE main board was placed in the lower section. But then he had to add another power supply in the upper section, and that seems wasteful.

I like the idea of putting the OpenEVSE board in the top section where it seems easier to get to, and I believe I can easily get to the opto that controls the main contactor. But then I'd need the test wires, the GFCI wires, and more between the top and bottom sections. I'll consider my options.
MG ZS EV 2021 April 2021. Nissan Leaf 2012 with new battery May 2019.
5650 W solar, 2xPIP-4048MS inverters, 16 kWh battery.
Patching PIP-4048/5048 inverter-chargers.
If you appreciate my work, you can buy me a coffee.
User avatar
coulomb
Site Admin
Posts: 6357
Joined: Thu, 22 Jan 2009, 20:32
Real Name: Mike Van Emmerik
Location: Brisbane
Contact:

Re: Chargepoint CT2003 transformation

Post by coulomb »

coulomb wrote: Thu, 10 Mar 2022, 14:25 The main contactor is buried inside the lower section of the unit, where there is another processor. It would all be controllable via RS-232 I imagine, but I don't have the appetite to reverse engineer the protocol.
I'm thinking about all the good stuff on this Pilot board, and what a shame it would be to toss it all away, or just keep the opto-triac to operate the AC relay. So now I'm back to thinking I might still try and reverse engineer the protocol, or perhaps replace the whole firmware on there with a new one. But setting up the gains for the Cirrus Logic power & energy chip (see below), and all the fiddly control pilot checking, is a consideration.

I now have a good feel for what most of it does:

Pilot board blocks sm.jpg
Pilot board blocks sm.jpg (339.13 KiB) Viewed 2524 times
But worryingly, I have some loose ends. I can't see where CN14 connects to anything (it's just an LED interface, so not essential), and I can't identify the circuit that is behind this connector. They frustratingly use internal layers for signal connections (as well as power supplies, which is standard). My latest guess is that it's a 3.1 V voltage detector. That part of the circuit connects to the processor pin 21, which can be INT1 (external interrupt 1). JP4 is across this chip too, suggesting that you can use a jumper or even a screwdriver to short JP4's pins to perform some sort of interrupt. When you do, LED1 (green) lights. The KIC73 series seem like a good fit, except that the pinout is wrong (or my tracing is bad).

U11 mystery annot.jpg
U11 mystery annot.jpg (105.02 KiB) Viewed 2524 times
Lastly, I can't identify this part across the Control Pilot output, marked D1; presumably it's a TVS diode. It seems to me that OpenEVSE use the wrong sort of diode, one that prevents negative signals (lower than one diode drop anyway) from getting through to the Control Pilot pin of the EVSE connector. [ Edit: I finally found the answer to this. Many of the OpenEVSE schematics are wrong; it should state the P6SMB16CA, not the P6SMB16A. All EVSE TVS diodes (from the pilot signal to earth) should be bidirectional. The "137" in the part number probably refers to a reverse standoff voltage (VR or VWM) of 13.7 V; the OpenEVSE part uses 13.6 V. A suitable 13.6V replacement seems to be the P4SMA16CA, available from many manufacturers. ] The CT2003 diode reads open circuit both directions (at multimeter diode test levels), as I expect:

Mystery part D1 XX137 UK sm.jpg
Mystery part D1 XX137 UK sm.jpg (66.58 KiB) Viewed 2524 times
Any clues on the marking code or even the manufacturer's logo will be greatly appreciated.
MG ZS EV 2021 April 2021. Nissan Leaf 2012 with new battery May 2019.
5650 W solar, 2xPIP-4048MS inverters, 16 kWh battery.
Patching PIP-4048/5048 inverter-chargers.
If you appreciate my work, you can buy me a coffee.
User avatar
coulomb
Site Admin
Posts: 6357
Joined: Thu, 22 Jan 2009, 20:32
Real Name: Mike Van Emmerik
Location: Brisbane
Contact:

Re: Chargepoint CT2003 transformation

Post by coulomb »

I set myself up for some RS-232 logging today:

CT2000 ready for RS232 logging sm.jpg
CT2000 ready for RS232 logging sm.jpg (344.08 KiB) Viewed 2486 times
You can see, approximately top of the photo to bottom:
  • A 2012 Leaf for testing, with J1772 socket. This EVSE still has a type 1 plug (I will eventually replace it with a type 2 plug).
  • The J1772 plug, with foam around it for protection.
  • Laptop for receiving RS-232 data.
  • The "pilot" unit (also called the "Level 2 unit", model number CT2000-L2CORE=AUS). This is a heavy duty case aluminium box with the Pilot board, contactor, current sensor, etc.
  • To its left, a non-contact thermal sensor, in case things get hot.
  • To its right, you can just see a USB to RS-232 adapter, with a switch to select data to or from the pilot unit.
  • Inside a plastic bag, the junction box that provides 230 V to the two main boxes. It has an orange 1.5 mm² cable with an industrial style plug on the end, plugged into my industrial style 15 A outlet. 15 A should be enough to charge via the Leaf's 3.6(?)  kW on-board charger. Another reason to use the older EV; I'm not yet ready for 32 A or even 28 A that the MG can take.
  • The main unit with the blue fluorescent display and card reader hanging out, also in a small plastic bag. To the right is a pair of authenticating cards (ChargePoint and Chargefox).
  • The cap (triangular thing with the hole in the middle), which contains the cellular antenna. The original firmware still needs that to phone home and authenticate. There is also a Zigbee antenna in the cap, but I think I don't want to use this. If anyone is a Zigbee wiz and wants to convince me it's useful, I'll listen to arguments.
Here is the cellular modem, a beautiful work of art, soon to become obsolete:

3G modem with full sized SIM.jpg
3G modem with full sized SIM.jpg (176.62 KiB) Viewed 2486 times
The full-sized (!) SIM card is usually protected by a rubber bung.

Without plugging into the car, I see the same packets repeating every 10 seconds; the longer one to the pilot unit, the shorter one from the pilot unit.

[ Edit: I had the comms directions wrong earlier. ]

To pilot (commands?). . FE 00 02 00 02 00 FF
From pilot: (response?): FE 00 06 C0 02 00 07 00 A1 62 FF

It looks like FE introduces a packet, and FF terminates it. The second and third bytes (e.g. 00 02) are the big-endian size of the data (so 2 bytes and 6 bytes) and the data is followed by an XOR checksum of the second through third-last bytes (i.e. the underlined bytes, which are all bytes excluding the start and end bytes, and of course the checksum itself). So after a 2-byte command the pilot is responding with six bytes of data (sometimes 8).

It appears that when command 0x yz (x, y, z are hex nibbles), the response starts with Cx yz (i.e. I am responding to command 0x yz). This is presumably useful when several commands could be outstanding. It looks like responses starting with 8x yz might be unsolicited data of type xyz, sent because something has changed.

Here is the log from a longer session, plugging in the car, and including a little of the data from the pilot to the main unit near the end. Unfortunately, I was watching the responses when I thought I was watching commands, so there is way more of the response data than command data. Fortunately, if I'm right, it's easy to figure out the commands used to elicit a response.

PILOT unit ⇒ HEAD unit
====================
FE 00 06 C0 02 00 07 00 A1 62 FF < idle response >
< repeated 4 times>
FE 00 06 80 02 00 07 00 A2 21 FF < unsolicited: last byte changed A1 to A2 >
FE 00 06 C0 01 00 00 00 1E D9 FF < response to 00 01 command? 0x1E = 30,perhaps saying the pilot is set to the default of 30 A? >
FE 00 06 C0 02 00 00 7F A3 18 FF < response to 00 02 command? 3 last bytes changed >
FE 00 06 80 02 00 07 00 0B 88 FF < more unsolicited changes >
FE 00 06 80 02 00 0B 00 0C 83 FF < ditto >
FE 00 06 C1 C0 00 00 00 00 07 FF
FE 00 06 C1 00 00 F8 00 01 3E FF
FE 00 06 C1 02 00 4F 70 00 FA FF < Current gain = 1.241 >
FE 00 06 C1 04 00 31 60 00 92 FF < Voltage gain = 0.7715 >
FE 00 06 C1 03 00 07 24 DE 39 FF < Voltage dc offset = 0.0558 => 29.2V >
FE 00 06 C1 01 00 FE 1A 49 6B FF < Current dc offset = -0.0148 => -0.74A >
FE 00 06 C3 00 00 00 00 00 C5 FF < This 03 00 command response is 6 bytes >
FE 00 06 C3 01 00 00 00 00 C4 FF < Also this 03 01 command. Note the order >
FE 00 06 C1 0F 00 80 00 00 48 FF
FE 00 06 C1 1A 00 80 00 00 5D FF
FE 00 06 C1 E0 00 00 00 E8 CF FF
FE 00 06 C1 0F 00 10 00 01 D9 FF
FE 00 06 C1 13 00 00 00 00 D4 FF
FE 00 06 C1 0A 00 00 00 00 CD FF
FE 00 06 C1 0C 00 00 00 00 CB FF
FE 00 06 C1 0B 00 00 00 00 CC FF
FE 00 08 C3 01 00 00 00 00 00 00 CA FF <response to C3 01 command often 8 bytes >
FE 00 08 C3 00 00 00 00 00 00 00 CB FF < Also response to C3 00 >
FE 00 06 C1 0F 00 10 00 81 59 FF <Start of oft-repeated 7-byte command responses >
FE 00 06 C1 13 00 17 3B 80 78 FF
FE 00 06 C1 0A 00 00 06 F9 32 FF
FE 00 06 C1 0C 00 76 82 D2 ED FF
FE 00 06 C1 0B 00 00 BB D4 A3 FF
FE 00 08 C3 01 00 00 00 00 00 03 C9 FF
FE 00 08 C3 00 00 00 4D 66 00 03 E3 FF

FE 00 06 80 02 00 07 00 0B 88 FF < Start of almost repeated sequence >
FE 00 06 C0 02 00 07 00 0B C8 FF < Maybe a 00 02 command is sent every 10 seconds >
FE 00 06 C0 02 00 07 00 0B C8 FF < repeat of above>
FE 00 06 80 02 00 0B 00 0C 83 FF
FE 00 06 C1 C0 00 00 00 00 07 FF
FE 00 06 C1 00 00 F8 00 01 3E FF
FE 00 06 C1 02 00 4F 70 00 FA FF
FE 00 06 C1 04 00 31 60 00 92 FF
FE 00 06 C1 03 00 07 24 DE 39 FF
FE 00 06 C1 01 00 FE 1A 49 6B FF
FE 00 06 C3 00 00 00 00 00 C5 FF < Again: 03 00 responses is 6 bytes >
FE 00 06 C3 01 00 00 00 00 C4 FF < Also this 03 01 >
FE 00 06 C1 0F 00 80 00 00 48 FF
FE 00 06 C1 1A 00 80 00 00 5D FF
FE 00 06 C1 E0 00 00 00 E8 CF FF
FE 00 06 C1 0F 00 10 00 01 D9 FF
FE 00 06 C1 13 00 17 A1 80 E2 FF
FE 00 06 C1 0A 00 FF FF FF 32 FF
FE 00 06 C1 0C 00 00 10 00 DB FF
FE 00 06 C1 0B 00 00 0D 44 85 FF
FE 00 08 C3 01 00 00 00 00 00 1C D6 FF
FE 00 08 C3 00 00 00 00 00 00 1C D7 FF
FE 00 06 C1 0F 00 10 00 81 59 FF
FE 00 06 C1 13 00 17 BD 80 FE FF
FE 00 06 C1 0A 00 00 01 65 A9 FF
FE 00 06 C1 0C 00 76 75 BA 72 FF
FE 00 06 C1 0B 00 00 A6 CE A4 FF
FE 00 08 C3 01 00 00 00 00 00 1F D5 FF
FE 00 08 C3 00 00 00 04 31 00 1F E1 FF
FE 00 06 C1 0F 00 10 00 81 59 FF
FE 00 06 C1 0F 00 10 00 81 59 FF
FE 00 06 C1 13 00 17 C1 00 02 FF
FE 00 06 C1 0A 00 0F 4B 85 0C FF
FE 00 06 C1 0C 00 73 31 62 EB FF
FE 00 06 C1 0B 00 45 15 9E 02 FF
FE 00 08 C3 01 00 00 00 00 00 24 EE FF
FE 00 08 C3 00 00 29 7C 63 00 24 D9 FF
FE 00 06 C1 0F 00 10 00 81 59 FF
FE 00 06 C1 13 00 17 D5 80 96 FF
FE 00 06 C1 0A 00 11 EA B6 80 FF
FE 00 06 C1 0C 00 72 C3 38 42 FF
FE 00 06 C1 0B 00 50 F1 7A 17 FF
FE 00 08 C3 01 00 00 00 00 00 29 E3 FF
FE 00 08 C3 00 00 82 F8 86 00 29 1E FF

HEAD unit ⇒ PILOT unit
=====================
FE 00 02 01 0F 0C FF < Change of data direction, i.e. I threw the switch here. >
FE 00 02 01 13 10 FF
FE 00 02 01 0A 09 FF
FE 00 02 01 0C 0F FF
FE 00 02 01 0B 08 FF
FE 00 02 03 01 00 FF
FE 00 02 03 00 01 FF
FE 00 02 01 0F 0C FF
FE 00 02 01 13 10 FF
FE 00 02 01 0A 09 FF
FE 00 02 01 0C 0F FF
FE 00 02 01 0B 08 FF
FE 00 02 03 01 00 FF
FE 00 02 03 00 01 FF

PILOT unit ⇒ HEAD unit
====================
FE 00 06 C1 0F 00 10 00 81 59 FF < Change of data direction, I put the switch back >
FE 00 06 C1 13 00 18 4B 80 07 FF
FE 00 06 C1 0A 00 11 E9 B3 86 FF
FE 00 06 C1 0C 00 72 C6 0E 71 FF
FE 00 06 C1 0B 00 50 EA 58 2E FF
FE 00 08 C3 01 00 00 00 00 00 38 F2 FF
FE 00 08 C3 00 01 8F AB 2D 00 38 FB FF
FE 00 06 C1 0F 00 10 00 81 59 FF
FE 00 06 C1 13 00 18 14 80 58 FF
FE 00 06 C1 0A 00 11 EB D2 E5 FF
FE 00 06 C1 0C 00 72 BA CC CF FF
FE 00 06 C1 0B 00 50 FB 5C 3B FF
FE 00 08 C3 01 00 00 00 00 00 3D F7 FF
FE 00 08 C3 00 01 E9 47 B3 00 3D EA FF
FE 00 06 C1 0F 00 10 00 81 59 FF
FE 00 06 C1 13 00 18 35 00 F9 FF
< Probably J1772 disconnected at this point >
FE 00 06 80 02 00 07 00 0B 88 FF < Vehicle refused charge status >
FE 00 06 C1 0A 00 00 01 62 AE FF < Power nearly zero >
FE 00 06 C1 0C 00 76 80 52 6F FF
FE 00 06 80 02 00 07 04 A1 26 FF < Status: plug disconnected >
FE 00 06 C1 0B 00 00 A6 5E 34 FF
FE 00 08 C3 01 00 00 00 00 00 42 88 FF
FE 00 08 C3 00 01 F4 AE EC 00 42 3E FF
FE 00 06 C0 02 00 07 04 A1 66 FF (similar to the idle packet, except for 5th real data byte now 04 was 00)
< repeated twice more>

[ Edit: data with just the checksums deleted. I know enough that this is pointless now. ]

The 8-byte packets have a structure to them. They are always in pairs, starting with C3 01 and the second starting with C3 00. The rest of the first packet is always 00, except for the last real data byte, which increases monotonically. It's possible that this is some sort of time stamp, and the time stamp could be up to 6 bytes long, though I suspect 2 bytes. Bytes 7 and 8 (starting with 1) are repeated in the second packet. Bytes 2-6 of the second packet are often 00, but other data appears, especially later in the log. Bytes 2-3 of the second packet taken as a 2-byte number increase monotonically as well.

From this short sample, it seems that the commands to the pilot unit often cycles every 7 packets.

I have lots to think about, including deciding if and when I quit trying to figure this out.
MG ZS EV 2021 April 2021. Nissan Leaf 2012 with new battery May 2019.
5650 W solar, 2xPIP-4048MS inverters, 16 kWh battery.
Patching PIP-4048/5048 inverter-chargers.
If you appreciate my work, you can buy me a coffee.
User avatar
coulomb
Site Admin
Posts: 6357
Joined: Thu, 22 Jan 2009, 20:32
Real Name: Mike Van Emmerik
Location: Brisbane
Contact:

Re: Chargepoint CT2003 transformation

Post by coulomb »

I wondered if I had the data directions wrong; indeed I did, and I've corrected the above post. It makes much more sense now.

I thought I'd add that one of the the reasons I'm doing this is that it seems possible that a fair few of these may end up on the market as ChargePoint forces some operators to update to the newer CT4000 series, and ChargePoint's presence in Australia reduces to zero soon. Also, ChargePoint gear seems to be mainly type 1, and the vast majority of vehicles in Australia are now type 2. So that may prompt operators to replace any existing hardware with more relevant type 2 gear. So this may be a source of relatively inexpensive, tough and reliable (for home use anyway) "chargers" that can be converted to become open.
MG ZS EV 2021 April 2021. Nissan Leaf 2012 with new battery May 2019.
5650 W solar, 2xPIP-4048MS inverters, 16 kWh battery.
Patching PIP-4048/5048 inverter-chargers.
If you appreciate my work, you can buy me a coffee.
User avatar
coulomb
Site Admin
Posts: 6357
Joined: Thu, 22 Jan 2009, 20:32
Real Name: Mike Van Emmerik
Location: Brisbane
Contact:

Re: Chargepoint CT2003 transformation

Post by coulomb »

I found it a bit easier to carry around the beast when it was almost re-assembled, with just a wire hanging out for the RS-232 logging:

CT2000 logging day 2 sm.jpg
CT2000 logging day 2 sm.jpg (362.85 KiB) Viewed 2445 times
CT2000 logging day 2 closer.jpg
CT2000 logging day 2 closer.jpg (1.66 MiB) Viewed 2445 times

I think I've made enough progress to decide it's worth keeping the whole pilot unit as is, assuming I don't find any unexpected problems. The only thing missing is an RCD/GFCI, and it's probably better to have one in your switchboard protecting the dedicated cable as well as your EVSE. Software-in-the-loop RCDs like the Open EVSE uses don't seem as safe to me as simple, dedicated hardware designed for the job.

The protocol between the main and pilot units is pretty simple and straightforward, especially once I realised that most of the responses from the pilot unit are directly from the Cirrus Logic CS5463 chip, documented here (PDF file). During charging, there are 7 commands and 7 responses. The first 5 of these are CS5463 registers: status, temperature, real power, Vrms, Irms. Then follows two other packets, both of which seem to have the elapsed charge time at the end. The time seems to be in approximately 0.1 second units in a 16-bit word, allowing for at least 6,500 s, or 109 min, or 1.82 h. That seems too short, so probably the time is actually reported in 24 bits.
[ Edit: Amazing how far off I was. It's one second units. ] The final packet I haven't figured out as yet.

Data from the main unit to the pilot unit seems to be a combination of 2-byte commands and 6-byte status updates or status change acknowledges. There are 5 bytes of overhead for all packets: the FE and FF start and end bytes, the two-byte data length, and the XOR checksum.

FE 00 n=len data1 data2 .. dataₙ checksum FF
Checksum = XOR of all bytes except the first one and last two. All data is big endian (big, most significant end first).
data1 and data2 indicate the type of packet. For commands, these start with a 0 nibble. "Unsolicited" (my word) packets, use to a change of state that the other end needs to know about, start with an 8 nibble. Acknowledgements start with a C nibble.
The last three nibbles of data1/data2:
002 request general status
001 set important parameters like maximum charge current (data6)
10x request 24 bits of data (in response bytes 3-6) for Cirrus Logic register x (see datasheet)
30y request a longer data response (n=8 bytes), with elapsed time in bytes 7 and 8 (probably byte 6, possibly more)

I'll fill in more details later. For now, here is a taste of the data. First, from the pilot unit:

PILOT unit ⇒ HEAD unit
=====================
FE 00 06 C1 0F 00 10 00 81 59 FF < Status always seems to report 0010 0081 here down: CRDY, TUP, /IC >
FE 00 06 C1 13 00 1C DE 00 16 FF < Temperature: 1CDE00 = 1,891,840 / 65536 = 28.9°C >
FE 00 06 C1 0A 00 11 C7 86 9D FF < 11C786 = 1,165,190 -> 0.1389 x 26500 = 3680W >
FE 00 06 C1 0C 00 71 69 44 97 FF < 716944 = 7,432,516 -> 0.4430 x 530 = 234.8 V >
FE 00 06 C1 0B 00 51 3B 10 B6 FF < 513B10 = 5,323,536 -> 0.3173 x 50 = 15.87 A >
FE 00 08 C3 01 00 00 00 00 03 FB 32 FF < Charging time 3FB = 1019s or 16:59 >
FE 00 08 C3 00 00 3A 7C 58 03 FB 2D FF

I should mention that most of the registers (not the status register) in the Cirrus Logic power and energy chip are 24 bit, floating point. The temperature is scaled to read -128.0 < T < 128.0, RMS values are scaled 0.0 ≤ x < 1.0, and real power is scaled -1.0 < x < 1.0. In other words, the binary point is between bytes 2 and 3 for temperature, to the left of the first byte for voltage and current, and to the right of the first bit for real power.

The scale appears to be 50 A [ edit: I now believe it's 51.2A, 51.3 according to my cheap power meter ], 520 V, and 56,200 W [ edit 2: now 26,6254 W, was dividing by the wrong value. ] Time units appear to be 0.25 s. [ Edit: sigh. They are one second units. ]

HEAD unit ⇒ PILOT unit:
=====================
FE 00 02 00 02 00 FF < Ask for general status 0002 >
FE 00 06 C0 02 00 07 04 A1 66 FF < Response / ack to unsolicited unplugged packet >
FE 00 02 00 02 00 FF
FE 00 02 00 02 00 FF
FE 00 06 C0 02 00 07 00 A2 61 FF < Ack of plugged back in packet >
FE 00 02 00 02 00 FF
FE 00 02 00 02 00 FF
< Charge authorised >
FE 00 06 80 01 00 00 00 1E 99 FF < 80 = change of state. Charge at max 0x1E = 30 A >
< Suspect that 00 02 status 3rd/4th byte = 7F A3 -> contactor on >
FE 00 06 80 02 00 00 7F A3 58 FF < Change of state to 00 00 7F A3 = J1772 state C = charging >
FE 00 06 C0 02 00 07 00 0B C8 FF < Ack status change from pilot >
FE 00 06 C0 02 00 0B 00 0C C3 FF < Ack 7->B, B->C Don't understand why pilot sent this >
FE 00 06 81 C0 00 00 00 00 47 FF < Parameter 01C0? >
< Phase compensation = -4 = -0.086°@ 60 Hz presumably = -.0717°@ 50 Hz; Igain = 10; K (clock divider) = 1: >
FE 00 06 81 00 00 F8 00 01 7E FF < Parameter 0100: Configuration register >
FE 00 06 81 02 00 4F 70 00 BA FF < Param 0102 Current gain register >
FE 00 06 81 04 00 31 60 00 D2 FF < Param 0104 Voltage gain register >
FE 00 06 81 03 00 07 24 DE 79 FF < Param 0103 Voltage DC offset register >
FE 00 06 81 01 00 FE 1A 49 2B FF < Param 0101 Current DC offset register >
FE 00 06 83 00 00 00 00 00 85 FF < Param 300: Accumulated energy cleared? >
FE 00 06 83 01 00 00 00 00 84 FF < Param 301: time cleared? >
FE 00 06 81 0F 00 80 00 00 08 FF < Param 10F Reset DRDY (Data ReaDY) bit >
FE 00 06 81 1A 00 80 00 00 1D FF < Param 11A mask register: this bit DRDY will cause interrupt >
FE 00 06 81 E0 00 00 00 E8 8F FF < Param 1E0 Possibly energy pulse output width register = 1000 >

FE 00 02 01 0F 0C FF < Standard sequence: 010F: Request CL status register >
FE 00 02 01 13 10 FF < 0113 Request CL temperature >
FE 00 02 01 0A 09 FF < 010A Request CL real power >
FE 00 02 01 0C 0F FF < 010C Request CL Vrms >
FE 00 02 01 0B 08 FF < 010B Request CL Irms >
FE 00 02 03 01 00 FF < 0301 Request elapsed charge time >
FE 00 02 03 00 01 FF < 0300 Request ?? >

< Repeats the above 7 requests over and over every 5 seconds or so >
...

FE 00 06 80 02 00 00 7F A1 5A FF < 7F A1 = Contactor off >
FE 00 02 00 02 00 FF
FE 00 06 C0 02 00 07 00 A2 61 FF < Ack plugged in >
FE 00 02 00 02 00 FF
FE 00 06 C0 02 00 07 04 A1 66 FF < Ack unplugged >
FE 00 02 00 02 00 FF < Back to general status >
FE 00 02 00 02 00 FF


So to control a charge, it seems to me that I basically play back most of the commands, acknowledging status changes as required. Obviously I send the desired maximum charge current instead of 30 A at the start. Ooh, I hope I can change the charge current dynamically. If not, that almost certainly rules out using the pilot unit as is. So the next major experiment is a simple control program to test out these ideas.
MG ZS EV 2021 April 2021. Nissan Leaf 2012 with new battery May 2019.
5650 W solar, 2xPIP-4048MS inverters, 16 kWh battery.
Patching PIP-4048/5048 inverter-chargers.
If you appreciate my work, you can buy me a coffee.
sleeperpservice
Groupie
Posts: 367
Joined: Wed, 14 Oct 2020, 20:58
Real Name: Paul

Re: Chargepoint CT2003 transformation

Post by sleeperpservice »

Very nice you are finding a way these units don't have to become junk
User avatar
coulomb
Site Admin
Posts: 6357
Joined: Thu, 22 Jan 2009, 20:32
Real Name: Mike Van Emmerik
Location: Brisbane
Contact:

Re: Chargepoint CT2003 transformation

Post by coulomb »

Wow! Nearly a day wasted. I thought I'd install one of those serial monitoring programs so that I could see data both ways, and also I thought it would make debugging easier. I recently (in the last month or two) updated to Windows 11, and it seems that software that has to fiddle with the low level things hasn't necessarily caught up. All three of my serial ports (Prolific USB to serial and the two in-built Bluetooth serial ports) stopped working, with Code 39 errors from the device manager.

It took hours to sort it out, involving registry editing, more or less as per this web page:

https://www.lifewire.com/how-to-delete- ... es-2619222

but I used the GUID from the error message in device manager, rather than any from the list of GUIDs on that page. When I found the offending UpperFilters key with the value hhds... (arrgh, I didn't write down the full name), I looked for other HKEY_LOCAL_MACHINE registries with that name, found some, and deleted them. I had to reboot to fix the Bluetooth ports, but the Prolific port worked straight away after my registry deletes. Phew.

So think twice before installing even professional looking serial port monitoring software that explicitly mentions Windows 11 support.
MG ZS EV 2021 April 2021. Nissan Leaf 2012 with new battery May 2019.
5650 W solar, 2xPIP-4048MS inverters, 16 kWh battery.
Patching PIP-4048/5048 inverter-chargers.
If you appreciate my work, you can buy me a coffee.
sleeperpservice
Groupie
Posts: 367
Joined: Wed, 14 Oct 2020, 20:58
Real Name: Paul

Re: Chargepoint CT2003 transformation

Post by sleeperpservice »

Ahh windows. Even though they keep so much cruft in for backwards compatibility they always break things on a version change.
My mother in law has an XP machine as that is the only OS that will load the software and drivers that talk to her computer aided sewing machine.
User avatar
coulomb
Site Admin
Posts: 6357
Joined: Thu, 22 Jan 2009, 20:32
Real Name: Mike Van Emmerik
Location: Brisbane
Contact:

Re: Chargepoint CT2003 transformation

Post by coulomb »

sleeperpservice wrote: Sun, 20 Mar 2022, 09:10 Ahh windows.
My mother in law has an XP machine as that is the only OS that will load the software and drivers that talk to her computer aided sewing machine.
Heh. I think it's the drivers that suffer the most from Windows' "improvements". I think Micro$oft thought all the developers would be quick to salute the new order every time they changed the driver interface. And that probably was true in the early days.

I'm also finding that Windows is the "basket case" of operating systems, at least as far as Free and Open Source Software is concerned. A lot of the examples are for Linux or Mac, and you have to figure out what to do for the Windows case. Example: serial.Serial("/dev/ttyUSB0", 9600) isn't going to fly for Windows.
MG ZS EV 2021 April 2021. Nissan Leaf 2012 with new battery May 2019.
5650 W solar, 2xPIP-4048MS inverters, 16 kWh battery.
Patching PIP-4048/5048 inverter-chargers.
If you appreciate my work, you can buy me a coffee.
User avatar
coulomb
Site Admin
Posts: 6357
Joined: Thu, 22 Jan 2009, 20:32
Real Name: Mike Van Emmerik
Location: Brisbane
Contact:

Re: Chargepoint CT2003 transformation

Post by coulomb »

My test code is coming along. I've learned my ≈tenth computer language (≈30th if you count all the assembly languages): python. Lovely plumage, the Norwegian Blue :D It seems to be a pretty decent language for this sort of rough work.

In less than 400 lines of code, I have a simple GUI that is cross platform:

CT2000 test.png
CT2000 test.png (7.12 KiB) Viewed 2334 times
It's still very rough, so I'll spare you the present source code for now, with all it's debugging and no doubt python noob errors. Some of the hardest code was formatting the temperature and real power, both of which can be negative. I'm OCD enough that the rounding has to be perfect.

Actually, the threads handling the asynchronous serial code are pretty hairy too.

The above is with nothing plugged in, so the voltage, current and power should be zero.

I have one major feature to add, and that's handling all the retries for acknowledgement failures. I have a dictionary of packets sent indexed by command, but I have yet to add the timestamp so I can get another thread going to find out what packets haven't been acknowledged in a timely manner, and resend them.

There is still also the unknown packet; for now I just display the three 16-bit words as hex, and hope that I'll figure out what they mean as I do an actual charge. Or make the call that it doesn't matter and I can just ignore it.

Tomorrow is forecast to be a sunny day (the third in a row, yay) so I should be able to experiment with solar power.
MG ZS EV 2021 April 2021. Nissan Leaf 2012 with new battery May 2019.
5650 W solar, 2xPIP-4048MS inverters, 16 kWh battery.
Patching PIP-4048/5048 inverter-chargers.
If you appreciate my work, you can buy me a coffee.
d3wy
Noobie
Posts: 13
Joined: Sun, 30 Jan 2022, 15:49
Real Name: Andrew

Re: Chargepoint CT2003 transformation

Post by d3wy »

Thanks for sharing your journey, sadly these evse are not super readily available but nice none the less. Looking at the UI you've created for it you can tweak the current so follow the sun solar should be achievable? :D
EV Fanatic, impatiently awaiting his number of the pre-order list to be called.
User avatar
coulomb
Site Admin
Posts: 6357
Joined: Thu, 22 Jan 2009, 20:32
Real Name: Mike Van Emmerik
Location: Brisbane
Contact:

Re: Chargepoint CT2003 transformation

Post by coulomb »

d3wy wrote: Thu, 24 Mar 2022, 19:25 Looking at the UI you've created for it you can tweak the current so follow the sun solar should be achievable? :D
This is just a temporary testing UI. I have another button now for sending an updated charge current. Hopefully I'll eventually be able to adjust the current, manually or automatically, from a proper phone app (likely the OpenEVSE one, or a version of it) via WiFi.

But I'm a but stuck at the moment; I can change the current limit before charging starts, but not afterwards, and the problem seems to be with some packets that don't get acknowledged properly or on time. I just need a bit more time hopefully.
MG ZS EV 2021 April 2021. Nissan Leaf 2012 with new battery May 2019.
5650 W solar, 2xPIP-4048MS inverters, 16 kWh battery.
Patching PIP-4048/5048 inverter-chargers.
If you appreciate my work, you can buy me a coffee.
User avatar
coulomb
Site Admin
Posts: 6357
Joined: Thu, 22 Jan 2009, 20:32
Real Name: Mike Van Emmerik
Location: Brisbane
Contact:

Re: Chargepoint CT2003 transformation

Post by coulomb »

coulomb wrote: Thu, 24 Mar 2022, 19:39the problem seems to be with some packets that don't get acknowledged properly or on time.
Breakthrough. I had too large a value for the read timeout; it wasn't leaving enough time to get to the next read, and things weren't getting acknowledged in time. So the pilot unit was giving up sending anything at all.

It works much better now, and I can actually charge, and change the charge limit on the fly. Thankfully, it's also possible to pause the charge, at least on the Leaf, and at least for short periods of time, by clicking on my "stop charge" button. I can also send 0 amps, but this seems to just disconnect the contactor under load, which is certainly not what I want. So I'll disable that possibility. Maybe OK for an "emergency stop" facility.

Here is the laptop controlling a charge; you can see the two blue LEDs on the Leaf indicating charging (and SoC between 4 and 8 bars, or roughly 33 and 75% SoC usable).

Phthon charging 1 sm.jpg
Phthon charging 1 sm.jpg (176.41 KiB) Viewed 2275 times
The EVSE is off to the left of this photo, flashing a red LED and sending grave warnings about "L2CORE" "installation" errors. That's presumably because the display processor is no longer seeing correctly timed acknowledgements from the pilot unit, and in fact is seeing unexpected acknowledgements because the PC is in control.

A closeup of the app, with some of the cave-man debugging in the command terminal (where I started the Python app from). Note that the voltages and currents are off, and the status is an unknown value.

Python charging closer 1 sm.jpg
Python charging closer 1 sm.jpg (226.83 KiB) Viewed 2275 times
My suspicion is that I screwed up with some of the initialisation packets. I did copy and paste from actual logs, but I had to do some significant editing to get the format right for Python, and I may have screwed up one or two of them.

I did have the charge unexpectedly stop at one point, so that's an indication that the pilot unit is not happy with things, possibly the initialisation, but possibly also the lack of retries. But this is progress.
MG ZS EV 2021 April 2021. Nissan Leaf 2012 with new battery May 2019.
5650 W solar, 2xPIP-4048MS inverters, 16 kWh battery.
Patching PIP-4048/5048 inverter-chargers.
If you appreciate my work, you can buy me a coffee.
HungryTradie
Noobie
Posts: 14
Joined: Mon, 21 Mar 2022, 12:45
Real Name: Jeff
Location: Bathurst

Re: Chargepoint CT2003 transformation

Post by HungryTradie »

G'day @coulomb really nice work.

Is it plausible that they are simply using an existing protocol for comms, have you eliminated ModBus from the candidates?
Could the last packet have something to do with the authorised account to debit the energy from (did you say you are repurposing a commercial charger that needs account authorisation)?

I'm no expert at Python but I have learned a few tricks to make my C logic more pythonic, would you like someone to have a look at your code?
1HungryTradie
User avatar
coulomb
Site Admin
Posts: 6357
Joined: Thu, 22 Jan 2009, 20:32
Real Name: Mike Van Emmerik
Location: Brisbane
Contact:

Re: Chargepoint CT2003 transformation

Post by coulomb »

HungryTradie wrote: Sun, 27 Mar 2022, 10:43 Is it plausible that they are simply using an existing protocol for comms, have you eliminated ModBus from the candidates?
Definitely not ModBus.
Could the last packet have something to do with the authorised account to debit the energy from (did you say you are repurposing a commercial charger that needs account authorisation)?
It's possible, but I'd expect the head unit (which is the one that talks to the mother ship) to do all that.
I'm no expert at Python but I have learned a few tricks to make my C logic more pythonic, would you like someone to have a look at your code?
This temporary Python code is just quick and dirty, though of course learning a new language means it's less suitable for that sort of thing 🤔 But thanks for the offer. I mainly chose Phthon so I didn't have to spend a lot of time getting the GUI working, or using something like Curses to avoid a GUI, while updating random values.

I'm getting close now; I had my first PC controlled charge yesterday, but it refuses to send the time [ edit: sigh. I was using only the first 6 bytes; all the action happens in the last 2 bytes. ], and the voltage and current are still mucked up [ edit: most of the time, and now the power as well ]. I've checked the initialisation code, and it's sending the same as the head end sends. It doesn't always charge either.
MG ZS EV 2021 April 2021. Nissan Leaf 2012 with new battery May 2019.
5650 W solar, 2xPIP-4048MS inverters, 16 kWh battery.
Patching PIP-4048/5048 inverter-chargers.
If you appreciate my work, you can buy me a coffee.
User avatar
coulomb
Site Admin
Posts: 6357
Joined: Thu, 22 Jan 2009, 20:32
Real Name: Mike Van Emmerik
Location: Brisbane
Contact:

Re: Chargepoint CT2003 transformation

Post by coulomb »

Who knew that asynchronous communications was tricky? 🙋‍♂️

I was on my second comms design when I realised that I was having synchronisation issues. Huh! Python has locks and semaphores... But it got really hairy fast, and I realised that I'd have some trouble replicating this in C on an Arduino.

So I simplified things a lot, now for my third comms design I'm using a single "interrupt routine" called at regular intervals. Only one command is pending at once. It has full retries now, and is working successfully. It will be even cleaner with a real switch statement or two in C.

During all this, it occurred to me that the unknown output from the pilot unit had to be the one vital piece of data that was missing (when you're a commercial charger at least): energy consumed. I decided that one of the 16-bit words has units of approximately 1/20th of a watt·hour. When I stop the charge and start it again, the time and energy numbers start from zero again. I've just realised that I can probably stop that by not sending the initialisation code again, part of which sends zero to the same register that the time comes back in. So I'll add a "pause charging" button to see if I can get it to retain the charge time and energy so far.

It's going slower than I expected, but you have to expect a certain amount of unexpected delay with software development. 🤔 Even quick and dirty code like this.
MG ZS EV 2021 April 2021. Nissan Leaf 2012 with new battery May 2019.
5650 W solar, 2xPIP-4048MS inverters, 16 kWh battery.
Patching PIP-4048/5048 inverter-chargers.
If you appreciate my work, you can buy me a coffee.
User avatar
coulomb
Site Admin
Posts: 6357
Joined: Thu, 22 Jan 2009, 20:32
Real Name: Mike Van Emmerik
Location: Brisbane
Contact:

Re: Chargepoint CT2003 transformation

Post by coulomb »

Here is what's inside the top of the CT2003; basically 2 antennas:

CT2003 antennas sm.jpg
CT2003 antennas sm.jpg (118.5 KiB) Viewed 1454 times
Outlined in yellow is the cellular antenna; it looks like a piece of solid core wire cut to a precise length. The zigbee antenna outlined in orange looks like a standard router antenna. The galvanised steel earth plane / shield thing is electrically isolated from the main chassis by three nylon nuts, bolts, and washers.

In case anyone is interested in the GPRS modem, I pulled it apart today. It's 3G, so if it's not obsolete now, it soon will be, and I no longer need it to operate the EVSE.

Inside MultiTech GPRS modem 1 sm.jpg
Inside MultiTech GPRS modem 1 sm.jpg (215.9 KiB) Viewed 1454 times
It's basically a Wavecom wireless CPU module with a power supply (operates on 5-32 VDC), the SIM holder, some LEDs, and an RS-232 chip. So most of the work is done in the Wavecom module. Here it is unsoldered and with its top metal shield removed:

Inside MultiTech GPRS modem 6 sm.jpg
Inside MultiTech GPRS modem 6 sm.jpg (160.36 KiB) Viewed 1454 times
There are 4 largish Ball Grid Array chips; one is by Ricoh, I suspect it's an audio amplifier chip. The processor is an ARM, of course; the ST chip is a 32 Mbit flash chip (2M x 16).

Inside MultiTech GPRS modem 8 sm chip numbers.jpg
Inside MultiTech GPRS modem 8 sm chip numbers.jpg (329.13 KiB) Viewed 1454 times
MG ZS EV 2021 April 2021. Nissan Leaf 2012 with new battery May 2019.
5650 W solar, 2xPIP-4048MS inverters, 16 kWh battery.
Patching PIP-4048/5048 inverter-chargers.
If you appreciate my work, you can buy me a coffee.
User avatar
coulomb
Site Admin
Posts: 6357
Joined: Thu, 22 Jan 2009, 20:32
Real Name: Mike Van Emmerik
Location: Brisbane
Contact:

Re: Chargepoint CT2003 transformation

Post by coulomb »

I should add this link to my "how I think the firmware works" post: viewtopic.php?f=62&t=7578&p=91647#p91647

Also this photo that I thought I posted earlier; I've gotten a lot further since this:

openevse WiFi on Jaycar esp32 sm.jpg
openevse WiFi on Jaycar esp32 sm.jpg (149.92 KiB) Viewed 1453 times
MG ZS EV 2021 April 2021. Nissan Leaf 2012 with new battery May 2019.
5650 W solar, 2xPIP-4048MS inverters, 16 kWh battery.
Patching PIP-4048/5048 inverter-chargers.
If you appreciate my work, you can buy me a coffee.
User avatar
coulomb
Site Admin
Posts: 6357
Joined: Thu, 22 Jan 2009, 20:32
Real Name: Mike Van Emmerik
Location: Brisbane
Contact:

Re: Chargepoint CT2003 transformation

Post by coulomb »

I thought I'd get the display working as a sort of break from working on the firmware. How hard can it be, right? Hitachi compatible, I just have to find which pins have the I2C interface. So I looked up the datasheet; as is not unexpected, the display used is no longer manufactured. But there is one that has a very similar part number. It showed me that the serial (I2C) interface is right next to the 16-bin parallel interface. When I looked, there is was... missing! This older model only has the parallel interface; the newer models have the parallel and serial interfaces.

Huh. Well, I want to work with that I have; spending more money on a display I'll rarely use (?) is not on.

But, no problem; in this post in the other topic, RedwoodEV states:
The display messages are encoded as <ESC> C <index> <0x00> Text <0x00>.
Index? I guess that's the co-ordinates; either the first null (0x00) is actually the row/line number, or the index is 0-0xF for the first line, and 0x10-0x1F for the second line, or something like that. So I hooked up an RS-232 interface and sent some escape sequences with various combinations, and the result was initially very confusing. I think it was bugs in my code, but I had the text scrolling right to left one position for each character sent, with blanked areas also moving right to left. It looked like the Atmel chip on the back of this display, which drives the parallel interface and all its complexity, only allows for the annoyingly slow and sparse messages that you always see with these ChargePoint EVSEs. This was definitely not what I wanted. There may be other escape sequences, but unless they are really obvious (I might try some VT100 sequences), my only resort will be to erase the flash on the Atmel and write my own display driver. Ugh!

I was just about to send the above when I did a few more experiments, and was surprised to find a stable, non-blanking display. My findings are:
  • Serial parameters are indeed 19200/n/8/1, as posted.
  • I don't know how I got into that scrolling left with blanking mode, and I don't particularly want to find out!
  • 0x0C (formfeed) homes the cursor (visible or not, so far it's invisible), but doesn't clear the display.
  • 0x0D (carriage return) and 0x0A (line feed) do what you'd expect, except that line feeding from the bottom line has no effect.
  • 0x0E usually clears the display and homes the cursor, but it doesn't always home the cursor. 0x0D0x0E always seems to clear and home.
  • Cursor positioning is by Escape C index text (no nulls before or after the text). Index is 0 for top left, 0xF for top right, 0x10 for bottom left, and 0x1F for bottom right.
  • If you send text past the end of the line, the text wraps as expected: from top right to bottom left, and from bottom right to top left.
In the photo below, the text at index 8 is "Right end"; the "d" wraps to the bottom left, and is overwritten by the next string starting at index 0x10 (the "L" of "Left"). The display looks much better and more colourful than the photo below indicates; the text is washed out below:

Display with cursor positioning sm.jpg
Display with cursor positioning sm.jpg (355.79 KiB) Viewed 1411 times
I don't know what makes the middle LED blink; it's under the control of the Atmel behind the display. It seems to flash on its own when certain characters are sent. It's been flashing all day for me, except now it's stopped. No biggie. Though it would be nice to find some sequences that turn it on/off/red/green and maybe yellow.

Edit: Just powering up the display causes it to cycle the middle LED green and red, displaying "CHARGEPOINT NETWORK" then a second or two later "Loading."
MG ZS EV 2021 April 2021. Nissan Leaf 2012 with new battery May 2019.
5650 W solar, 2xPIP-4048MS inverters, 16 kWh battery.
Patching PIP-4048/5048 inverter-chargers.
If you appreciate my work, you can buy me a coffee.
User avatar
coulomb
Site Admin
Posts: 6357
Joined: Thu, 22 Jan 2009, 20:32
Real Name: Mike Van Emmerik
Location: Brisbane
Contact:

Re: Chargepoint CT2003 transformation

Post by coulomb »

Partial schematic trace for the display board:

CT2000 Display Partial Sch.png
CT2000 Display Partial Sch.png (26.12 KiB) Viewed 1361 times
MG ZS EV 2021 April 2021. Nissan Leaf 2012 with new battery May 2019.
5650 W solar, 2xPIP-4048MS inverters, 16 kWh battery.
Patching PIP-4048/5048 inverter-chargers.
If you appreciate my work, you can buy me a coffee.
Post Reply