Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[gt13013]

My Zero is a 2016 FXS with 2 battery packs. I have kept the original firmware until July 2021. It was :
   Firmware rev.      47
   Board rev.         3
But in July 2021, the controller died, and has been replaced. At the same time, they made a firmware upgrade. The new one is:
   Firmware rev.      56
   Board rev.         3
They also changed some internal parameters of the bike.
Since this intervention, I get strange behaviour of the SOC (mainly decreasing and rising inconsistently, since it now depends mainly on the battery voltage, whereas with the old firmware it was more clever and it gave pretty good estimations of the SOC), and the range has decreased.
I looked  at the logs in detail, and I noticed this strange thing.

When I key the bike on, there are two lines of this kind that appear in the log. They apparently give information about the two battery packs. I have kept all the log files of my bike, and for all the logs before the intervention, the two lines show very close values. Here is an example:
   Module 00 Closing Contactor  vmod: 109.052V, maxsys: 109.049V, minsys: 108.938V, diff: 0.111V, vcap: 96.562V, prechg: 89%
   Module 01 Closing Contactor  vmod: 108.916V, maxsys: 109.049V, minsys: 108.938V, diff: 0.111V, vcap: 96.562V, prechg: 89%
Here is another example, before the intervention :
   Module 00 Closing Contactor  vmod: 102.946V, maxsys: 102.985V, minsys: 102.926V, diff: 0.059V, vcap: 91.125V, prechg: 89%
   Module 01 Closing Contactor  vmod: 102.990V, maxsys: 102.985V, minsys: 102.926V, diff: 0.059V, vcap: 91.125V, prechg: 88%

But since the intervention, the two lines always show very different values for vcap and prechg. Here is an example:
   Module 00 Closing Contactor  vmod: 105.837V, maxsys: 105.886V, minsys: 105.837V, diff: 0.049V, vcap: 93.312V, prechg: 88%
   Module 01 Closing Contactor  vmod: 105.880V, maxsys: 105.891V, minsys: 105.880V, diff: 0.011V, vcap: 105.500V, prechg: 100%
Another example:
   Module 00 Closing Contactor  vmod: 101.966V, maxsys: 101.979V, minsys: 101.966V, diff: 0.013V, vcap: 90.562V, prechg: 89%
   Module 01 Closing Contactor  vmod: 101.973V, maxsys: 102.025V, minsys: 101.973V, diff: 0.052V, vcap: 101.625V, prechg: 100%

I wonder if something was not badly reprogrammed during the intervention.
Some questions:
1) What are the values of vcap and prechg representative of ?
2) By the way, same question for vmod (I assume the present module voltage?), maxsys, minsys ?
3) Can it be related with the strange behavior of the SOC ?
4) Is someone understanding what happened ?
5) If someone has a modular FXS or FX, I would like to know if they have the same strange logs as me
 
Thanks for reading this long message

[sharagan]

I have a long brick in my FXS, but the log still shows 2 modules
 00094                       0   Power On                   Key Switch
 00095                       0   Key On   
 00096                       0   DEBUG: Module scheme changed from None mode to Stopped mode   
 00097                       0   Module 00                  vmod: 0V, batt curr: 0A
 00098                       0   Module 01                  vmod: 0V, batt curr: 0A

all the prechg entries are always 87%, 88%, 89%.

maybe this helps

[rgutt]

1) vcap is the voltage across the input capacitors in the Sevcon; prechg is the percent of the capacitor voltage relative to the battery pack voltage.

2) vmod is the battery pack voltage.

3) No, and I don't know the specifics of the SOC calculation Zero uses. Other than the convenience of an accurate fuel gauge though, the algorithm is irrelevant to the range and power you can make at any time. If the new SOC calculation is based strictly off battery voltage, even time averaged for some smoothing, I would expect it to fluctuate up and down a lot based on the load on the motor.

4) The differences you see in the before and after logs could be as simple as a change in the timing of when the values are polled by the Sevcon and posted on the CANbus or an actual change in the timing of when the MBB closes the main contactor(s) after the Sevcon has indicated the precharge capacitors have reached adequate charge. It's possible that the old firmware closed the contactors for both modules simultaneously and the new firmware staggers them. Since the power is going into a single motor controller, either way is just fine. The staggering of the contact closure could have a slight edge when it comes to contactor and capacitor longevity, but I suspect the effect would be negligible relative to other failure sources for those components. Whatever the reason, that activity has no bearing on your SOC.

5) Sorry, I don't have an FX or FXS, so I can't help you there.

[gt13013]

Thanks a lot for your inputs !

rgutt :
You gave the answer. Indeed, before the intervention, the 2 contactors closed at the same time (I remember that somebody on this forum told me that I should hear 2 clicks, but I was only able to hear one). And starting from the intervention, I now hear 2 clicks when keying or charging the bike, with about 1 second delay between them.
With your explanation in mind, it is now clear that these reported values of vcap and prechg have nothing to do with the SOC.

Concerning the SOC, there has been a clear change linked with the firmware update. Before the update, the SOC was very helpful. Now it fluctuates a lot and seems directly linked with the battery voltage. During the same travel, if I go a little bit faster (fast lane at 90 km/h = 56 mph for instance) the SOC can go down very quickly, but as soon as I slow down (and just after in the same travel, without stopping the bike in the meantime) the SOC can rise by 5%. I have used the old firmware for 4.5 years and I don't remember seeing this behavior: the SOC was always decreasing during a trip.

Note that, in almost all my BMS logs before the intervention, during charging I got lines telling that SOC mode changed from "voltage mode" to "Coulomb counting mode", such as
  DEBUG: Switching to voltage SOC mode
  DEBUG: Switching to coulomb couning SOC mode
I join a file with these lines in their context.
But since the intervention, these lines did not appear anymore.

I have also noticed, that after the intervention, almost each time I turn on the bike I get the warning "Max allowed voltage difference is 500mV". I did not get this warning before the intervention. There is less than 500mV difference between the two battery packs. Which are the voltages that differ from more than 500mV ?
More details in the attached file.

sharagan:
OK, I take note that the long brick FXS is obviously physically different from the model with 2 removable batteries, but seems to behave electrically in the same way.
From your observation and from rgutt input, I guess that you get two simultaneous contactors clicks when you key or charge the bike. And very probably you do not have a very recent firmware. Which one ?

Thanks again.

[TheRan]

That voltage difference will probably be the cell balance, leave you bike for a little bit after it gets to 100% and it should be sorted.

[rgutt]

Thanks a lot for your inputs !

Concerning the SOC, there has been a clear change linked with the firmware update. Before the update, the SOC was very helpful. Now it fluctuates a lot and seems directly linked with the battery voltage. During the same travel, if I go a little bit faster (fast lane at 90 km/h = 56 mph for instance) the SOC can go down very quickly, but as soon as I slow down (and just after in the same travel, without stopping the bike in the meantime) the SOC can rise by 5%. I have used the old firmware for 4.5 years and I don't remember seeing this behavior: the SOC was always decreasing during a trip.

Note that, in almost all my BMS logs before the intervention, during charging I got lines telling that SOC mode changed from "voltage mode" to "Coulomb counting mode", such as
  DEBUG: Switching to voltage SOC mode
  DEBUG: Switching to coulomb couning SOC mode
I join a file with these lines in their context.
But since the intervention, these lines did not appear anymore.

So, if you Google something like "lithium battery state of charge versus voltage," you might find a lot of articles stating a very non-linear correspondence. However, within the typical operating of devices that are expected to have a battery last a very long time incuding our bikes, the capacity versus voltage is pretty much exactly linear. So making a simple SOC calculation based solely on meaured voltage seems an easy way to put a gauge on the dash. Unfortunately, during use, measured voltage varies with load. A more complex algorithm could include the battery resistance and output current into the model to make a more accurate gauge and maybe take it even a step further and model the voltage rebound characteristics based on factors like temperature and duration and amplitude of discharge, but that's a lot of work for not a long of gain that I guess Zero doesn't figure is worthwhile.

I've read it claimed that the old algorithm effectively took the voltage at key-on to establish the battery capacity at that point and subtracted energy from those kWh based on how much voltage and current the motor was fed during the ride. Your old BMS log appears to support that. On its face, it sounds like it would be a better way until you consider that batteries degrade. For a given voltage, the kWh available gets lower over time, so the SOC would become less and less accurate unless you somewhat regularly ran the bike from 100% to 0% (real 0% wherein the bike turns itself off) and even that is contingent upon the programming learning the new SOC versus voltage. If that was a fixed array in the program, it would never learn anything, and you'd eventually have your bike dying completely with the dash still showing some non-zero number.

I have also noticed, that after the intervention, almost each time I turn on the bike I get the warning "Max allowed voltage difference is 500mV". I did not get this warning before the intervention. There is less than 500mV difference between the two battery packs. Which are the voltages that differ from more than 500mV ?
More details in the attached file.

Since your battery voltages are obviously within 500mV and the error you see in the log actually appears before system acknowledges that the CAN link is even up, my best guess is a glitch in the code. It looks like before the CAN link is up, the system thinks the battery modules are at 0V. Maybe 0 is what is in RAM when the BMS first fires up before the registers are populated by the real data from the BMS over the CAN. Does the bike actually do anything odd, or does it work as expected? Does that message actually display on the dash or only in the logs?

[sharagan]

my bike makes only one click when turning on

I made a fresh log, the last one was from last winter

new log:

Firmware rev.      1536

 07782                       0   Module 00                  vmod: 0V, batt curr: 0A
 07783                       0   Module 01                  vmod: 0V, batt curr: 0A
 07789     01/14/2022 14:16:51   Module 00                  vmod: 100.481 maxsys: 100.481 minsys: 100.481 diff: 0.000 vcap: 89 prechg: 88%

also small update, the Module 01 entry is always displayed only with 0V and  0A as in line 07783
the next line with the maxsys, minsys etc. only appears for Module 00

so there is a difference between the long brick and the modular.

[rgutt]

Firmware rev.      1536

 07782                       0   Module 00                  vmod: 0V, batt curr: 0A
 07783                       0   Module 01                  vmod: 0V, batt curr: 0A
 07789     01/14/2022 14:16:51   Module 00                  vmod: 100.481 maxsys: 100.481 minsys: 100.481 diff: 0.000 vcap: 89 prechg: 88%

What information is in the log between lines 07783 & 07789?

[sharagan]

 07784                       1   Module 00 CAN Link Up   
 07785                       1   Module 00                  serial: 18ld0835,  vmod: 100.489V
 07786     01/14/2022 14:16:50   Sevcon Turned On   
 07787     01/14/2022 14:16:51   Sevcon CAN Link Up   
 07788     01/14/2022 14:16:51   DEBUG: Sevcon Contactor Drive ON.   

[gt13013]

So, if you Google something like "lithium battery state of charge versus voltage," you might find a lot of articles stating a very non-linear correspondence. However, within the typical operating of devices that are expected to have a battery last a very long time incuding our bikes, the capacity versus voltage is pretty much exactly linear. So making a simple SOC calculation based solely on meaured voltage seems an easy way to put a gauge on the dash. Unfortunately, during use, measured voltage varies with load. A more complex algorithm could include the battery resistance and output current into the model to make a more accurate gauge and maybe take it even a step further and model the voltage rebound characteristics based on factors like temperature and duration and amplitude of discharge, but that's a lot of work for not a long of gain that I guess Zero doesn't figure is worthwhile.

Zero did the job in previous firmwares. Basically, the system should estimate capacity of the pack versus the pack voltage (without load). This is possible (see next paragraph). When there is no load or very low load, the system could calculate the SOC from the pack voltage using this capacity / voltage curve. When there is some load on the engine (or regeneration), the system should interpolate between the previous values using Coulomb mode. But apparently they have simplified their algorithms in some firmwares. That's a pity. I hope the goal isn't to prematurely age their motorcycles to incite people to buy new ones!

I've read it claimed that the old algorithm effectively took the voltage at key-on to establish the battery capacity at that point and subtracted energy from those kWh based on how much voltage and current the motor was fed during the ride. Your old BMS log appears to support that. On its face, it sounds like it would be a better way until you consider that batteries degrade. For a given voltage, the kWh available gets lower over time, so the SOC would become less and less accurate unless you somewhat regularly ran the bike from 100% to 0% (real 0% wherein the bike turns itself off) and even that is contingent upon the programming learning the new SOC versus voltage. If that was a fixed array in the program, it would never learn anything, and you'd eventually have your bike dying completely with the dash still showing some non-zero number.

I do not agree. Since the BMS is able to monitor both voltage and capacity (Coulomb measuring), it should be easy to take into account battery degradation over time. And there is no need to go to 0%. The system knows the minimum voltage it accept to run (for my bike it is 3.1 V / cell, i.e. around 87 V for the pack, I did the total discharge once just to know). Even if you do not go to this minimum voltage, the system can estimate the capacity from all the data that it collects: measures of voltages (those with no load) and measures of Ah between them.
If you have an Android smartphone, test AccuBattery. After some learning, it will give you the capacity of your battery. I use it to follow battery degradation over time. If you are interested I have a graph of its capacity over time.

Since your battery voltages are obviously within 500mV and the error you see in the log actually appears before system acknowledges that the CAN link is even up, my best guess is a glitch in the code. It looks like before the CAN link is up, the system thinks the battery modules are at 0V. Maybe 0 is what is in RAM when the BMS first fires up before the registers are populated by the real data from the BMS over the CAN. Does the bike actually do anything odd, or does it work as expected? Does that message actually display on the dash or only in the logs?

Yes, you are probably right. It seems that during the initialization the system do not logs the things in the right order, and probably some values are measured before they have been initialized!

[gt13013]

That voltage difference will probably be the cell balance, leave you bike for a little bit after it gets to 100% and it should be sorted.

That is not the reason. See the file that I have attached in my previous post.

[gt13013]

my bike makes only one click when turning on

OK, that is the reason why you get similar values of prechg for the 2 modules. The capacitors are in the same transient state in both cases.

new log:

Firmware rev.      1536

 07782                       0   Module 00                  vmod: 0V, batt curr: 0A
 07783                       0   Module 01                  vmod: 0V, batt curr: 0A
 07789     01/14/2022 14:16:51   Module 00                  vmod: 100.481 maxsys: 100.481 minsys: 100.481 diff: 0.000 vcap: 89 prechg: 88%

also small update, the Module 01 entry is always displayed only with 0V and  0A as in line 07783
the next line with the maxsys, minsys etc. only appears for Module 00

so there is a difference between the long brick and the modular.

Even considering my bike only, two similar events (for instance turning on the bike) will not always give the same logs.
So it's difficult to compare line by line the logs of two different bikes.

How do you get your Firmware rev. 1536 ?
When I say that I have a firmware rev. 47, I get that from the MBB log, parsed with http://home.hasslers.net/zerologparser/log_parser.php

[sharagan]

funny, that the output is different.

I used https://zero-motorcycle-community.github.io/browser-parse/zero-log-parser.html and gives the 1536 revision number.

with hasslers I get
Firmware rev.      32

as far as I remember the last update I received on the bike was July 2021 or I was only told that I received one...who knows.

[gt13013]

That's strange.
When I use the same parser as you, https://zero-motorcycle-community.github.io/browser-parse/zero-log-parser.html
I get for my recent logs (after the firmware upgrade):
  Firmware rev.   56
  Board rev.        3
  Model              FXS

And for my old logs (before the firmware upgrade), Firmware rev. was 47

[sharagan]

also it shows FX instead of FXS, I downloaded the logs through the Zero Android mobile app over bluetooth.
Do you use some other method?

Firmware rev.      32
Board rev.         2980
Model              FX
Initial date       Oct  5 2020 14:00:33

Also the intial date is rather strange, that was the date it went for a warranty claim and stayed there for 4 months