You might want to have a peek at this “Frankenstein contraption” testing rig. Things have moved on since (more on that in a later post), but this is how projects like this start. Note that I laid it out neatly on my desk. Real life testing is often a lot messier, often smacking all of this, plus a power bank, plus my laptop, plus my phone in my car!

I do all CANbus connections using RJ45 connectors with a specific pin layout. On the breadboard is the ESP32 development board, powered, flashed and debugged through it’s USB cable. I use PlatformIO on top of Atom on Ubuntu, after having recently switched from the Arduino IDE. The dev board is slightly development unfriendly in that it leaves no pin row on one side. Luckily, that side only needs Vcc, so a small green wire pops out under the board.

On the left side is the 3.3 volt CANbus transceiver. powered from the dev board. From here, a short grey cable carries the CANbus. The T in the middle connects the bus components. On the right a short wire to the SAE J1962 plug going to the car, and on the left is my good old GVRET device based on an Arduino Due and the accompanying SavvyCAN desktop software to spy on the bus and see what is going on. This proved invaluable again. At first the wrong bus resistors made the controller refuse sending packets. Later on it confirmed the car computers did fine answering, but there was a bug in the firmware interpreting that.

The silver block is just a connector, but when this is not connected to the car, I can replace it with an identical block with a 60 ohm resistor over the bus terminals to create an independent CANbus-on-my-desk. Note that to test a CANbus device such as the ESP32, you not only need that bus termination resistor, but also at least one other device to set the acknowledge bit of each frame transmitted by your device under test.

We might have ironed out most issues with the DIY dongle. If there are people willing to build an ESP32 based dongle, especially if they own a Q90, R90, or R110 model, we would like to hear about it. Requirements would be:

  • Preferably drive one of the above models.
  • Willing and able to build a dongle, which requires ordering stuff through Aliexpress or ebay HK, basic soldering skills, and either some basic knowledge of using PlatformIO with Atom (or VSCode) with git, or the ability to upload binaries to an ESP32 development board from the command line.
  • Fool around with it, and be willing to cycle quickly though different updates of CanZE or the ESP32 code.

The KonnWEI dongles are, though the most stable in terms of what you get when you buy, not the best to run CanZE with, especially when fast performance is required. Think like the Driving, Braking and Consumption screens. For the technically inclined: this is because these type of dongles are designed to query, in their own pace, car computers using the ISO-TP protocol, where we had to misuse them to also intercept the raw, operational data. Most of that data can also be obtained through ISO-TP, but again, it would have been slow and we would have to do a lot of reverse engineering to make that work.

And then of course there are a ton of dongles that don’t work at all as they have severely stripped functionality.

With the availability of cheap ESP32 micro-controllers, that can do CAN, WiFi and Bluetooth, time had come to finally build our own hardware. In the next posts, I will describe the hardware, the software and the testing. For now suffice to say that we have something working over Bluetooth, with an unmodified CanZE instance on Android, for under 20 euros hardware, and it is blazing fast.

For those who want to follow in our footsteps and want to build their own dongle, let me start with a shopping list. Especially useful if you order on AliExpress!

  • ESP-32 development board. Maybe something like this.
  • CANbus transceiver board. Needs to be 3.3 volt, so for instance this.
  • Some sort of housing / SAE J1962 (“OBD2”) connector. My advice would be to buy the cheapest dongle you can get and gut it. You should be able to do that for under 3 euros.
  • A small 12 to 5 volt converter. While the ESP development board can take 12 volt, that is a maximum and I wouldn’t advice to run it on the car’s 13.5 volt. Example.
  • Some veroboard, wire, and other generic craft and soldering stuff.

Stay tuned!

Fred Leudon disassembled his Q model BCB himself and here a few of his pictures, now including the filter module!

Note that what I earlier identified as the flyback diode is actually a 63 uH coil. Also visible is the modest PCB of the rectifier module.


Here is the filter module, still closed. For orientation, note it is held upside down and the orange connector (normally connected to the loom going to the car’s “nose”), points to the front of the car when mounted. The four cables exit in the direction of the rectifier box; left side of the car. Also note that the N wire is substantially thinner than the three L wires (see below).


And here the filter is opened up, rotated 180 degrees when compared to the previous picture. The crimp on the center orange cable has it’s shrink wrap insulator removed. It was not properly crimped on the coil wires which made this module fail. The coils seem to be used both as filters as well as current sensors. Also note the black plastic box and a substantial PCB pair.

Now there is confusion is about the N <> L3 relay. My stance, based on what I saw on Renault provided schematics and me hearing clicking sounds, the black box should house said relay. The original author swears there was no power capable relay in the entire module, and that ZOE uses two diodes to N. At the moment, both stances are incompatible and we have no way to verify one or the other.

The much thinner N cable suggests there is substance to my stance, or the two diodes should be in this module. But that doesn’t jive with me, since all the rectification is done in the other box, but I am biased and could be totally wrong of course.

More investigation is needed. Maybe I will get brave and open mine……..

Thank you Fred and user “Pixel”. Here a link to the original source and discussion.

Just like in brain research, often a lot can be learned when things go wrong. A friend driving a ZOE was struggling for months with the weirdest problem. The car charged fine on public chargers, but not at home. However, that home charger did it’s job fine on several other ZOEs. Dealer was helpful but couldn’t find a thing; charger supplier found nothing wrong.

Sequence of events was:

  1. cable plugged in and chargepoint light goes blue;
  2. the usual relays clicking noises from the car (the battery, and the 12 volt bus);
  3. the usual “CLOINK” of the contactor closing in the chargepoint;
  4. after 15 seconds and a bit of clicking in the car, contactors open, light goes green and everything stalls.

All this time, the dash shows “Ongoing checks”. No error, no red nose, but no charging.

After a few weeks of faffing around, trying here and there, including his fivari charger, he is suspecting it is one phase charging that fails, but three phase is OK (hint one). Everyone (yours truly included) says that is very unlikely. In private, he tells me he hears “electric sparking noises” from under the bonnet. Oh dear!

Finally, Renault NL is involved and I am gracefully invited / allowed to join in. So I head over on a misty Friday morning to his house. Three ZOEs present! CLIP tool hooked up and indeed an error is presented (DTC064063), suggesting either chargepoint, cable or filter in the BCB (hint two). All are a bit miffed the dealer missed this.

Then we open the bonnets of two ZOE’s and hook up the charger to each. Lo and behold, his ZOE made some soft, but scary noises the moment charging is supposed to start, just after the “CLOINK” (hint three). It’s not sparks, but it sure isn’t good, more like a rattle. The Renault tech pulls up the functional schematics and explains what might be wrong. To make a long story short: ZOE rectifies current from the 3 phases using a “three-phase full-wave rectifier”.

Note that the N (neutral) is nowhere to be seen. What ZOE does is when you connect single phase (between L1 and Neutral), a relay connects the N wire in the feed line to L3, so now the juice is between L1 and L3, and since L2 is not connected to anything, all is fine. Obviously said relay is not energized when on three phases. It is located in the filter module (see this post). It was this specific relay, or it’s control circuit, that had failed. Friend did a “yessss!!!” as he finally had a diagnosis and as he had confirmation he was right about the single phase after all.

The car has been repaired and is right as rain again. I am hoping for some more info on the filter module; how it works and what went wrong.

For those of you deep into home automation, using documentation compiled by Terrence Eden, me and Harm Otten wrote some Node-RED code to retrieve battery status from the same API that the the Renault Z.E. app uses. I’ve posted it on gitlab.

It outputs an MQTT message every 15 minutes. If there is more than one car associated with the login, more than one message is sent. A message looks like this


In my setup the message finds it’s way to a dashboard on my Android phone using MQTT dash, a Node-RED dashboard and like all other MQTT messages a MariaDb database on my Synology NAS for logging.

Thanks to the kind people running the OVMS project, we have access to quite a bit of documentation on the Twizy. Unfortunately, the current developers are unable to implement this knowledge into CanZE, mainly because lack of Twizy to play with :-). If developing CanZE taught us one thing, it is that it is virtually impossible to add functions without the car available; remote testing simply doesn’t cut it.

So, if any volunteer is available, we would be happy to take him or her into the team. There is no hard prerequisite (hint: when I started I had not written a single Android program), but it would be fair to say the following would help, in diminishing order of importance:

  • Owns a Twizy, ELM dongle and an Android device, and is willing to play and experiment with it;
  • Can bear to stumble along and spend too much free time;
  • Has done some development in Java or C++;
  • Has done some Android development.

We would love to hear from you!

Chris sent me a very interesting dongle. It is called a Freematics ONE. The simplest way to describe it is it being an ELM327 CANbus interface, plus a fully programmable Arduino UNO, plus an SD-card interface, plus a Bluetooth interface, plus serial-over-USB (oh yeah, could do a fast, wired CanZE version) plus an accelerometer, plus (optionally) one of WiFi, GPRS+GSM or xBee modules. Pricepoint is not crazy expensive: a bare version would come in at 70 USD.

I am still figuring what to do with it, but it sure is a great datalogger. And assuming the ELM327 “look-alike” chip inside is reasonably compatible with the V1.5 dongles we use, the Arduino code is in large part available, as I made that for the WiFi gateway. Anyone got cool ideas?

We received a CLIP clone today. CLIP is the tool that your Renault mechanic will use to diagnose any of the brand’s cars. The tool was very kindly financed by “kick-starter” style funding on the Dutch and UK forum. Thank you all for that! Reason I asked for it was that we really like to get to the data of the BCB (the charger inside the car) and we haven’t been able to figure out why. This post is a short update.

Let me first say, the hardware is a serious piece of kit. You have seen your dongles and my interface s and that´s child play compared to this. Two rather massive 4 layer PCB’s plus a connector PCB. Admitted, it seems the hardware can do ISO 9141-2 next to CAN, but the ZOE doesn’t use that. Anyway, it explains the price-point somewhat.

The good news is that it works. Somewhat. As ar as we understand Renault is pushing more and more functions to their central services and there is very little we can do with the tool without online connectivity, which we obviously do not have. Or maybe we do not understand it yet, which is a possibility.

Still, it’s able to run a diagnostic script on all computers of the ZOE and extract their DTCs, including a more extensive context. In theory, that should be enough to teach us how to get at least some data from the BCB. Stay tuned for updates.

From day one we’ve had a love-hate relationship with the dongles. We love them being cheap, available, consumer-grade devices anyone can get on the cheaps and just use them. We hate the instability, how slow they are, the version issues and the complicated way to interact with them. They’re totally unusable to analyze what is going on on the CANbus.

When we started getting our feet wet and didn’t know anything about what was going on on the CANbus we started building our own hardware. Alex and Bob used AVR powered Arduino’s with an external CAN controller, I myself build a derivative of EVTV’s CanDue, based on a fast but not very popular ARM powered Arduino Due. Data was then pushed over serial (USB or Bluetooth) to a PC or tablet for further processing. This of course was totally not consumer rated, but it enabled us to really see what was going on in the car. There are some video’s on youtube of us struggling with that: the AVRs were lacking processing power, and the Due was more bulky and had to be hooked up to a PC using USB.

Fast forward two years and with the fast, small and WiFi enabled ESP8266 processor taking over the role of many AVRs in hobby projects, it was time for a new experiment. I connected a WeMos D1 Mini processor (bottom PCB) to a cheap external CAN controller board (top PCB) featuring an MCP2515, the bigger of the two chip and unfortunately a TJA1050. I had to either replace that chip with an SN65HVD230 or or modify the board a bit for 3.3 volt usage and choose the latter.

Be careful with the pin layout. The ESP8266 is VERY confusing: GPIO numbers, WeMos pin numbers, notation with D-prefixes and without. Most of that stuff is documented in the source code. Oh and I found a really tiny 12 -> 5V buck converter. It is minuscule, tucked away under the WeMos.

On the software side I started with the code for the http Bluetooth gateway, removed all code for Bluetooth and the dongle and added in code to use the CAN controller. This opened up a wealth of possibilities:

  • Fast WiFi interface, fast direct PCI connection to the CAN controller
  • Can auto-connect to the home WiFi network, or act as an access point;
  • Very small footprint (4 x 6 cm PCB);
  • No changes in CanZE and other tools needed as the http interface is exactly the same as for the gateway;
  • Processor easily keeps up with the bus speed;
  • Multi-frame handling (ISO-TP) completely offloaded to the ESP8266.

The device is more functional than an ELM327, completely programmable (watch this space for more functions beyond CanZE) and most of all FAST. You can see how fast here