It was noticed in several forum topics that if some SBS parameters reported by chip were out-ranged the GUI throws "Communication error" message.
For example this thread.
Static and Dynamic parameters read Ok except SBS.ChargingCurrent() which field is empty.
On pressing "Lock status" button it throws "Communication error". Probably when SBS.ChargingCurrent() is to be read for evaluation.
Procedures where this parameters is used like Charging and AutoCycling become blocked as well.
Manual read of SBS.ChargingCurrent() over Smbus tab 10 times with 1s interval revealed communication is Ok, but parameter is out-of-range. The value is 0xccc1=52417mA that is abnormal.
The reason is some chips use FCC parameter as a base to calculate Charging Current.
uint16 ChgC = f(FCC, ...);
And this battery had FCC abnormal (what is typical for many bq208xx, bq304xx chips after long storage).
After fixing the FCC, SBS.ChargingCurrent() was automatically fixed as well. Now pressing "Lock status" button does not throw any communication errors.
Charging procedure become unblocked as well.
Recommendation:
To print Charging Current reported by chip "as is" instead of treating out ranged values as communication error.
How to reproduce the issue:
To take any chip which uses FCC to calculate Charging Current, for example bq20889.
To change manually FCC to 65000.
To read then SBS, LockStatus, to try charge it.
Another topic with same bug.
Another 9 month old topic with same issue. Due to bad quality picture attached by TS, me only now noticed that SBS.ChargingCurrent() is missing in the report. Chip is bq20889, FCC=65xxx mAh. Battery was charging well from the first tab. TS did not return with any feedback to resolve the issue
The issue was explained on the forum. A fix could be added in the Battery Info tab to display the values exactly as they are received. For Charging and Discharging, the NLBA1 device has the charging and discharging algorithms done in the firmware. There are other checks on top of the raw values received from the chip. One check is to have the correct value for ChargingCurrent, it is part of the safety concept.
Once the FCC is displayed as it is received from the chip, it could be colored as red (wrong) and the user will know that there is an issue with it. Once it is fixed then the problem is solved.
One check is to not have abnormal value for the FCC,
Do you mean Charging Current?
FCC is displayed "as is" even its out of range.
Yes, Charging Current.
One check is to have the correct value for ChargingCurrent, it is part of the safety concept
As was explained in another thread the limit for Charging Current is 20000mA as per safety concept. So as me understood this concept correctly, device should not use the value above this limit to not go in overload, correct?
More or less yes. There are several redundant checks to avoid using NLBA1 for other scopes. For overcurrent, there is another check against the instant current, if it is higher than 5000mA the charging stops. It seems that Dell has something similar, if the FCC is higher they even don't respond to CC command. It could be a bug or a feature...
It seems that Dell has something similar, if the FCC is higher they even don't respond to CC command
They respond very well to CC register. It was confirmed using Smbus tab ReadWord 0x14 command. The value of CC in this case is modulated by FCC so its out of normal range. Its not read by NLBA1 first page, but read well using any other hardware like cp2112 or ev2300.
Fixed in NLBA1 Version 5.2.4: https://www.laptopu.ro/community/nlba-pc-software-version-history/nlba-pc-software-revisions
Latest Post: RESET LENOVO BATTERY WITH SONY BQ8030A CHIP Our newest member: amageritspecialist.dk Recent Posts Unread Posts
