Print

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

[ms_smart]

Hi,

I own a 2020 Zero SR/S and really love this bike. I am wondering, if it possible to get some info on SOH of the battery. I regularity retrieve this data from my other BEV and find this information useful. SOH is an indication for the battery degradation. You can better plan the range, know if your bike should be impacted by warranty conditions and a report on SOH also is helpful if you want to sell the bike.

I accessed the MBB console (thanks to all the useful information how to access it and what kind of data you can retrieve with Gen3!!) and thought, that the most useful information can be retrieved with the command "bms interface".

pack_capacity_ah  shows 109. Question would be: Is this a value that is constant for all Gen3 bikes or a potential indication for SOH? If I multiply this data with target_charge_voltage 116.2 V, I get a total capacity of 12.6767 KwH. This would be in sync with the owners manual (NOMINAL CAPACITY).

If  pack_capacity_ah  is actual data, it could be an indication, that the current SOH is 100%. Appreciate any guidance if this is a possible route to SOH calculation or if not if there are other / better ways to monitor SOH.

FYI: This is my last bms interface report (SOC = 73%):

ZERO MBB> bms interface
BMS 2 interface data:

 - status 0x80000036
 - status2 0x0000
 - pack_current_ma -425
 - time since status_rpdo_received 16

 - max_charge_voltage 117.6 V
 - target_charge_voltage 116.2 V
 - pack_soc_pct 73
 - discharge_allowed 85
 - max_charge_current 128
 - max_discharge_current 1092
 - time since power_rpdo_received 31

 - pack_capacity_ah 109
 - min_pack_temp_c 24
 - max_pack_temp_c 25
 - lowest_cell_voltage_mv 3822
 - time since pack_rpdo_received 33

 - pack_open_circuit_voltage_mv 107106
 - pack_voltage_mv 107106
 - time since voltage_rpdo_received 41
 - Contactor recently closed 0

 - bms_compatibility_field 0x03

[TheRan]

Given the degree of precision of all the other measurements the bike makes I would imagine if that was the actual measured capacity (or perhaps a calculated estimate, I don't think you can get the actual capacity without running it from 0-100% or vice-versa but I could be wrong) it would be more precise than just to the nearest Ah (and possibly be displayed in mAh given how they show voltage in mV).

[remmie]

My SR/F states 106 Ah so indeed different to yours, I'll also keep an eye on it now that I have the serial cable.

ZERO MBB> bms interface
BMS 3 interface data:

- status 0x80000036
 - status2 0x0000
- pack_current_ma -2032
 - time since status_rpdo_received 293388

- max_charge_voltage 117.6 V
- target_charge_voltage 112.8 V
- pack_soc_pct 87
- discharge_allowed 95
- max_charge_current 128
- max_discharge_current 1228
- time since power_rpdo_received 293390

- pack_capacity_ah 106
- min_pack_temp_c 25
- max_pack_temp_c 26
- lowest_cell_voltage_mv 3999
- time since pack_rpdo_received 293392

- pack_open_circuit_voltage_mv 111918
- pack_voltage_mv 112086
- time since voltage_rpdo_received 293393
- Contactor recently closed 0

- bms_compatibility_field 0x03

some nice info to be found through this serial cable, for example while charging you can see the amps, voltage PWM pilot signal etc for each charger.

ZERO MBB> charging

*************************************************************
*         Charger Data                        *
*************************************************************

          Measurement,      Value,     Units,    Valid,   In Test
EVSE_Connector_State,          0,      Conn,      Yes,         0
         EVSE_Command,          1,       Yes,      Yes,         0
         Inlet_Region,          2,        EU,      Yes,         0
          Latch_State,          0,    Closed,      Yes,         0
        Pilot_Current,         11,         A,      Yes,         0
  Cable_Current_Limit,         20,         A,      Yes,         0
             Charging,          1,       Yes,      Yes,         0
   Chargers_Connected,          3,          ,      Yes,         0
   Max_Charge_Current,        127,         A,      Yes,         0
   Charge_Current_Sum,       20.5,         A,      Yes,         0
   Max_Charge_Voltage,      117.6,         V,      Yes,         0
      Target_Charge_V,      112.7,         V,      Yes,         0
      Storage_Voltage,      106.0,         V,      Yes,         0
      Target_Override,          0,        No,      Yes,         0
    SOC_Charge_Target,         90,    Pct(%),      Yes,         0
Charge_Target_Enable,          1,       Yes,      Yes,         0
   Charge_Target_Init,          1,       Yes,      Yes,         0
      Charge Complete,          0,        No,      Yes,         0
   Scheduled_Charging,          0,        No,      Yes,         0
    Schedule_Override,          0,        No,      Yes,         0
   Sched_Charging_Now,          1,       Yes,      Yes,         0
   Plugin_Window_Init,          0,        No,      Yes,         0
   Charge_Window_Init,          0,        No,      Yes,         0
   Sched_Charge_Delay,          0,       min,      Yes,         0

******************* Charging Schedule ***********************
Day, Start_Time, Offset, Plugin_Start, Plugin_Offset
Sun,      21:30,   6:00,        17:00,          7:00
Mon,      21:30,   6:00,        17:00,          7:00
Tue,      21:30,   6:00,        17:00,          7:00
Wed,      21:30,   6:00,        17:00,          7:00
Thu,      21:30,   6:00,        17:00,          7:00
Fri,      21:30,   6:00,        17:00,          7:00
Sat,      21:30,   6:00,        17:00,          7:00

******************* Chargers Connected **********************
Charger,  En,  DC V,  DC A,  AC V,  AC A, AC HZ, Limit A,  Ver,   Serial,    ID, Status
   3_kW,   1, 111.9,  20.5,   224,  10.7,    50,      11,  101,  1850154, 0x010, 0x0080
   3_kW,   0,   0.0,   0.0,     0,   0.0,     0,      11,  101,  1850216, 0x011, 0x4020
   6_kW,   0,   0.0,   0.0,     0,   0.0,     0,      11,  100,  1919024, 0x012, 0x4020



also 12V power to each consumer is shown (command "PDU")

ZERO MBB> pdu

*************************************************************
*         PDU State                           *
*************************************************************

         Channel,   Current,   Units,   Valid,  In Test,          Fault,  State
  12V_Switch_Pwr,       134,      mA,     Yes,        0,           None,      1
         ABS_MCU,        82,      mA,     Yes,        0,           None,      1
       High_Beam,         0,      mA,     Yes,        0,           None,      0
            Horn,         0,      mA,     Yes,        0,           None,      0
     Heated_Accs,      3358,      mA,     Yes,        0,           None,      1
      Aux_Outlet,        30,      mA,     Yes,        0,           None,      1
       Headlight,      1616,      mA,     Yes,        0,           None,      1
     Cntlr_Logic,       498,      mA,     Yes,        0,           None,      1
     Brake_Light,         0,      mA,     Yes,        0,           None,      1
   Right_Blinker,         0,      mA,     Yes,        0,           None,      0
    Left_Blinker,         0,      mA,     Yes,        0,           None,      0
      12V_Heater,         0,      mA,     Yes,        0,           None,      0
   DC-DC_to_Batt,         0,      mA,      No,        0, No_Measurement,      1
12V_Heater_Temp,         0,       C,      No,        0,               ,      0
   Total_Current,      5744,      mA,     Yes,        0,               ,      0



Also a nice one, the performance data.(command "perf") look at that total Wh : 920 kWh almost 1 MWh  

*************************************************************
*         Performance                         *
*************************************************************

                           Parameter,      Value,    In Test
                        filt_batt_ma,      29236,          0
                       filt_kph_x100,       5340,          0
                               Ws/km,          0,          0
                      Ws/km_filtered,          0,          0
                            total_Ws, -980402786,          0
                           total_Whr,     920712,          0

[Hans2183]

Oh interesting! I've done 11k by now so could see some degradation. Don't have any means of reading the odb port yet though. The Bluetooth one didn't work and haven't checked any other options just yet. Where should I look for SRF/SRS specific odb options?

[remmie]

I used an Arduino and some components, but an USB-TTL converter should be fine as well. See the link to the zero manual
https://zeromanual.com/wiki/How_to_build_a_cable_to_access_the_MBB. The baudrate for the SR/F and SR/S is 115200 (same pins as the (D)S(R)

I had an Adafruit Featherwing 3.5 inch TFT with an Adafruit Huzzah32 ESP32 microcontrollerboard laying around so whipped up some code to make the MBB console visible on that 3.5 inch TFT.
https://www.adafruit.com/product/3405
https://www.adafruit.com/product/3651


The result is in the attached picture. The code sends the charging command to the OBD connector every 2 seconds and then waits for a response, everything that is received on the serial port is added into a string and after the 2 seconds waiting time is over the following is done :
* clear there TFT
* set the cursor to the top of the TFT
* send the received string to the TFT
* send the received string to (another) serial port (For the serial monitor of the Arduino IDE), this is not needed if the TFT is used stand alone
* empty the received string (make it ready for new info)
* send the "charging" command to the ODB serial port.

below is the entire code in full for those of you who want to play around with this as well. 1 additional hardware thing though. As the ESP32 is a 3.3V microcontroller, I've put a 1k resistor in series with the RX on the ESP32 (so the signal from the MBB to the ESP). The other way around seems fine, the MBB understands the "charging" command on a 3.3V level and sends the appropriate response.

As you can see in the picture not all info fits on the screen even though the smallest possible font is used. That requires further programming. Like stripping the headers with all the asterisks, removing unnecessary spaces etc.

but as a first try (well, it took me a few tries  ) I think it already looks very promising. Looks like another project is starting to emerge 
Thinking of :
* speeding up the "drawing" of the text (there are much faster drivers for the ESP and TFT)
* scrolling through different pages of information (the TFT has a touchscreen built in)
* saving all the received data to microSD (the TFT also has a built in SD card slot)
* Making a dashboard with the data.
* etc etc



Full code :

#include <SPI.h>
#include "Adafruit_GFX.h"
#include "Adafruit_HX8357.h"

#define STMPE_CS 32
#define TFT_CS   15
#define TFT_DC   33
#define SD_CS    14
#define TFT_RST -1

int request_interval = 2000;
unsigned long last_request_sent_at = 0;
String received = "";

Adafruit_HX8357 tft = Adafruit_HX8357(TFT_CS, TFT_DC, TFT_RST);

void setup() {
  Serial2.begin(115200);
  Serial.begin(115200);
  tft.begin();
  tft.setRotation(0);
  tft.setTextWrap(0);
  tft.setTextSize(0);
  tft.fillScreen(HX8357_BLACK);
  tft.setCursor(0, 0);
}

void loop(void) {
  while (Serial2.available()) {      // If anything comes in Serial (USB),
    received = received + Serial2.readString();
  }
  if (millis() - last_request_sent_at > request_interval) {
    tft.fillScreen(HX8357_BLACK);
    tft.setCursor(0, 0);
    tft.println(received);
    Serial.print(received);
    received = "";
    Serial2.print("charging\n");
    last_request_sent_at = millis();
  }
}

[ms_smart]

@remmie, your arduino project is really cool and looks like I have now a new project for the next winter

@Hans, If you decide to build your own cable following https://zeromanual.com/wiki/How_to_build_a_cable_to_access_the_MBB (this is what I did): You may run into a problem, that the device driver (windows device manager) reports prolific usb-to-serial code 10. There are some articles on the web how to address this issue (e.g. https://www.totalcardiagnostics.com/support/Knowledgebase/Article/View/92/20/prolific-usb-to-serial-fix-official-solution-to-code-10-error)

@remmie, thanks for sharing your data! Very helpful. I have seen, that your data shows target_charge_voltage 112.8 V. In my case it is 116.3 V. If I multiply your target_charge_voltage with your pack_capacity_ah it sums up to 11.95 KWh. This would be 93% of my 12.67 KWh. Does someone has an idea what target_charge_voltage could mean? I just re-ran the BMS log with SOC 90%. My target_charge_voltage did not change (of course pack_voltage_mv increased as well as lowest_cell_voltage_mv).

[remmie]

In the bike's menu I have set a charge target of 90% so that the bike only charges up to 90% (you can override by keying the bike on and selecting "override" after which it will charge to 100%. This is to prolong battery life. When doing a longer tour it only takes about half an hour to top up to 100%.

So the 112.8 volt is 90% SOC voltage So the name "target charge voltage" is spot on. 116.3 Volt is 100% SOC voltage

glad you like the Arduino project, I'll update the progress periodically.    If you need help with your project, just post and let me know

[remmie]

Today I downloaded all the responses to commands that were available and put them in a text file.
That file is attached so you can see if there is information in there you're interested in.

[ms_smart]

@remmie, target_charge_voltage  now makes totaly sense to me:)

how have you connected the OBD2 port to the Arduino and how have you powered it? Appreciate if you can give guidance on your exact HW setup.

My plan would be, to use a cheap NodeMCU ESP32 device with WLAN and no display at all. The device should connect to the OBD2 port, open the MBB console, retrieve data that I think is important to me and save it to a FTP server as well as a SQL database that I have at home. Success or any error condition should be reported through push notifications to my smartphone/smartwatch. My idea would be, that the device is permanently attached to the OBD2 port and reports out each time the device gets power (either through USB or OBD2). If the device is can't connect to my WLAN at home, it should store the data in a local file on the device and upload it once connected.

[remmie]

Sure, no problem.

The power to the ESP32 is a standard USB to micro-usb cable. One of the 2 standard USB ports in the "frunk" works fine. so that's easy.
Pin 16 on the OBD port is powered with 12V when the bike is off. Though it would require a 12V to 5 volt (or 3.3V) DCDC converter. 

Data signals :
GND is easy. Pin 5 on the OBD is directly connected to the GND pin of the ESP32 (black wire in the pictures)
Data from OBD to ESP : Pin 8 of the OBD is connected via a 1kOhm resistor to the RX port of the ESP32 (green wire in the pictures)
Data from ESP to OBD : Pin 9 of the OBD is connected directly to the TX port of the ESP32 (yellow wire in the pictures)

the 1K resistor is to protect the ESP32 RX port against possible 5V from the OBD (ESP32 is a 3.3V microcontroller, even though it is powered with 5V). The TX of the ESP has no level conversion to 5V but the MBB seems to understand the commands sent on 3.3V perfectly.

Thats really it. So 2 options for you :
1) buy an OBD connector, a dcdc converter (12V to 5 or 3.3 depending on the need of the NodeMCU) and a resistor and solder it all inside the OBD connector housing and you have a permanent on system. or
2) still fit the MCU in the OBD connector but attach the usb cable to it and connect this to the USB port in the frunk to have switched power. The USB cable is then also great for reprogramming and debugging.
3) make your own setup 

love to see your progress on it

[Hans2183]

Almost there, I do get the log statements when toggling switches or ignition using screen on the terminal in MAC OS X

Code: [Select]

DEBUG:   08/21/2020 11:45:31.234  ..\src\Application\zero_mbb_manage_bike.c
However I'm never prompted with the menu options and I don't get any responses when I type any text. Not sure if that is a screen issue. I'll continue checking later today.

From the wiki

Mac
    Open CoolTerm (freeware, unsigned) and connect to the bluetooth serial modem and set baud rate.
Linux/Unix-like
    Open minicom/etc. and connect to the USB (likely /dev/ttyUSB0) or bluetooth serial modem and set baud rate.

Open connection and the MBB prompt should be displayed (hit enter key if not)

    Mbb1.png

Coolterm doesn't seem supported on latest OS X versions (at least I think that is why I keep getting access denied) so I also tried minicom on mac just to be sure and even with that I don't get any different output but the debug log statements.

According to this manual I should be able to hit enter to get the output.

[remmie]

For the menu items to appear you need to type “help” first.
Getting a correctly working terminal program is also required off course.

I also use a macbook but i was able to use an arduino as interpreter.
I don’t know of any standalone terminal programs for up to date macs unfortunately

[Hans2183]

Yes I was trying help and other commands but that didn't work. Even using echo directly on the tty device and cat to monitor elsewhere nothing happened.

But I now tried with an Arduino using SoftwareSerial (only have UNO and NANO boards here) and then I was able to send commands and get responses back. However data was only partial. So I then went back to my USB TTL converter and just used the Arduino Studio provided Serial Monitor and that works perfectly.

This is my output with 71% SOC displayed on the dash. So according to this my pack_capacity_ah value is at 112. This is after just over 11.000 km and tomorrow I'll have the bike exactly 1 year. "Thanks" to covid-19 it's only 1/3 of what I normally ride.

Let me know if you want me to share other data. Looks like this also has information on current speed and power usage while riding. Will have to make a logger of some sort to get that info.

Code: [Select]

ZERO MBB> bms interface
BMS 3 interface data:

- status 0x80000036
- status2 0x0000
- pack_current_ma -589
- time since status_rpdo_received 100

- max_charge_voltage 117.6 V
- target_charge_voltage 109.8 V
- pack_soc_pct 72
- discharge_allowed 87
- max_charge_current 128
- max_discharge_current 1120
- time since power_rpdo_received 10

- pack_capacity_ah 112
- min_pack_temp_c 25
- max_pack_temp_c 26
- lowest_cell_voltage_mv 3811
- time since pack_rpdo_received 27

- pack_open_circuit_voltage_mv 106815
- pack_voltage_mv 106815
- time since voltage_rpdo_received 29
- Contactor recently closed 0

- bms_compatibility_field 0x03

And this is the contraption I used

[remmie]

112 Ah after 11.000 km. that seems quite good. I have 106 Ah after 13500 km.

Good to hear that the USB-TTL converter also works with the Arduino IDE on Mac. At least that is a solution that works with the latest software updates.

One thing that I haven't been able to find is the cell balance value.
But I think there is way to derive a somewhat similar figure from the available data.

your pack voltage is 106815mV and the lowest cell voltage is 3811.
106815 millivolt divided over 28 cells in series is 3814.8 mV and the lowest is 3811. So the difference between lowest and average is 3.8 mV which is quite good. Off course balance is technically the difference between lowest and highest voltage but since highest voltage is not available it will have to do.

for my data the "balance" is 112086/28-3999 = 4.1mV also nice!

and for ms_smart 107106/28 - 3822 = 3.2 mV very nice.

[Hans2183]

Isn't that because @ms_smart is at 100% SOC? That it gets better balanced when reaching the full charge?

I quickly hacked up the existing OBD housing to hold the USB to TTL