Home › 2016 › December

Month: December 2016

By Posted on Posted in ZOE 2 Comments

Truth to be told, the DTC READOUT screen never worked very well. Codes did not always appear and when they did, well, it was just codes. Not anymore in the next release! We’re adding the actual meaning of the Diagnostic Trouble Codes for every computer we have them for. Here’s a little teaser screen, showing the result of querying the Uncoupled Brake Pedal computer of my ZOE:

Let’s dissect the second one. 405155 can be split in three parts. The first one (4) means it is usually displayed on diagnostic tools as “C0”, meaning it is a SAE  standardised chassis trouble code. The next 3 (051) define what hard- or software component of this computer is causing this DTC. Here it is the Steering wheel angle sensor, which is interesting as it is part of the Power steering (EPS), not the UBP. The last two hexadecimal numbers indicate what test triggered this DTC to be fired. Here (55) it is “Not configured”. Finally, zero or more flags can be sent with the DTC. In this case the “testNotCompletedThisOperationCycle” flag.

This particular DTC is completely benign. If a flag called “warningIndicatorRequested” is included, we’re in different territory. It  means the orange spot light in the dash comes on.

By Posted on Posted in ZOE No Comments

I read quite a few complaints about the heater system. Not that it’s a bit underpowered, but really off, as in just blowing cold air when heat is requested. I am more or less trying to compile a list of user-fixable, or -detectable causes, from what I read on forums. Please comment if any of what’s listed here is wrong by your experience, or right!

  • Low on coolant gas. Rattling sound by the compressor. Dealer trip needed. CanZE might help, it shows the gas pressure after the compressor. It should be around 4-5 when idle and around 20 when working hard;
  • Cabin sensor. It is at the bottom of the rear view mirror mount on the wind shield;
  • CLIM computer bug: it is said that in combination with or after a demist, the car can refuse to heat. I am not sure if a hard reset (next bullet) is needed, but one could at least switch de-misting off;
  • CLIM computer lost it’s mind. Things happen. Pull/push fuse F3. It is the rightmost column, the first fuse counting bottom up in the fuse panel in the cabin. Should be a 10 amps fuse.

Some people have reported heating the outside temperature sensor to roughly 50 degrees using a hair dryer or a hot towel (it’s the dimple under the right hand side wing mirror) also seems to kick the computer’s logic.

Edit: see this post for a follow up.

By Posted on Posted in Geek talk, Hardware No Comments

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.

By Posted on Posted in ZOE 4 Comments

With mentioned gateway now in place, and the car happily charging (therefor awake) in my front yard, and what seems to be a fairly good description of all diagnostic fields, it is SO much easier to peek into the car’s diagnostics. So, on my laptop I made a little program plowing through the database of diagnostic commands of the EVC (motor controller), the LBC (battery controller)  and the CLIM (heater / airco computer), request every known diagnostic frame, pull out the values of each frame and write that back into the database. We are talking over 3000 values for these 3 computers only.

I can see the pressure in the Airco circuit, which is not fairly low as it was not running, but laso things like the positions of every airflow valve.

Here some data from the LBC.

By Posted on Posted in Geek talk, Hardware 4 Comments

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?