Update: Compact 3.7kW charger project

Picking up after where we left a week ago: After some debugging, I’ve been able to start communicating with the charger.

At last: I get meaningful data from the charger

At last: I get meaningful data from the charger


 
Assuming the hardware-related problems I had to solve before successfully receiving my first CAN packet are rare, I must say that the steps required to actually get packets from the bus and on the bus are quite simple.

Read the CAN bus with a few lines of code.

Read the CAN bus with a few lines of code.


 
Every car today relies on a CAN bus and has 70-150 CAN-nodes. Listening to and manipulating these values is not only interesting but can also unlock hidden features and make your car more run more efficiently. I strongly suggest anyone interested to look into the CAN bus and ways to get on the bus (since not everyone wants to write code) – it’s surprisingly easy and cheap to do so.

My 2-node bus with a charger and a BMS (emulated by the Arduino) is even more simple than the bus on any normal car.

To be able to speak to the charger, my Arduino has to know what to send and – crucially – how.

Although I’ve already flipped bits in ECU’s many years ago, I had to read-up on how the frames are set up and how the charger expects to receive its data, since the CAN protocol and specifications have been extended.

RTFM1: Packet format definition

RTFM1: Packet format definition


 
With this information, I then studied what kind of information the charger expects in order for it to start a charge and keep charging.

RTFM2: How to build valid control messages for the charger

RTFM2: How to build valid control messages for the charger


 
Many things can go wrong during a charge and with the charger itself. This is why a few bytes in every charger broadcast packet are dedicated to its status – many of them binary in bit representation.

RTFM3: Some bytes are filled with status bits

RTFM3: Some bytes are filled with status bits


 
After writing some code to assemble the packets and getting replies to the changes I set, it was time for some real-world in-TWIKE testing, since I don’t have another battery to test on.

First real-world testing

First real-world testing


 
With my battery at about 30% charge, TW560 is ready for its first charge at ludicrous speed 🙂

I connect the inverter and my existing chargers to 2 phases and add the new charger on the third phase of my 11kW plug.

Time to start the charge! *add determined face here*

19A from 3 chargers, 5.1A from inverter (@ battery voltage)

19A from 3 chargers, 5.1A from inverter (@ battery voltage)


 
Things get interesting by the minute – it’s incredible to see the numbers climb past the 32 amps I usually charge at – see just how far…

Maximum rate: 48.6A!

Maximum rate: 48.6A!


 
Wow! Now let’s have a look at the number we’ve been waiting for: Total wattage going into the battery.

Impressive: 9.6kW

Impressive: 9.6kW


 
With this, it’s official:
TW560 is the fastest-charging TWIKE…in the world! 🙂

With this successful test, my next step is to create a stand-alone charging controller which allows me to change the charge parameters without a computer being present and maybe display some kind of charge status information.

This, again, will take some time – stay tuned.

(another related mini-project coming up is adding a serial-to-can converter to the Dreifels-controller, which would allow the TWIKE to enter the world of modern vehicles – where status messages and logs would all be accessible via a single CAN connector, the controller could take control of various chargers and telemetry nodes, enable smart displays without Bluetooth hacks etc.)

As usual, a cautionary note: 10kW is a lot of energy, at any voltage. Please don’t attempt to re-create this kind of setup if you aren’t 100+% sure what you’re doing.

Want to see how the test looked like today and hear some commentary? You’re in luck: I recorded a short video for you 🙂