iOS version ready
Today I got big news from Frederic RICHARD, telling me that the iOS version has been published in iTunes and available:
We are using the same issue tracker for both version, so you know where to go with whatever you will find.
Connected services – thoughts
No, we’re not talking about Renault Connected Services, we are talking about CanZE. Let me start straight off the bat with this: we always have been, and still are, extremely reluctant to add any sort of Internet based logging or data transfer, even with your, the users, consent. That stance has not changed. Anything written in this post is, at most, dipping a toe in the water and no indication, let alone promise that we will implement any of this in this branch of CanZE. Our reasons are twofold: we don’t want to be responsible for your data, and there are possibly serious legal risks associated, depending on country of driver, home country of developer and/or country where the data is stored, again, even with your consent.
That doesn’t mean we haven’t had requests of various kinds. And actually, there is a lot to gain from it too. For instance, if we collect State of Health data from a couple of hundred cars, we could give you a lot of feedback on battery degradation. We have an idea floating around the developers to maybe make this possible after all. Not only that, maybe to make it in a way that anyone can make such analysis if he prepared to invest a little bit in a couple of tools. Let me explain.
Using a protocol called MQTT, you, the driver, could publish a data stream coming from your car through CanZE. That encrypted data stream would be sent to an MQTT broker service of your own choice. In fact, an MQTT broker can be your own, i.e. on a Raspberry Pi, but there are also cloud based brokers, such as Adafruit.io and Amazon CloudMQTT. In configuring this, you can decide who can subscribe to your car’s data stream. Maybe you don’t want anyone to, and that is fine. Or maybe the entire world, and that is fine too. Services that are allowed to your data can subscribe to it and from that moment on, they receive updates as they are pushed from CanZE. For arguments sake, lets say this is once every 10 minutes while CanZE is running.
An MQTT subscriber can be anything. It can be a small micro-controller that only enables your home charger if your battery is more than 50% empty. It can be a fancy dashboard on your tablet. It can be a data logger. It can be the light-switch of your living room (I wouldn’t hook that up to the data from your car really!).
There is no inherent storage (unless you tell your broker it should), and there is no ownership and responsibility of the data but yours. Of course anyone who is allowed to subscribe to your stream could decide to log it themselves, but the matter of fact is: we neither operate the broker (you do!) nor do we want to. We, the CanZE team, can only subscribe to a data stream that you would have made public and are therefor already, by definition, public. Anyone could check if what we are sending is what we promised to send and not more too. The only thing we would appreciate is any sort of mechanism to be informed if a driver decides to create a public stream of her data. I am not saying this should be automated. Maybe just courtesy based, we don’t know.
MQTT is not very complex. Bare minimum you would need an account from a broker provider, fill in half a dozen fields in CanZE, and then most providers will allow you do start making web or app based dashboards.
We would like to know if people are interested in this approach, again without any commitment from our end. If you want to know more about the nitty gritty of MQTT, here is part one of a quite detailed description.
Charging and cosphi
Dutch forum member, Q210 driver and multifuntion charger builder “fivari”, posted this table today, stating charging behavior of the Q210 on a single phase line under chargepoint power conditions. Measurements were done in this order, so charginging definately starts at 8A. Three phase table will follow on a later date. Great info, thank you!
Pilot chargepoint (A) - Pilot CanZE (A) - Current (A) - Power (kW) - cos phi ===================== =============== =========== ========== ======= 6 no charging, pinkish dash 8 7 7,7 1213 0,66 10 9 9,6 1808 0,80 12 11 11,2 2281 0,87 14 13 13,1 2763 0,91 16 16 15,7 3374 0,94 18 18 17,3 3750 0,95 20 20 19,5 4271 0,96
Here is more data. Also Q210, now on a 3 phase settable charger. Unfortunately no real AC power data
Pilot chargepoint (A) - Pilot CanZE (A) - Available CanZE (kW) - DC CanZE (kW) ===================== =============== ==================== - ============= 10 0, not charging 3,0 -0.2 12 11 4,2 4.0 13 12 5,1 5,1 14 13 6,0 5.6
R240, now on a 3 phase settable charger.
Pilot chargepoint (A) - Pilot CanZE (A) - Available CanZE (kW) - DC CanZE (kW) ===================== =============== ==================== - ============= 6 6 2,4 1,2 7 6 2,4 1,8 8 7 3,0 2,7 9 8 3,9 3,4 10 9 4,5 4,0 11 10 5,1 4,7 12 11 6,6 6,1 13 12 7,5 7,0 14 13 8,1 7,5 15 14 8,7 8,0 16 15 9,6 9,1 17 16 10,2 9,5 18 17 11,1 10,4 19 18 11,7 10,9 20 19 12,3 11,5 21 20 12,9 12,0 22 20 12,9 12,0
Edit: We now have much more technical background, see this post and a few before that.
DTCs unraveled (teaser alert)
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.
Climate computer loosing it’s mind?
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.
Developers geek talk – part 2
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.
First steps into diagnostics
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.
Developers geek talk – part 1
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:
- Think of some great feature you always wanted to implement;
- Program it;
- Conclude you made some silly errors;
- Back to 2, when done…
- Download it to your phone;
- It crashes immediately;
- Back to 2, when done…
- Walk to the car, unlock it, wake it up, start Canze, wait for it to pair with the dongle, open your great new screen;
- It crashes immediately;
- 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…
- 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;
- It works! now at least test some of the old functionality!
- Old functionality is broken;
- 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?
Crazy Heater Hack
Sandy posted an insane hack on speakev to put the heater in auto mode but A/C forced off.
Teaser on diagnostics
Through a friendly forum poster we got our hands on some important CANbus message definitions that should enable us to massively expand on the diagnostics side of CanZE. Getting more information from the LBC (the controller within the battery enclosure) seems within reach. We will also try again to get to the BCB (charger) through the CANbus and if we can work that out, we might be able to get a lot of information from it. We still like to know WHY a charging sessions fails and the BCB is the computer that has that information. Stay tuned.