Home › Archive for Geek talk › Page 3

Category: Geek talk

By Posted on Posted in Geek talk

For those of you deep into home automation, using documentation compiled by Terrence Eden, me and Harm Otten wrote some Node-RED code to retrieve battery status from the same API that the the Renault Z.E. app uses. I’ve posted it on gitlab.

It outputs an MQTT message every 15 minutes. If there is more than one car associated with the login, more than one message is sent. A message looks like this

{“charging”:false,”plugged”:true,”charge_level”:100,”remaining_range”:132,”last_update”:1514654435000,”charging_point”:”INVALID”,”age”:”6:45″,”VIN”:”VF1AGVYA…..”}

In my setup the message finds it’s way to a dashboard on my Android phone using MQTT dash, a Node-RED dashboard and like all other MQTT messages a MariaDb database on my Synology NAS for logging.

By Posted on Posted in Geek talk, Twizy 5 Comments

Thanks to the kind people running the OVMS project, we have access to quite a bit of documentation on the Twizy. Unfortunately, the current developers are unable to implement this knowledge into CanZE, mainly because lack of Twizy to play with :-). If developing CanZE taught us one thing, it is that it is virtually impossible to add functions without the car available; remote testing simply doesn’t cut it.

So, if any volunteer is available, we would be happy to take him or her into the team. There is no hard prerequisite (hint: when I started I had not written a single Android program), but it would be fair to say the following would help, in diminishing order of importance:

  • Owns a Twizy, ELM dongle and an Android device, and is willing to play and experiment with it;
  • Can bear to stumble along and spend too much free time;
  • Has done some development in Java or C++;
  • Has done some Android development.

We would love to hear from you!

By Posted on Posted in Geek talk 11 Comments

Chris sent me a very interesting dongle. It is called a Freematics ONE. The simplest way to describe it is it being an ELM327 CANbus interface, plus a fully programmable Arduino UNO, plus an SD-card interface, plus a Bluetooth interface, plus serial-over-USB (oh yeah, could do a fast, wired CanZE version) plus an accelerometer, plus (optionally) one of WiFi, GPRS+GSM or xBee modules. Pricepoint is not crazy expensive: a bare version would come in at 70 USD.

I am still figuring what to do with it, but it sure is a great datalogger. And assuming the ELM327 “look-alike” chip inside is reasonably compatible with the V1.5 dongles we use, the Arduino code is in large part available, as I made that for the WiFi gateway. Anyone got cool ideas?

By Posted on Posted in Geek talk 9 Comments

We received a CLIP clone today. CLIP is the tool that your Renault mechanic will use to diagnose any of the brand’s cars. The tool was very kindly financed by “kick-starter” style funding on the Dutch and UK forum. Thank you all for that! Reason I asked for it was that we really like to get to the data of the BCB (the charger inside the car) and we haven’t been able to figure out why. This post is a short update.

Let me first say, the hardware is a serious piece of kit. You have seen your dongles and my interface s and that´s child play compared to this. Two rather massive 4 layer PCB’s plus a connector PCB. Admitted, it seems the hardware can do ISO 9141-2 next to CAN, but the ZOE doesn’t use that. Anyway, it explains the price-point somewhat.

The good news is that it works. Somewhat. As ar as we understand Renault is pushing more and more functions to their central services and there is very little we can do with the tool without online connectivity, which we obviously do not have. Or maybe we do not understand it yet, which is a possibility.

Still, it’s able to run a diagnostic script on all computers of the ZOE and extract their DTCs, including a more extensive context. In theory, that should be enough to teach us how to get at least some data from the BCB. Stay tuned for updates.

By Posted on Posted in Geek talk 7 Comments

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

By Posted on Posted in Geek talk No Comments

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.

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 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?