2017.02.12 [Jeroen] Added total energy to ChargingTech #430
2017.02.12 [Bob] Spanish language file added, many thanks to the contributors
2017.02.11 [Jeroen] Improved code to get DTC's
2017.02.11 [Jeroen] Added TCU to the DTC reporting
2017.02.11 [Jeroen] Changed http interface to use RequestID instead of ResponseID
2017.02.09 [Jeroen] Added compressor RPM graph (0-4000) in climatech
2017.02.09 [Jeroen] Fixed Y axis on ChargingGraphs for model 90s
2017.02.06 [Jeroen] Fixed formatting problem in ChargingTech
2017.02.05 [Jeroen] Code fixup on getting strings from language packs
2017.02.05 [Jeroen] Added debug lines to all running screens
2017.02.05 [Jeroen] Lots of code and layout cleanup
2017.02.03 [Jeroen] Allow operation without BT adapter so runs on emulator
2017.02.02 [Jeroen] Fixed ELM test #427
2017.02.02 [Bob] Merged German with file received from Roland Klose <rkl.fritzbox@gmx.de>
2017.02.02 [Jeroen] Compressor power dissed, replaced with RPM.
2017.02.02 [Jeroen] Hotfix on master: log level #417
2017.02.02 [Jeroen] Added German (Thank you Stefan!)
2017.02.01 [Jeroen] Climatech, climate replaced power by a graph
2017.01.31 [Jeroen] Added Slovenian (Thank you Zdenko!)
2017.01.27 [Jeroen] Climatech, Power as extra field

From day one we’ve had a love-hate relationship with the dongles. We love them being cheap, available, consumer-grade devices anyone can get on the cheaps and just use them. We hate the instability, how slow they are, the version issues and the complicated way to interact with them. They’re totally unusable to analyze what is going on on the CANbus.

When we started getting our feet wet and didn’t know anything about what was going on on the CANbus we started building our own hardware. Alex and Bob used AVR powered Arduino’s with an external CAN controller, I myself build a derivative of EVTV’s CanDue, based on a fast but not very popular ARM powered Arduino Due. Data was then pushed over serial (USB or Bluetooth) to a PC or tablet for further processing. This of course was totally not consumer rated, but it enabled us to really see what was going on in the car. There are some video’s on youtube of us struggling with that: the AVRs were lacking processing power, and the Due was more bulky and had to be hooked up to a PC using USB.

Fast forward two years and with the fast, small and WiFi enabled ESP8266 processor taking over the role of many AVRs in hobby projects, it was time for a new experiment. I connected a WeMos D1 Mini processor (bottom PCB) to a cheap external CAN controller board (top PCB) featuring an MCP2515, the bigger of the two chip and unfortunately a TJA1050. I had to either replace that chip with an SN65HVD230 or or modify the board a bit for 3.3 volt usage and choose the latter.

Be careful with the pin layout. The ESP8266 is VERY confusing: GPIO numbers, WeMos pin numbers, notation with D-prefixes and without. Most of that stuff is documented in the source code. Oh and I found a really tiny 12 -> 5V buck converter. It is minuscule, tucked away under the WeMos.

On the software side I started with the code for the http Bluetooth gateway, removed all code for Bluetooth and the dongle and added in code to use the CAN controller. This opened up a wealth of possibilities:

  • Fast WiFi interface, fast direct PCI connection to the CAN controller
  • Can auto-connect to the home WiFi network, or act as an access point;
  • Very small footprint (4 x 6 cm PCB);
  • No changes in CanZE and other tools needed as the http interface is exactly the same as for the gateway;
  • Processor easily keeps up with the bus speed;
  • Multi-frame handling (ISO-TP) completely offloaded to the ESP8266.

The device is more functional than an ELM327, completely programmable (watch this space for more functions beyond CanZE) and most of all FAST. You can see how fast here

Zoe’s error messages to the driver are not always crystal clear. This one usually points to a failure in the 12 volt system.

There are basically two reasons why the 12 volt system can be compromised (barring real faults somewhere in the electrical system):

  1. failure of the 12 volt lead acid battery
  2. unexpected drain of the 12 volt battery (leading very very quickly to 1.)

Let me start by saying the 12 volt system feeds anything and everything that is not traction or the air conditioning compressor. For the non-Nordic version, it also feeds a few rheostats for fast wind shield defrosting. It’s all pretty beefy but still it can drain fast. Remember that all 16 computers are powered from the 12 volt system. If this bus runs bad, literally nothing will work as expected, if at all really.

Renault has the lead-acid battery replacement in their schedule set for after 3 years. This does seem pretty short indeed, but given the above, I wouldn’t dismiss the dealers suggestion for replacement flat out. If you are in doubt, at least have it tested. Lead acid batteries are loosing a notoriously amount of capacity when it gets cold, and you don’t want to get stranded with a full traction battery, but a dead 12 volt system. And if it’s dead, the computers are dead, and there will be no way to bootstrap charging it without hooking it up to an external 12 volt battery charger. Been there, read on.

Unexpected drain is pretty hard to do. The auxiliary power shuts off when the car goes in sleep mode, so even leaving on some sort of accessory through the lighter plug should shut down.

There is one scenario however, which I am pretty sure happened to me. The charger plug was not seated properly, or at least the car thought so. You can actually detect this when the motor lock retries every 2-3 seconds. This retrying continues forever and while this is going on, the car is fully awake, all computers are on, the lock motor is being fired continuously and of course no charging is happening while there is a serious load on the 12 volt system. Now one could think the 12 volt system is being replenished by the traction battery, but it isn’t. The lead acid battery was drained down to 5 volt in a few hours at which point the car went completely dead. 5 volt is devastating to a lead acid battery if not quickly charged. Luckily, I found out and diagnosed this within a few hours of it happening.

I couldn’t bootstrap the car “in situ”, because as soon as I connected my small 12 volt car charger to the battery, the car woke up, started to initialize all it’s systems and while doing so overwhelmed the charger. I removed the mass cable from the battery and charged it for an hour. After that, the battery had enough juice to pull the car through it’s initialisation. I then was able to remove the charger cable, hooked it up again and charged the car normally. The error went away after one cycle.

In the previous episodes of developers geek talk I explained a bit how the hardware you use is terrible for actual software development. Sitting in a cold car, often at night with a laptop is no fun, and the process is slow. The http gateway changed a lot in that respect. We can now test new features in CanZE without having to leave the desk. So code, upload to the phone and it will get to the car over WiFi through http and in the car itself it is still using a real ELM327 KONNWEI 902 dongle. More about an alternative approach in another episode of geek talk.

Another benefit is that CanZE can now be run in an Android Studio emulator. Here you see an emulated Nexus phone running CanZE on my Ubuntu laptop showing the latest Climate screen. I went outside while it was running an pushed my hand against the outside temperature sensor that is mounted under the right side mirror. We can now test different screen sizes and orientations too without actually owning such devices. All this has never been possible as the Android emulators do not support Bluetooth. Also, we can quickly test different language settings without messing up our own devices.

So now you know why the latest release of CanZE asked for network permissions: next to using Bluetooth to get raw data from the car, it can use WiFi or even the Internet over the cell network to get that data through a gateway.

Things have not been quiet since the last release. In the development version, more languages have been added (German and Slovenian), thanks to several volunteers. Thank you! Also, a new release makes users go through a lot of screens and quite a few bugs have already been found. And fixed. We try not to do hotfixes, unless (like with this last release) CanZE really crashes. So, the more benign bugs are fixed or being fixed in the development branch.

As always, feel free to report issues on the github issue tracker, where you can also see what other reported and what has already been closed.

We also got some feedback on the new “Clima” screen. Notably, there was a request to also show the power the climate system takes. This has not been proven possible (maybe “not yet”, see below), so after some experimentation, we added the compressor RPM as a separate graph to the climate screen. Here’s a teaser (pardon the Dutch).

Finally, we are very happy to have been able to crowd-fund the acquisition of a CLIP system (yes, a clone). Many users made a contribution to make this possible. Thank you! We really hope we can dissect the BCB (the charger) with it, as it is unwilling to give us it’s secrets just like the other computers do. Stuff has been ordered and we can’t wait to get our hands on it. We’ll most certainly report back here when it’s arrived, and later if it was able to give us what we want! Stay tuned.

With the release of version 1.21 CanZE (Android version) is now officially a multi-language application. We have included English as default, and locales for Dutch and French. German is on it’s way. The language files are roughly 350 lines of XML. If there are volunteers who would like to see other languages added we would be very grateful and of course will be happy to include them. You can grab the complete English file here which contains as you know them, including untranslatable ones, and any of the other files (Dutch, French) as a template on how to format your language file.

The best way to get the file to us is by dropping it as an attachment to a new issue on GitHub.

Hi

Version 1.20 has been dispatched by Google’s Playstore, but I got noticed that it crashes on some devices. If you want to help or get some details, please go here:

https://github.com/fesch/CanZE/issues/407

In order to fix it, we need to be able to reproduce it, so reporting every setting of your device may help us! We introduced localized strings with this version, and probably this is the reason for the crashes.

Edit: On first glance, it seems to be related to the SD card logging, Fields option switched on. If true, switching it off is your temporary workaround until we have fixed it, but we would appreciate if you could report on the issue tracker above if this matches what you are experiencing.

Edit: hotfix (1.21) is being deployed now.

We are close to releasing the next version, probably next weekend as we test for silly errors this week. Features:

  • Multi-language is now possible, and added languages (Dutch, French, and we think we’ll manage German too. Thank you all volunteers!)
  • Added a lot of diagnostics. This part still needs a lot of work. For some known ECU’s you now have:
    • Real descriptions of DTC’s, something like “Battery voltage:value below threshold”;
    • Dump of all diagnostic parameters to a file.
  • Added a Climate screen;
  • Changed the Firmware screen. This more expanded info is needed to import ECU definitions. More on that in a separate post later;
  • Lots of bug fixes in graphs and layouts.

Under the hood things have massively changed too.

  • Tons of cleanup, added comments and removal of old code;
  • Simplified and improved our development chain;
  • Improved and sped up existing code.

We’re still struggling with unstable Bluetooth and getting access to the BCB. We are working on both though.

Please note that this release of CanZE will ask for a new permission: Internet access. We use this only to have CanZE access a WiFi gateway (or a car emulator that uses the same protocol), see Developers geek talk . Regular users will probably never use this. Internet access is not used to send any data to the Internet. We have not implemented MQTT, we are not collecting any data, nothing.

See this post for details. Yesterday I was charging at a Fastned station to test out an issue with harmonics. That went fine. Fastned here is a provider doing only high power charging and only at stations along the highways. Their equipment is supplied by ABB. What never happened before, I was bitten by this issue. One can argue (and I am one who does!) that the pin lock mechanism, and especially the micro-switch is a flimsy design. However, the plugs at those Fastned designs are simply insane. The thing is so long and the cable is so heavy that even my never-had-this-problem-in-three-years ZOE not only had a hard time locking the plug until I supported it while it tried, but the force pried the switch open after it was locked, already charging and I slowly let go. Immediate interruption of the charging process, BCI level 1 (just retry)  and after three tree times red nose and BCI level 2, rain dance ™ required. What a pain in the behind! In the end I repositioned the car and “draped” the cable in a way it sort of supported itself more or less and then all was dandy, see picture.

This is two rather lousy designs conspiring together to not make things work. What on earth were they thinking?