Hacking into Zoe's CANbus

[Zoelibat]

Mein Zoe schläft während des Ladevorgangs auch dann ein, wenn das Armaturenbrett an ist.

Tire Pressure funktioniert beim R240 vorzüglich. Das Auto muss dazu allerdings wohl auf Ready sein. Ansonsten zeigt es irgendeinen bestimmten Wert an (ich weiß nicht mehr welchen, auf alle Fälle ist er auf allen 4 Rädern gleich).

Der ODB Port schläft aber anscheinend nicht ein. Müsste man testen.

Einschalten ist ein guter Tipp. Habe es nur kurz getestet bei einem R240.

[jmeijer]

Sorry to be stubborn. Whenever the dash is on, the CANbus is very, very awake.

There is a difference between CANbus and power on the OBD2 plug. Power is ALWAYS on, it is directly wired to the 12 volt battery. The CANbus goes "silent" when the car is locked and dark. It takes a few minutes though. See http://canze.fisch.lu/resetting-the-cha ... situation/ the one-but-last paragraph.

That strange value for the tyres has been fixed a while ago. It was the value for "unavailable" and when the car sends it, CanZE displays a dash sign "-".

[AbRiNgOi]

Hi,

In a sleepiness night I checked the Code from the CanZE. I think, my problem with JAVA is not the time to learn it, the problem is, I really don't like it. Sorry for that, but CanZE is a great project any way. I found all the Information I needed inside. CanZE is a kind of big data and address copy process. Using the address Information out of a filed, you need in JAVA one A4 Paper code. To define the variables of the Object, defining the method for filling it with data, and defining the methods for getting out each. And that is using code already! But you had done nothing by now, only defining an object. And than in the "running" code, you using the methods one by one.... In c this is one definition without using code. Using this structure is only a used pointer, one single assembler instruction.
Than using a new object "fields" fivehundred times bigger. Do you really using all of this information? Why storing strings in SW code? A HEX number is good enough, and much smaller. Ok, that is JAVA, I'll respect this.
You see, I am from an other world. I learned programming in 80's in good old assembler. Seeing the code coming out of JAVA is a really shocking thing for me.
Then I tried to get out the handling of the "requestID" and the "respontID". I find out, the code is not in the App, it is a part of ELM327, using the feature Transportprotocol (which including the feature CAN-De-Multiplexing, to get more then 64 Bit out of one CAN message, very tricky to program) . That is good, so the sending of CAN Massages, witch is very dangers for the car, is done from an embedded SW part inside the ELM327. Also you are using three different CAN Ports (Vehicle-CAN, Engine-CAN, and M? why not using strings here?). Are this three CAN Lines really all located on the OBD-Plug?
For me, the Information is now: All the datas with no requestID (null || "" as written in your code) are seen from my software, for the rest we need to program TP2.0 and CAN-De_Multiplexing, because our Hardware has no Transportprotocol feature... We will check, if it is necessary to do so, or if the information on the Vehicle-CAN is enough for us. Using TP2.0 means sending CAN Messages, I really not so happy about that. The Information an this is for example the voltage of each cell. This could be a start of an "balancing-Index" Software code. But this software should be in c, not making a "virtual Field" (with strings an so on) only because a Information is using more then one CAN message like "kwh/100km"... (OK, this was the last hit to JAVA, I promise. The layer concept of JAVA is very clear, I should respect this)

PS: If the voltage of a cell is not displayed on your smart phone, perhaps your ELM327 is not supporting Transportprotocol...

So, thank you really very much sharing your code to me and bringing the Twizzplay project again on track. And, pleace, don't be angry about me, not joining your team and programming JAVA, I think this is not my world. Sorry.

[jmeijer]

Hi AbRiNgOi,

Your head-ups are truly appreciated. I come from the same heritage as you. 68000, 8080, 6502, 80286, C, C++, MASM, and now (just for hobby) AVR's and ARM's. If you want to have a rant about Java, feel free, but for an app for the masses, this is the way to go. And to be honest, while from that heritage, I do disagree with you on a lot of things, but this is not the forum to have that discussion.

As for using ELM dongles, that is very simple. We wanted to make this happen with ultra-cheap consumer grade hardware (we did start with custom hardware (Arduino Due) nobody would ever buy or build, and still use it for high speed analysis. You might have seen my youtube videos of those. We have to live with ELM's quirks and limitations, and there are MANY! It was a huge pain in the behind to push through these limitations, but to be honest, we feel proud we did it. We now have several hundreds of users and that would never have happened if we made it elegant from a systems design point of view. Nobody cares really.

Good luck with the project, and stay in contact please!

[Stefan_M]

Gestern habe ich eine erste Testfahrt absolviert. Das Teil macht Spaß! Wirklich guter Informationsgewinn, z.B. daß man beim leichten Treten der Bremse kaum was verschenkt, sondern wirklich nur die Reku pusht... ich dachte zuvor, ich hätte mehr Verlust.

Verwundert hat mich aber folgende Darstellung:

Bei Beginn der Reku bilden sich zwei Fraktionen. Kann es mir jemand erklären?

EDIT: Tapatalk hatte die Bilder vertauscht. jetzt korrigiert!

[Lokverführer]

Der obere Balken ist die von dir angeforderte Bremskraft, der zweite Balken die elektrische Bremskraft und der dritte Balken die Bremskraft der Reibungsbremsen.

Im Augenblick deines Screenshots reichte also die E-Bremskraft nicht aus und Zoe hat zusätzlich die Reibungsbremsen aktivieren müssen.

[jmeijer]

Almost correct

The blue "aiming" bar is what the car CAN brake on the motor. So there the requested braking torque is below that maximum. The car still brakes a tiny little bit on the friction brakes, probably that is either a calculation error or on purpose to smoothen the transition between motor and friction braking.

So, the aim is to not brake beyond the blue bar. This is also visible in the driving and the consumption screens. See also http://canze.fisch.lu/the-blue-aiming-bar-explained/

[Stefan_M]

Danke für die Antworten!

Meine Frage bezog sich auf das Bild mit den Zellspannungen.
Tapatalk hatte leider die Bilder vertauscht. sorry. Jetzt korrigiert!

Die Sache mit dem Bremsen ist mir soweit klar. Spannend war für mich aber, wie sich die Kräfte tatsächlich verteilen, weil das Auto mich hier ja im Ungewissen läßt. Ich hatte befürchtet, mehr wegzuwerfen und der Reku nicht soviel Kraft zugeschrieben. Insofern Daumen hoch für Auto und App!
Ein kleines bisschen mechanischer Verlust könnte ja sogar gut sein, dass die Bremse nicht vergammelt und im Notfall volle Leistung bereitstellen kann.

[jmeijer]

Bremsen: Agreed, it is a smart system! There is more on the CanZE blog on it. Search for "braking".

Cell voltages: Let it run for half a minute and it will look a lot different, more like in this post http://canze.fisch.lu/teaser-for-the-weekly-build-8/ (minus the faked defective cell, I hope!)

[campr]

I'm a Java developer with IntelliJ IDEA experience (no experience with Android) and finally got CanZE running in the emulator. Is it possible to simulate a trivial Bluetooth connection, so I can debug some displays?