Pushing ourselves alsong, we’re far from done but will release in the production channel soon, even if far from all fields working for the ZE50.

Unfortunately, things area bit bumpy wen using the already slow KONNWEI 902 dongle. As we need to keep the gateway open, we hardly see three functional requests per second coming through. We might be able to optimize that further in a later stage, but success is not a given there, and it’s irritating. So if you are an electronics tinkerer, building a cansee dongle is more advised than ever. If not, we’re also investigating if we can finally make a jump to a branded, better, cheap, more potent dongle, possibly even on BLE. This will take time of course.

For those of you on the beta channel, you must have noticed the insane update speed. Things have been progressing at such a rate, it was useless to add blog entries. All ECU’s have now been added and you can play around with the firmware and alldata screens. Many regular fields have already been “ZE50-ified”, but there are still a lot to do. And there are a bunch that are simply not there anymore, so we might have to downscale a few things in CanZE for the ZE50, yet upscale others. Stay tuned, and if you are on the beta and running a ZE50, do contact the team on github to share! https://github.com/fesch/CanZE/issues

Thank you for your patience, and a very well deserved thank you to the new, relentlessly hard working new team members.

Late PS: if you are running a cansee dongle, you need to update it again. There was another bug found & fixed.

While working on the ZE50, we found a silly bug in the CanSee firmware. If…

  • you have a ZE50
  • you build a CanSee dongle
  • you want to be on the bleeding edge on the CanZE beta’s

… please update the firmware as soon as possible. You can find it here.

I am very happy and proud to announce that a small team of ZE50 owners with tons of technical talents coalesced the last week or so from all over Europe to take up where we left off what feels like ages ago on the ZE50. Leopold Baillard, Frederick Sommerfeld and Roberto Sonzogni caught up on the code in no time and started testing tons of fields on their ZE50’s. I can relate to the constant back and forth and sitting crammed with a laptop and cables in the cold, cold car.

We did some code cleanup and already added fields like the SOH. The pace is really high, and I just release our work in progress in the open beta. Feel free to punish it hard. Not much use yet in reporting “hey, this field doesn’t populate”, trust us, we know ๐Ÿ˜‰ But fields that give weird values of course need to be addressed. As always, please use the issue tracker https://github.com/fesch/CanZE/issue if you do.

Google has changed it’s storage model starting Android 10. Starting the next production release and also Beta1.53-3, we will be following their lead, which means log files, TPMS set files and the _Research.csv file will all be stored in Android > data > lu.fisch.canze > files now.

Note: We will not transfer old files to the new folder, so if you want to maintain your TPMS IDs, you need to do some copy-pasting yourself, or simply (re)type the IDs and hit Save.

The new storage model has a strange quirk that is relevant for the _Research.csv file only. On some, if not all phones, a file can be written through a copy, can be deleted, but not overwritten. Best practice at this moment is to maintain your file on your PC, and when needed on the device, delete the old file there, then paste the new version.

Long time no see.

Given that CanZE does not support the Ph2 cars, I am pleasantly surprised to see uptake still grow albeit more slowly. The last year saw an average growth of 22.5% or roughly 1.7% per month. It makes sense I guess as the pool of “Ph1” cars is now (very) slowly going down, but the technically inclined or more daring number of drivers is probably going a bit up.

Speaking of daring, this brings me to my second point. Somehow the “Force crash” option, only there to test Google Crashlytics behavior, made it in production by mistake. While there is a warning, it seems everybody wants have a go at it at least once: in the last 30 days, it was done 123 times by 77 users, go figure! Pretty daring indeed because who knows, maybe it would have crashed the car ๐Ÿ˜‰ Anyway, it has affected crash statistics pretty badly and we’re way over what Google deems “bad behavior”. However, if I take that cause out, it’s down 85%. I am not going to do a new release over this one, but if you can resist, it’s appreciated.

Stay healthy, stay safe.

Set point current (A)Power battery (W) *)Power AC (W)Current AC (A)Power efficiency (%)
20120221306019.26 **)92.1

*) Battery power (DC) was derived from CanZE, voltage times current **) There was an obvious typo in the data I received for this value, 19.26 is most probably the correct value but I must note this could be wrong.

I must say I am mightily impressed by these figures, especially the dynamic range of the efficiency. I hope this puts to rest the “inefficient” fairy tales. Very clever engineering for sure.

A lot has been written, assumed, wrongly (and rightly) measured and interpreted about the efficiency of the charger. The biggest problem has always been that the big capacitors in the the charger filter section create a fairly large phase shift (phi) so real power is not the same as RMS voltage times current. This is not inefficiency. It’s, at most, ineffectiveness.

I have been in contact with an Italian professor in Power Electronics and he has put an R110 on some serious lab equipment. The results are as follows

Set point current (A)Power battery (W) *)Power AC (W)Current AC (A)Power efficiency (%)

*) Battery power (DC) was derived from CanZE, voltage times current

Conclusion: If charging at a 16A setpoint (single phase), the efficiency is only a few percents lower than the highest measured. 85.5% is nothing to write home about but not bad. 80.7% at 16A is surely not as bad as some people would like you to believe.

I hope to get my hands on some 3 phase measurement. There is reason to believe the efficiency could be better, as there is a lot less curve following to do.

Note: I drafted this post in February and somehow never published it.

Github user SMCinc posted his research on ZOE’s TPMS system in CanZE’s issue tracker.

The proper TPMS sensors can be coaxed to transmit their ID using 125 kHz activation tool. Those tools are cheaper than a decent dongle. Search for “EL 50448”.

The transmission of the sensor can be received by a cheap DVB-T USB Stick with RTL2832 chipset and the rtl_433 software from Github and a Zadig driver (latter only if on Windows). It runs fine on a Raspberry Pi.

rtl_433 -f 434000000 -R 123

Here is example output


The ID of the the sensor here is A3FFDAD which should be entered in CanZE as