In the next release, which we will try to push out really soon, the Tyres screen has been augmented with a section where you can read the IDs of your TPMS valves and write them back. So, if you have a second set of wheels with TPMS valves, simply make sure you know and remember the IDs of the valves, and can write them back in after a change.

At this moment we have no way to let the car reliable learn new valves with unknown IDs, so you need to visit the dealer once more to get to the IDs of your other set of valves, but from then on, you’re done. Also, if you happen to buy after market valves, check the packaging if there is a 6 hex digit ID printed. Might save you a dealer visit.

If you have TPMS, our advice is to read out the IDs as soon as the next release is out and store a screenshot somewhere.

Thanks bjaolsen for the information and Richard for letting me try this on your car.

While heavily a Work in Progress, Bob has started to put together some decent documentation on the dongle. It’s in the Wiki section of the firmware on gitlab. Have a peek and maybe you want to go on an order spree.

On the hardware side, as you probably have noticed we’ve progressed from the breadboard to veroboard-and-hot-glued in an OBD2 dongle enclosure. At least our builds are now a bit wife-friendly 😉

On the software side we’re working on a few features such as direct access to the Multimedia CANbus that Bob mentioned in the previous post, It will open up a few possibilities you will really like (more on that later). Also, we’re working on making the thing a bit more secure, but also more friendly for the non-technical user.

And then there is the ton of other things small and large. To name just a few:
– some things need to be slightly changed in CanZE now that is fed with data so much faster
– a setting screen in CanZE for this device
– low level technical stuff to make more things possible

For the techies: implementing sending multi-frame ISO-TP messages is needed. It required a lot of testing and coding and what not. This is how my desk looks around midnight. CANbus sniffer (Arduino DUE with GVRET) under USB control, T-cable with custom RJ-45 pinout, RJ45 splitter, RJ45 coupler with a CAN termination resistor tucked inside, RJ45 power insert contraption with lots of hot glue, the DIY Dongle being monitored over USB ……..

Is anyone experienced in moving this sort of home grown garage build stuff to the level of a decent and efficient PCB design without using a development board, a production run and maybe even fulfillment?

My current development dongle already looks somewhat clearer, now that it got it’s case, but under the hood, there is still room for improvement.

The second transceiver has recently be added, still it is not being used right now. So the hardware is present and software development is “under construction”.


Here is an example on how I build my dongle prototype. Note that this is not fitted in a real dongle case. It’s slightly too big for it and at the moment this my only ESP32 board and I want it removable. Also, I do like the RJ45 connectors (see this post) I use to hook up to the ZOE’s different CAN buses. In a follow up post I’ll show a more neatly “dongle-ized” evolution, with added LEDs, and maybe even able to access that second CANbus without any replugging.

The development board is plugged into two pin headers. When removed it reveals the DC-DC converter set to about 5.5 volt and the CANbus transceiver.

The software consists of a few functional parts.

First, there is the CANbus library. While the ESP32 is around for a while now and there is good CAN support in Espressif’s IDF, the support in the Arduino environment is mediocre at best. For instance, the receiving is implemented using proper FreeRtos queues, but sending a frame is totally unbuffered and without any success/failure feedback. Still, it works.

Then there is a simple I/O system that handles communication on basically a character by character basis to and from the Serial-over-USB, Bluetooth and Wifi (basically a socket connection over TCP/IP, and a local access point). While it takes some tinkering to get the WiFi sockets play nicely, all this stuff is very well supported in the ESP32 tool chain for Arduino. A simple command interpreter handles the commands. The language used is called BobDue for historical reasons.

Free frames on the bus are simply received, stored in an array with one element for each ID. When a frame is requested, the latest value is simply pulled from the array. Note that all this traffic is very volatile and it serves no purpose whatsoever to do complex queuing for any other reason than keeping up with the data speed.

ISO-TP frames are decoded and buffered, but only if they match up with the requested ID. Flow control is handled as is message assembly. We don’t support multi-package frame sending yet. Edit: we now fully support long message sending!

The main loop checks if there is a new frame on the queue and if so, having it processed. Then it checks for new characters from the I/O subsystem. Finally it calls a few ticker functions to send out queued ISO-TP frames and other housekeeping tasks, such as aging the free frame array.

The entire source is reasonably commented C code, and can be found on https://gitlab.com/jeroenmeijer/cansee. Just load the source into PlatformIO, select the board, and upload. This is all a work in progress and at this moment your best bet is the development branch. As soon things settle a bit, we will start doing decent releases with pre-compiled binaries attached.

While developing, tons of new ideas are popping up. Will talk about those later.

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.

Remember this post? Well today SpeakEV user StinkyPete posted a detailed sequence of events how to trigger it and what firmware version has it fixed. I will repeat here only his short version.

  • Set the car to pre-condition at a specific time (requiring the car to be plugged in)
  • Allow the pre-condition cycle to fully complete
  • Sometime later, use the key fob to initiate a pre-condition
  • Firmware version of the CLIMA system: 0803 or lower, figured by user Tooney

In this post a general description of the heating system.

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!