Open dalathegreat opened 5 months ago
@dalathegreat , is there a reason you can't use the calculation I gave to estimate the full pack? It works for the 30kwh pack, and was quite accurate. Does the qc capacity reported by the battery not work the same in a 40 or 62 kWh pack? Qc capacity/0.8 (80wh/gid?)
@dalathegreat had a quick look across the code, the 3port code is missing the 30kwh battery detection code. This is staying registered as a 24kwh battery on 3 port bridge. That is why the gids are not raised to the full pack level on startup
Not sure how you sample the QC Capacity, but massive thanks for the review! I added the 30kWh detection to 3-port, PR is up! https://github.com/dalathegreat/Nissan-LEAF-Battery-Upgrade/pull/36
I'll show for fullcap and capremaining, if its helpful. I used these values to create better charge timer estimates also.
Declare the variables
volatile uint16_t LB_FullCap_for_QC = 0;
volatile uint16_t LB_CapRemaining_for_QC = 0;
Capture the values as they come from the battery, before we manipulate the values to fix fast charging.
case 0x59E: // QC capacity message, adjust for AZE0 with 30/40/62kWh pack swaps
LB_FullCap_for_QC = (((frame.data[2] & 0x1F) << 4) | ((frame.data[3] & 0xF0) >> 4)) ;
LB_CapRemaining_for_QC = ((frame.data[3] & 0x0F) << 5) | ((frame.data[4] & 0xF8) >> 3);// collect these for better charge time remaining calcs
And finally use the value to know the gids capacity of the battery, in place of the hard coded values
case 0x5BC:
...
swap_5bc_remaining.LB_CAPR = (LB_FullCap_for_QC/0.8); // for elevating the gids on startup
The hardcoding of capacity remaining should be removed, and instead use a (Whan new capacity * SOH%). This will avoid showing 12/12 bars of range left when in fact it should be emptier. Not a massive issue, but could be done smarter.