Category: Hardware

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.

This post is not about the ZOE, Fluence or Kangoo Z.E., but about what it takes developing something like CanZE. Imagine debugging this beast without a car systems emulator on your desk and no Bluetooth emulation in Android Studio. The process goes a bit like this:

  1. Think of some great feature you always wanted to implement;
  2. Program it;
  3. Conclude you made some silly errors;
  4. Back to 2, when done…
  5. Download it to your phone;
  6. It crashes immediately;
  7. Back to 2, when done…
  8. Walk to the car, unlock it, wake it up, start Canze, wait for it to pair with the dongle, open your great new screen;
  9. It crashes immediately;
  10. Close car, kill remnants of CanZE, get back in the house, sit down, connect phone to USB only to conclude the crash post mortem is gone from the phone’s memory. Back to 2. When done…
  11. Notice it doesn’t do exactly what you intended. Often you’re now back to 1 instead of 2, as you need to think again where you conceptually went wrong. Sometimes that means creating entire new data structures. And all the existing functions need to work;
  12. It works! now at least test some of the old functionality!
  13. Old functionality is broken;
  14. Fix it. back to 10

And I am not even talking about version control, releasing, managing changes between developers. It is a far from complete list, but you get the idea: it is a tedious process often taking place in the hours after midnight.

As I am working on a major change involving getting more diagnostics data from the car I decided enough was enough. I build a special piece of hardware based on a “Wemos D1 mini” processor and a “HC-05” Bluetooth interface (eBay is your friend). It connects my WiFi network directly to the KONNWEI dongle in the car. The processor acts like a web server and all the primitives CanZE can ask the dongle, this little computer can too. In essence it is initializing the dongle, getting a free frame or a diagnostic command. Wemos runs about 1000 lines of C code to do that, part of which is very similar to the ELM327 driver in CanZE. Though CanZE is Java of course……..

This little thingy is now in the window sill near the car, while my desk is at the complete other end of the house. Total hardware cost is under 10 Euros, but of course many hours went into programming it. The Wemos is a fantastic implementation of the ESP8266 processor by the way, but I digress.

Next on my list: Modify CanZE (see process above!) so it can use http to get the data from the car. Not only would (notice that I am not saying “will”) that enable me to run CanZE from my phone while still at my desk, but it should also enable us to finally run CanZE in the Android Studio device emulator. There is one minor thing left though. The car must be awake for this to work. That usually means it should be on and started; in some cases, it just charging is enough. Oh well, we can’t have it all can we?

The AC charger cables have a resistor between protective earth (PE) and the proximity pin (PP) pin to indicate

  • that the plug is inserted
  • that the plug can therefore be locked (type 2 only)
  • the gauge of the cable, and thus the maximum current

Note that the PP pins are NOT wired through the cable. The most common resistor values and also those of your standard Renault cable are 220 ohms, corresponding to 6 mm2 and 32 amps continuous, and 680 ohm, corresponding to 2.5 mm2 and 20 amps continuous. These are per strand values and the power varies given the number of phases used.

These PP-PE resistors should be installed on both ends of the cable, which I had not realized before. Yesterday I helped a friend changing his home charger from a socket type to a fixed cable type, so that he didn’t have to get the cable from the trunk every evening. The cable came pre-wired with the resistor in the plug, but it didn’t work. Only when we installed a PP-PE resistor in the charger itself, indicating the cable was inserted on that end, the charger started the process. The other side effect is that if you measure the connectivity between the PP pins on your standard Renault cable, you’ll measure a confusing 440 ohms. That’s because both ends are wired to the ground lead with 220 ohm resistors.

1500 Ω resistor – 13A cable
680 Ω resistor – 20A cable
220 Ω resistor – 32A cable
100 Ω resistor – 63A cable

A (former?) Twizy and current Zoe driver in Austria called “AbRiNgOi” had a Twizplay laying around. This is an open source CANbus driven small display, based on Atmel micro controller. Anyone who has ever played with Arduinos knows what I am talking about. The specific controller used is an automotive version of an ATmega with a build in CAN controller.

He reprogrammed the Twizplay using the CANbus information that we gathered and that is available in the source code of CanZE on github. We are very pleased and proud that our hard work is spinning off toward other projects, in the true spirit of Open Source. Link here.

DSC02335

TwizPlay is originally programmed in BASCOM (a non-Free BASIC compiler for the Atmel and 8051 processors), but “AbRiNgOi” decided to do this the proper, but hard way and redo all using Atmel Studio 7 and C++, bringing it much, much closer to the Arduino community.

 

I finally got to the point to upload the firmware of my ArduinoDue and Teensy, but please be warned that it does not work the way I would like it to work!

Top