A few weeks ago we announced a new release of CanSee. After running it for quite a bit, it’s now time for a true release. As said in the linked announcement, it is truly significantly faster and more stable.

If you have made your own version, you need to merge the changes, or (after checking with this release) issue a pull request so we can incorporate your changes, that have to be non-breaking and configurable of course.

We got contacted by Scott Heim, reporting how well CanZE can be used with a Chromebook. Here is what he wrote on RZOC:

Haven’t heard talk about using a Chromebook with CanZE. As I’m a computer geek & experimented with a cloud version of chrome. It gave me the idea a Chromebook would be perfect if it works. So local shop had a sale & Chromebook was at the price point. Took a punt, found CanZE was available for install. Did a little happy dance! Then the real test out in the car. At first had some issues, all turned out to be my stupidity. Chromebook turns out to be an excellent partner with CanZE & Zoe. Actually way more stable connection then I got using my mobile. Seeing Melbourne has had 200 days of lockdown, most with curfew & 5km distance. I been keen to see how my 12 volt battery was copping. It’s been quite a cold winter. The motorcycle required a new battery. As you can see my main battery has great health! Eventually I’ll get to enjoy Zoe, she is about to have her first birthday with 3050 km on the odometer.

Source: https://www.facebook.com/groups/RZOC.CLUB/permalink/2550694458407407/

Warning: this is a geek post pertaining to the CanSee dongle, not CanZE, nor the ELM style dongles.

In the CanSee design we’ve specified the SN65HVD23x chip to translate the micro-controller’s logic levels to the CANbus. The beauty of this series of chips is that it runs on 3.3 volt, thus requiring no level shifting and only one supply rail. As reported earlier we’ve seen many bad chips though. Lately I have been involved in a commercial project and we selected the same chip for the same reason. To make a very long (debugging) story short, faulty chips bit us again, and these were sourced through a reputable PCB manufacturer. I also received a few chips from a friend and again, one was bad. Either there is a huge manufacturing problem, or there is a massive batch of fake chips on the market, or these chips are extremely prone to damage.

This problem has been haunting us for well over a year now and after wasting many, many hours again sifting through chips, re-soldering, messing with the firmware, and countless other botches, the camel’s back has now definitely broken. I am changing the public design to set the DC-DC converter’s voltage to 5V, use that to supply the development board AND the alternative transceiver chip (an NXP TJA1050). I’ll also add two resistors to level-shift the signal from the transceiver to the ESP32.

We’ve made a significant change to the CanSee dongle firmware. Nothing is visible from the outside of course, but internally, the CANbus driver we used earlier has been replaced in it’s entirety with the native driver supplied by Espressif, the supplier of the ESP32 micro-controller used in a CanSee dongle. This solves a problem when using the most recent wafer versions of the ESP32 (v3) with the bus speed, and improves stability significantly.

This change is published in the development branch of CanSee and under test right now. Feel free to grab it and give it a spin. If we don’t encounter issues it will be released to production in a few weeks.

For those of you wanting to delve into the technical nitty gritty of things, here is the explanation. If you are into the ESP32, using it’s CANbus controller, and doing so using the Arduino framework, I would urge you to have a good look at that comment and it’s follow up. It took me way too long and way too much head scratching before I ran into that post and have my “ah-ha” moment.

If you have copied the code for the Node-Red implementation of the Renault API, be aware that the the kamereon_api key has changed. A few clever people figured out they are distributed using Google Firebase instead of in the code of the app, so decompiling is now useless. However, it’s pretty much all over the internet now, so here is a link to as far as I could quickly follow back.

BTW, there are now many more implementations for Node-Red.

With the addition of the Ph2 and the new settings it’s fair to say we were not up to snuff when it comes to app stability. In December we significantly went over Google’s “bad behavior” benchmark when it comes to app crashes. As written earlier, we’ve been daily checking and meticulously cracking these and older lingering bugs and mostly updated weekly to avoid those from re-appearing. I am happy to announce that this weekend we lost the red “bad behavior in the last 30 days” tag.

We continue to trace and if anything possible fix each and every crash we get reported and release those fixes within a week of receipt. This is by far the most important reason for seeing recent updates in the play store and we appreciate you installing them to keep user experience as good as possible.

ISOTP is a protocol to transfer messages larger than the maximum CANbus frame size of 8 bytes. While it’s purpose is only this, it is usually associated with diagnostic, request-reply type of traffic, as opposed to the broadcast “free frames” type of chatter.

When we started with CanZE we had more information about the free frames and while it is a real pain the xxx to implement and requires commands not available in cheap clone dongles, we also prefered it as it did not require us to inject any traffic whatsoever on the car’s CANbus.

Things have significantly changed since. Using diagnostic commands exclusively has a couple of advantages

  • it’s a given on the Ph2 vehicles. No way to get to it’s free frames;
  • it’s commands are fairly well documented from more or less public sources;
  • some data is simply not available on free frames;
  • more dongles will work without using free frames.

So, the setting for ISOTP are as follows, though they may seem a bit counter intuitive.

  • For the Ph2 cars, it has no meaning. We should probably disable it.
  • For Ph1 cars, if using a CanSee dongle, we nudge ISOTP off, as it’s the fastest option and works fine. If using a commercial dongle, we nudge it on.
  • Nudging means: it will save as set, but every time you open the settings, it will switch it again to the preferred option.

All in all, we might decide to get rid of the entire option as it’s confusing. If there are strong opinions either way, let us know.

Renault changed it’s API totally for the complimentary MY Renault app. Muscat did massive reverse engineering, implemented a python library and CLI. I implemented that in Node-RED. Please note there is zero error checking. The bottom two rows are examples that can be fed the same message as the Get battery status node.

Please note that the API has changed again. The current implementation is here.

The kamereon_id key has changed early 2021. See this post.

Another episode of the 4-weekly statistics and some additional information

  • Growth is steady. Last month we’ve seen a 4% increase.
  • Crashes and ANRs (unresponsive screens) are again slashed. In the last 7 days (Taken because now most are on 1.37):
    • we have seen zero ANRs, cool!
    • we had 4 crashes, two were instances of the same problem.

The 30 days crashes and ANRs statistics now put us way above the “bad behavior thresholds” google has defined, and solidly into the second quadrile of all applications. We strive for the third quadrile, meaning less issues than the median of all applications in the Play Store. Though you might not notice “less crashes” actively as a user, it is improving the perception in the long run a lot. It is also bloody hard work!

ANRs and crashes are measured as percentage of affected daily sessions, where a daily session is defined as a day where an individual user used the app at least once. For example: suppose on Monday 20 users use the app once or more, and on Tuesday 30, then there are 50 daily sessions in those two days. If one user has 2 crashes on Monday, it counts as one affected session. If no crashes occurred on Tuesday, the crash rate over those two days is 2%. Google defines “bad behavior” for crashes as more than 1.09% over the last 30 days. Given that we see roughly 100 reported daily sessions per day, only one crash per day is “allowed”, though the median of all apps is 0.32%.

Now there are two important notes to address:

  • We only see total numbers. The reports are heavily anonymized and not generated at all if the total number of daily sessions for them is too low. This seems to be to avoid pinpointing users, which is a good thing. Though I admit I sometimes see errors where I think “how did the user manage to do that?”
  • Only users who allow sharing of usage and statistics provide this data, so we have no way of knowing how many actual daily sessions are operated. While we understand the privacy impact, especially towards google, we are very grateful to users who do have this option set to on as it allows us to notice issues and act fast on them. To check or change: Settings > Google > Three dots menu > Usage & Diagnostics > On / Off