Category: Builds

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.

This morning I received a message from user @Minibiti reporting success on the ZE50 test code. This indicates our route to enabling CanZE for the ZE50 is probably solid. In aeronautical terms: the test flight was a success and we will now open up the envelope. Apart from a very small change that needs to be tested, it could be mostly boring table conversion work. Thank you Minibiti!

Minutes ago, I released a new beta. It contains, next to the usual array of small fixes, very limited proof-of-concept test-code for the ZE50. Select ZE50 in settings, ensure ISOTP fields is on, return to main, swipe to experimental and tap ZE50. Under the 4 meaningless lines it just might display the accelerator pedal position in %.

Please note that substantial changes in several places had to be made to make this work, and I do not have a ZE50 at my disposal to test. In other words, this is completely testing in the blind and anyone who has ever made any software knows where that leads to.

I’d appreciate feedback of course, if anything with debug files etc.

The good news is that as soon as this works, getting the current functionality of CanZE migrated to the ZE50 is straightforward.

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

• Forced light mode if your phone has a dark system setting but you want CanZE in light mode
• GPS coordinates can now be logged in the Research activity
• Option to save and load tire sets
• Climate control temperature setpoint is back

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.

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

• is done by CanZE, not by Android
• is still stripped from user identification
• reports all crashes, not just the ones enabled in Android
• can contain more information, such as the state of the application instead of just the call stack. This later works by the app saving some information to crashlytics. If the app runs fine, that info is discarded. If it crashes, it is send to the backend database together with the other crash info.
• is presented to us in a comprehensive console, with tons of filters, sorting, tagging.

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.

As announced. Two major changes:

• serious rewrite and testing of Tires screen
• cleanup of Bluetooth connection UI: title changes gone, BT icon now on all screens

Further details the change log and in the commit messages.

We might move to staged rollout in the future, meaning only a small, random percentage would get a new release first to allow a potential massive issue to show up and be addressed before a full rollout. With active user approaching 6000, this level of professionalism is becoming mandatory. As is the Open Beta of course for the daring.