Category: Hardware

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.

Why does my dongle not work? Is it working? What version is it? Why do only some of the values get displayed?

I recently discovered an app that can test a dongle and tell you what version it is, so also what features it implements:

https://play.google.com/store/apps/details?id=com.applagapp.elm327identifier&hl=en

Here is what the app produces for my MaxiScan dongles, which advertises itself as an v1.5 …

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 Richard Thompson 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.

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.