Category: Teaser

More to follow soon…….

No, we’re not talking about Renault Connected Services, we are talking about CanZE. Let me start straight off the bat with this: we always have been, and still are, extremely reluctant to add any sort of Internet based logging or data transfer, even with your, the users, consent. That stance has not changed. Anything written in this post is, at most, dipping a toe in the water and no indication, let alone promise that we will implement any of this in this branch of CanZE. Our reasons are twofold: we don’t want to be responsible for your data, and there are possibly serious legal risks associated, depending on country of driver, home country of developer and/or country where the data is stored, again, even with your consent.

That doesn’t mean we haven’t had requests of various kinds. And actually, there is a lot to gain from it too. For instance, if we collect State of Health data from a couple of hundred cars, we could give you a lot of feedback on battery degradation. We have an idea floating around the developers to maybe make this possible after all. Not only that, maybe to make it in a way that anyone can make such analysis if he prepared to invest a little bit in a couple of tools. Let me explain.

Using a protocol called MQTT, you, the driver, could publish a data stream coming from your car through CanZE. That encrypted data stream would be sent to an MQTT broker service of your own choice. In fact, an MQTT broker can be your own, i.e. on a Raspberry Pi, but there are also cloud based brokers, such as Adafruit.io and Amazon CloudMQTT. In configuring this, you can decide who can subscribe to your car’s data stream. Maybe you don’t want anyone to, and that is fine. Or maybe the entire world, and that is fine too. Services that are allowed to your data can subscribe to it and from that moment on, they receive updates as they are pushed from CanZE. For arguments sake, lets say this is once every 10 minutes while CanZE is running.

An MQTT subscriber can be anything. It can be a small micro-controller that only enables your home charger if your battery is more than 50% empty. It can be a fancy dashboard on your tablet. It can be a data logger. It can be the light-switch of your living room (I wouldn’t hook that up to the data from your car really!).

There is no inherent storage (unless you tell your broker it should), and there is no ownership and responsibility of the data but yours. Of course anyone who is allowed to subscribe to your stream could decide to log it themselves, but the matter of fact is: we neither operate the broker (you do!) nor do we want to. We, the CanZE team, can only subscribe to a data stream that you would have made public and are therefor already, by definition, public. Anyone could check if what we are sending is what we promised to send and not more too. The only thing we would appreciate is any sort of mechanism to be informed if a driver decides to create a public stream of her data. I am not saying this should be automated. Maybe just courtesy based, we don’t know.

MQTT is not very complex. Bare minimum you would need an account from a broker provider, fill in half a dozen fields in CanZE, and then most providers will allow you do start making web or app based dashboards.

We would like to know if people are interested in this approach, again without any commitment from our end. If you want to know more about the nitty gritty of MQTT, here is part one of a quite detailed description.

More teasers. Frédéric is still working on quite a few screens, but as you can see there has been a lot of progress!

We will release a new version today. As usual, a lot of under-the-hood things, especially reducing the footprint of the application and small speed improvements. No major changes, but you can find a detailed change list here but these are the highlights.

• Several improvements in the consumption graphs screen, including a low pass filter on the real consumption per 100 km line.
• Small changes in the logging.
• Added 12 volt reading (several drivers had flat batteries this winter) and the kilometers of the battery (if you had your battery changed) in the technical charging screen.
• Added an experimental screen with parameters about the battery-clima interaction.

Enjoy!

We are very close to releasing 1.09, probably today, and we are pretty excited about it. We have revamped the consumption screen substantially and we really believe you will like it a lot, especially if driving economically is your thing.

Let me give you a small run down:

• The Torque (Nm) bar from the driving screen, including the Blue Aiming Bar has been added to this screen. This will aid in avoiding friction braking (short term behaviour).
• The tiny consumption (kW/100km) dial has been replaced by a fat bar. This will aid in being a bit more gentle on the accelerator (short term behaviour).
• The first timed graph will show you the last couple of minutes (this depends on the screen-width of your device) of power usage and energy in the battery (long term behaviour).
• The middle timed graph shows Speed and consumption (long term behaviour)
• Finally, the last graph shows both the available distance as well as the SOC (we don’t want to start a war about what’s best, so we show both)

The short term behaviour bars assist in providing immediate feedback and feed forward. Avoid friction braking and decrease energy usage when driving and accelerating.

The long term behaviour graphs will give you nice feedback on how you drove that last part. It is very insightful how much that funny blast-off of your kitty-Zoe next to that ICE really cost.

In the technical part there is new screen “Charging Graphs” that will show you the technical behaviour while charging. You can record load balancing by the charger, where the power is limited, etcetera.

Other than that, of course the usual bug fixes, performance shaving, improvements on the graphs, etcetera. All in all there are more than 40 changes recorded.

Not many visible changes this week. Small changes on the charging and driving screen based on user feedback. In the experimental section, we added s tyres screen for cars equiped with TPMS. If you happen to have this feature on your car, give it a spin and let us know the results through github please (issue #235).

Under the hood we’re still working on strange Bluetooth instabilities and getting things back on track for the Kangoo and Fluence, which needs a lot of research.

We’re also working very hard on getting all the info we have (and not just the fields we use in CanZE today) in our database. It is a lot of tedious, lonely work but it is needed to move on.

You will not find many obvious changes this week’s release. We’ve taken a small step back from the rather crazy development cycle and the rest of our efforts have been focussed on fixing issues.

It seems we’ve been pushing the ELM a bit too hard; CanZE appears to freeze now and then, though it is usually the communication between the CanZE and the ELM. Please know it has our full attention, but it’s a hard one to crack as it’s really a bit of a random issue. We believe we’ve made some improvements though. Keep us updated (through github please!) and send us your logs please as it helps is pinning down what’s going on.

We’ve split the “Experimental” section into “Experimental” and “Technical”. Technical contains screens that should work, but are for the users that want to dig a bit deeper. At the same time, we’re cleaning up the “Main” activities to only display the information that matters most.

The Cell Voltages Heatmap has a new function that you should actually never see: if a cell turns bright red, it means it has a serious problem. The algorithm used is borrowed from Nissan: If the delta between the mean and lowest cell voltage is greater than then 1.5 times the delta between the mean and the highest cell voltage, it is considered bad. This check is only valid (and will only be performed) if the pack’s SOC is roughly 25% or lower.

EDIT: I was not aware that the Leaf uses a different chemistry for the battery than the Zoe. The red cell algorithm used may, or may not be valid. Don’t rely on it.

Here is a (faked) example

Have a great remainder of your weekend!

Last weeks release was not very stable with respect to the Bluetooth connection. A lot has been done to improve that, but if you have still have problems, please switch on “log to sdcard” in the new setting screen, so we might find some more remedies with the extra logs.

The Consumption screen has changed a lot and we hope you like it!

We removed a lot of overly technical information for the charging and braking screens based on feedback we got. Things are simpler now and more focussed on the things that matter. The old charging screen is still available in the experimental screen and we’re contemplating creating a third menu screen called “Technical” for the more detailed information.

As always, we appreciate your feedback. Enjoy!

This week we have above and under the hood developments for you.

We’ve added two heat-maps, giving a quick overview of your battery temperatures and voltages. Those will give you immediate insight in the overall stability of your battery pack: the colors indicate the deviation of the mean temperature / voltage.

Data for graphs is now retained much longer so your graphs will simply continue once you restart them.

Then there are some graphical updates, a bit better handling of different screen sizes. Also we’ve become a bit more aware of potential licensing issues so you might notice some different wording, removal of copyrighted graphics, stuff like that.

Of course there has been the usual bug fixing but we’ve also improved on the differences between the Zoe, Fluence and Kangoo.

Under the hood significant changes going are on. We’re constantly optimizing speed and memory usage and there are a lot of technical changes that you will notice above the hood too. One notable change is the ability to differentiate better between slow changing parameters, such as temperatures, and fast changing ones, such as speed. This way we can optimize display speed for the fast changing ones.

Also, there is now a setting to let CanZE continue to run in the background instead of closing or pausing. Note that this will use significantly more power on the device.

These enhancements create even more possibilities that we will announce and implement later.

DTC readout is already working for a few ECU’s, you can try in the experimental section (at your own risk!). It certainly works for the TCU (Telematics) and the CLUSTER (instrument panel).

We have some exciting news this week.

CanZE is now available in the Google Play Store. Once installed that way, updates will come to you a tiny bit slower, but fully automated. We will maintain a weekly release schedule as long as features are changed or added as frequently as they are now. When we’re confident that the updates in the Play Store come through fast enough, we might close the download page here.

We were able to shed a lot of code that was no longer necessary, meaning easier to maintain, and less error prone. We hope to have added again a bit of stability.

Also, we have gained a lot of information about the Zoe this week, straight from Renault. Consequently, we also now know that a few things in CanZE are simply wrong. Friction braking is far smarter in the car than we anticipated, and that code needs to be rewritten. The information came in too late to make to this weeks release, just know that the friction braking bars are not correct for now JUST made it in time for today’s release.

Also, the firmware screen was unfortunately picking up a wrong field. This has been corrected, but of course we need to work on reference versions again based on your input. Please do report newer versions if you see them in your car.