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.

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!

When I got home tonight the KONNWEI dongle I ordered on August the 29th had arrived directly from China.

I ordered it here. Less than 9 euros.

It had the proper 120 ohm resistance on the CANbus. Next, I opened it up and it is the new design, i.o.w., it seems like the error was found and new production runs are OK. Of course we don’t know how many old supplies there are and if by chance I got the top of a just replenished stack. YMMV.

Note in the previous post that the problem started occurring already in April. I didn’t know this but at least there is a fair chance the problem dongles are sort of slowly going out of stock.

Short glossary: We have no ties with KONNWEI. Actually KONNWEI902s are knock offs of real ELM327 based hardware, but they have been the only consistently stable ones we have found. And we haven’t spotted “knockoffs of KONNWEI knockoffs”. Yet.

It seems the manufacturer has cost-optimized the hardware, which is not bad at all. However, as said in the previous post, there is a problem with one component. Recent deliveries have not worked and actually I heard of a few drivers getting weird error messages in the dash. Not fun.

Long story short: we would gladly recommend something that works, but we have no decent alternative. The solution at this moment unfortunately is tinkering. It’s not hard to do and you don’t need fancy knowledge or tools. Just a fitting hex tool and a sharp exacto style knife. I did this on a non working dongle and can confirm it works.

  • remove the 4 screws
  • gently pry open the case. Be careful that the connector and the front stay in the half that has the main PCB mounted on
  • check this post to determine if you have the old or the new design. Unfortunately there is no way to check this from the outside *)
  • if the design is “old”, stop here. If your dongle does not work there is another problem
  • if the design is new, locate the chip with 8 pins roughly in the middle of the PCB
  • just above and between the 2nd and 3rd pin of that chip, there is a tiny black component (resistor), see picture below
  • carefully cut away the middle part of the resistor. Ensure you do not damage the track going up on the right side. Damaging the track on the left, going to the second pin is not a big deal. Of course if you have soldering skill, you can also de-solder the resistor.
  • close the case and put the bolts back in. Note that one side has hex formed holes, these are for the nuts.

Done!

I drove with a modified dongle today without any problems. The only issue I had were more than usual ATMA timeouts and I had the impression it was all a bit slower than what I am used to. The former I need to investigate a bit further, it can probably be fixed with a modification in CanZE, the latter might be subjective, or maybe the processor is a bit slower in the optimized design.

We fully expect KONNWEI to fix the problem in the long run, and it seems there are already new designs shipped with the new resistor. part of current stock seems to be troublesome though.

*) If you have a multimeter there is actually an external way to check the dongle. Measure the resistance between pin 6 and 14. If it’s 20 ohms, you have a bad dongle. If it’s 120 ohms, it’s fine. BTW pin counting is from right (1) to left (8), top row, meaning in the wider part of the connector first, then the bottom row, again right (9) to left (16) in the smaller part.

EDIT: The leafspy guys reported on this last April. Oops! Oh well! More pictures there too BTW.

Today I received an email stating that some KONNWEI’s are shipped with a 20 ohm resistor across the CANbus. This is a massive production fault. First of all, normal bus termination is 120 ohms, second, the dongle should not impose a new termination resistance at all.

Now, I am not saying this is the root problem of the recent KONNWEI issues. I need to do tests, and I will try to do them tonight. It is still possible there are additional firmware issues, and in fact, earlier measurements indicate there may be indeed. This resistance problem might cause problems though with some ECUs and not with others, making everything transient and hard to tackle. I am extremely grateful to Amazon user for finding this error and SpeakEV member cDy for relentlessly pursuing the issue and following tons of reviews.

Stay tuned. If this is indeed the main problem, at least there is a path to a solution.

Latest KONNWEI guts with faulty resistor. Flat cable and crystal on the PCB

Old KONNWEI design with the wiring loom and the floating crystal

A few days ago I tested that dongle I received and things were not looking good. Flow control commands are not accepted, and while I assured it is able to both send and receive data on the CANbus *) it does not like the replies to diagnostic commands the car puts on the bus.

I opened it up and the hardware is definitely different. A better build in my view, but the firmware (reporting the same version BTW, lies lies lies) does not work.

The very cheap but very well build “HH” dongle I bought was total crap. Not only did it not work, the firmware was easily send to lala-land.

IN the mean time, as my own KONNWEI died on me (I abused it a lot), I ordered a new one. If it works, I will post a link to the item here. If not, we need to explore a few new paths:
– see if we can work around the issues in software (might prove impossible or very hard);
– hand pick dongles that do work (complicated to manage, and who can you trust sending exactly that device);
– build our own hardware (out of reach for 99.9% of the users, and we are certainly not going to market a new design);
– focus on the Freematics ( http://canze.fisch.lu/freematics/ ) which can run firmware we can make (relatively expensive).

All in all this really stinks and we are NOT happy.

This is an intermediate post. I got a report from a user who ordered what seemed to be a bona fide KONNWEI, but had no success. That was slightly alarming, but one error could be anything. He send me the dongle that arrived today. *)

I did a quick test, only to discover several fields are not picked up. Went back inside to check the version and ATZ reported a neat 1.5.

Now I am worried that we have no decent advice anymore and the dongles are truly hit-or-miss. Either there are bootleg KONNWEI’s on the market, or they did something to their dongles breaking CanZE. I will investigate further, and maybe I can make this thing behave. Stay tuned.

 

*) Sorry about confusion I caused earlier with this post. I had mixed up this dongle with one that is still on order. I will report on that one separately, especially if it works.

Please skip if you are getting tired of this development talk ūüôā ……

While I was debugging the WiFi interface today I was, of course still getting in and out, now and then resetting the dongle, making sure th car was awake, etcetera. And then one of those “aha”-moments struck me.

What if I took a web-server (or even the Wemos reprogrammed) and make it emulate my gateway with possibly prerecorded answers from my car?

Eureka! Not only would I not need to leave my desk anymore, I could do entirely without the car, even tweak values supposedly coming from it. As all the primitives that are available in the real ELM327 driver are also present in the WiFi gateway, it should work. So, I quickly threw together a small “Wemos WiFi Bluetooth gateway emulator” on my ancient Freecom NAS server and verified it could serve at least one IsoTp frame (module temperatures). Like this for the IsoTp primitive:

<?php
$PAR = $_GET['f'];
switch ($PAR) {
    case "7bb.79b.6101":
        echo "{\"C\":\"IsoTp\",\"F\":\"$PAR\",\"R\":\"61011381138700000000000000000000000009980D61033A20D000000548000000000000000E721D000001142927100000000000\"}";
        break;
    case "7bb.79b.6161":
        echo "{\"C\":\"IsoTp\",\"F\":\"$PAR\",\"R\":\"6161000972C0C8C8C8ACA40000DB8D00002D6DFF\"}";
        break;
    ........
}
?>

So here is what that looks like, interface wise

jeroen:~$ curl http://[removed]/wemos/IsoTp?f=7bb.79b.6104
{"C":"IsoTp","F":"7bb.79b.6104","R":"6104000032000033000032000032000032000032000032000032000032000032000032000032"}
jeroen:~$

7bb and 79b is the ID pair of the LBC, and 6104 is the command to get the cell temperatures. The real frame contains more data but this is the only part used by CanZE in the heatmap. I have marked those fields in blue. Those are the 12 module temperatures in hex, with an offset of 40 degrees (32 hex is 50 decimal, minus the offset is 10). Then I continued working on the “ELM327Http” device in CanZE, which was sorta done, but was still full of errors. After a few hours of painstaking work, but not leaving my desk (the family was out with the ZOE anyway): success.

As I was 80% done with tedious under the hood changes for the new diagnostics, I had to fix the many problems I had introduced in that area too before CanZE was only slightly willing to operate at all. Did I already mention how that process goes? Well, exactly like that, but now without all of the car back and forth stuff.

Next: sniff the car on all possible frames and put that in the PHP code. After that is done, verify the other screens and then onto the diagnostics. Stay tuned.

Next day edit: of course errors keep popping up and I fix them as we go, but I have now committed the changes to the branch for internal testing. I also too a snapshot of my car (all free frames and all diagnostics of the EBV, LBC and CLIM computers) and put them all in said webserver “car emulator” code.