I thought dongles could not be further cost-optimized. Well, I was wrong. I ordered this as case / connector donor for a CanSee dongle. No screws, no wiring, blob processor. It cost me EUR 2.81 delivered, less than an empty shell. It didn’t work for CanZe of course.
A friend of mine received his ZE50 last week. Only a few days later we had a successful “CANbus sniffer session”. As I indicated in another post it seems the E-bus of the car, which in the past was wired directly to the OBD2 (SAE-J1962) connector, is now firewalled. And indeed, in the list of ECU’s of the ZE50 there is what is called a “Secure Gateway”.
First indications are the gateway needs to be mildly coaxed into letting us through, but for non-evasive stuff like CanZE does, there is no cryptographic authentication involved.
There are a LOT of new boxes in the ZE50. Some have 11 bit addresses, some 29 bits, and some seem to be able to use both. Let’s call that “interesting”.
So where are we now? Well, we have a few reasonable assumptions now. At the moment, I am making minor changes to the CanSee dongle so it supports 29 bits addressing and it’s internal table of ECU’s contains the new boxes. That is reasonably straightforward and almost done.
Next, I will add a simple screen to the experimental section of CanZE and see if we can make that work flawlessly. Just a few fields. To test that it will require another round trip to my buddy who will kindly let me plug in my gear into his car. This is a crucial step. If this goes as expected, the remainder is just work.
We need to upgrade the driver for the ELM dongles to enable 29 bit mode, and finally we need to go over each and every field to see if we can use the old definitions or need to adjust.
So, there is a plan now, there is decent logging data, and fairly good field definitions. But first I need to get rid of the flu 🙁
There is confusion about how to obtain the IDs of TPMS sensors. goingelectric.de user E-Gerd-21 figured it out in this post, thank you! TL:DR Use only the last 6 hex characters of the IDs that came with the valves. Those are usually 8 characters. If the first of those 6 is between 0 and 7, add 8 (hexadecimal, so i.e. if it was 3, add 8 becomes B). In other words, the first character should always be between 8 and F. This bit manipulation will be added in the next release.
Since there are different types of sensors, some are not compatible with ZOE’s TPMS system at all, and I read somewhere success entering the first 6 characters of the supplied ID instead. In other words, your mileage may vary. Of course the most safe option is to have the sensors installed once by the dealer and then read them with CanZE.
Finally, in the next release there will be a helper function swapping the front and back axles, simplyfying wheel swaps.
Rolling out as we speak. Among other fixes you can find in the changelog, here are the most important changes
Anyone who has played with the Research facility, or any log file really, knows the results can be massive and hard to process.
Massimo Ceraolo made a small post-processor that splits up the data per field, timestamped from start-of log. The output files (one per field) are pretty easy to convert into plots with Excel or other programs.
His software can be found here, the PDF has many more details.
In the upcoming release you can save and load two tire sets to phone storage. It was a deliberate choice not to store the sensor IDs in CanZE’s internal storage, because that disappears when uninstalling. The sets can be found as simple CSV files in the /CanZE/ folder on your phone. This addition should make it much easier to swap your winter and summer tires.
Note: to understand how the Research screen in the Experimental section works, see this post.
It is now possible to log positional data together with the other logged data. This functionality is only available in the Research screen. To use it, you need to manually give CanZE location permission in the App settings of your phone, enable location, and finally add the following line to your /CanZE/_Research.csv file
,800,24,31,0,0,0,,210e,610e,aff,GPS
Since GPS data are of course three numbers in one result, that result is presented in the log file as a string with the latitude, longitude and elevation separated with a /, for example
20191206160526974,800.610e.24,GPS,51.04594574/11.74158/407.0,
For the technically interested: this is a quite significant code change. Not only did we have to allow virtual fields in the Research screen, but also allow fields to be triggered externally. Normally, CanZE maintains a circular queue of fields it triggers to fetch from the car. In contrast, GPS events are triggered by Android itself, so instead of manipulating the queue and the process that handles that queue, now individual, virtual fields need to be enabled, started and stopped by screen starts, stops, pauses and resumes.
This feature is available in 1.50-beta3. I am pretty sure there are many kinks to iron out, so if you are interested, enroll in the Beta through the Play Store and put it to the test please.
Teaser alert: there is some exciting news coming up soon for the research and logger fanatics out there. But first, here is a recap of the permissions CanZE needs and why it needs it:
I have written quite often about our efforts to push back on crashes and ANRs (unresponsive screens). Up until now, and including the latest 1.49 release, our major tool for that has been the Google Play store. If enabled, your phone reports crashes and their call stack back to Google, where it is stripped from user identification and aggregated in our Play Store console. It works well, but it can give a massively false sense of comfort to the developers.
While not fully decided yet, we are implementing a Google product called “crashlytics” which goes a step further. When implemented, the crash reporting
We’ve read posts where applications reported tens to even hundreds of times more crashes than those coming back to the Play store and thus stayed under the radar. Of course we hope and think that this is not the case for CanZE, but we want you to have a trouble free experience.
What will you notice? Nothing at all. But be assured if/once implemented that every single crash will be reported and looked at.
As a test, this is now in the Open Beta channel.
