Cheap LiFePO4 BMS?

[MoominPapa]

6 minutes ago, Dr Bob said:

No, what I am saying is that when not charging but under normal discharge or rest, these boards will transfer charge from a high cell to a low cell - (except the board in question will only start when the delta is 100mV which will only be when charging or in the bottom knee). Lets assume then the charge transfer is happening when in the plateau. If I have say my cell 2 which is 15mV lower than the high cell ..call it cell 4 (at little load) then the balance board will transfer charge from cell 4 to cell 2 until the delta is <10mV. My problem is that cell 2 is the first cell to reach the knee when we charge so it doesnt need the charge from cell 4 when in the plateau range. It will only make it get to the knee quicker......and yes I have used a multimeter to check the voltages are real!

The key here is that the voltages of all 4 cells when in mid range of SoC are not identical and can be up to 20mV different but that difference MAY NOT BE the same when approaching the knees.

My approach of comparing the cell voltages during charge seems to be working OK. I'd like to see an attempt at a balancer which estimates the imbalance as the pack approaches termination and then corrects it post-hoc.

 

MP.

 

[Dr Bob]

17 minutes ago, MoominPapa said:

 If the motivation for this is to keep the LiFePO4 pack below 100Ah for balancing purposes, then that's spurious, balancing large packs is a solved problem, even if the solution is not the one stated above.

 

 

 

I agree, even my 'caveman' approach to balancing is so easy once you have worked out how much charge has to be shifted from one cell to another..... which is easy to estimate once you have done it once. It took me a few days to understand it mid year but now it really is very little effort.

[nicknorman]

6 minutes ago, Dr Bob said:

No, what I am saying is that when not charging but under normal discharge or rest, these boards will transfer charge from a high cell to a low cell - (except the board in question will only start when the delta is 100mV which will only be when charging or in the bottom knee). Lets assume then the charge transfer is happening when in the plateau. If I have say my cell 2 which is 15mV lower than the high cell ..call it cell 4 (at little load) then the balance board will transfer charge from cell 4 to cell 2 until the delta is <10mV. My problem is that cell 2 is the first cell to reach the knee when we charge so it doesnt need the charge from cell 4 when in the plateau range. It will only make it get to the knee quicker......and yes I have used a multimeter to check the voltages are real!

The key here is that the voltages of all 4 cells when in mid range of SoC are not identical and can be up to 20mV different but that difference MAY NOT BE the same when approaching the knees.

Ok I see. Yes obviously the balancing should be done based on the start of the knee, not the mid charge voltage.

 

As to the voltages I remain sceptical that the BG-8S is not misleading you somewhat. The stated accuracy is +-5mV so if one channel has +5mV and the other -5mV, there could be 10mV of imaginary mismatch. But no point in re-kindling that argument until I have proof. I keep meaning to rearrange the small LiFEPO4 cells connected to my BG-8S so see if the voltages faithfully follows the cells, or not. But haven’t managed to get around to it yet!

[Dr Bob]

5 minutes ago, nicknorman said:

 

 

As to the voltages I remain sceptical that the BG-8S is not misleading you somewhat. The stated accuracy is +-5mV so if one channel has +5mV and the other -5mV, there could be 10mV of imaginary mismatch. But no point in re-kindling that argument until I have proof. I keep meaning to rearrange the small LiFEPO4 cells connected to my BG-8S so see if the voltages faithfully follows the cells, or not. But haven’t managed to get around to it yet!

No the voltages are real. I have checked them with a multimeter and the multimeter sees the same deltas that the BG8S is seeing and the BG8S voltages do move up and down as expected. For me its not about absolute voltage, its how the voltage changes. I think it is far more likely that if there is an inaccuracy the two channels are both +5mV. Before I started I checked my multimeter against MPs multimeter and they were similar to 0.01V.

You are very welcome to come down and inspect/check/validate any voltage differences!?

 

[MoominPapa]

Apologies for going off-topic: I'm assuming this thread has taken on the role of the generic Lithium discussion thread now.

 

Just wanted to report that we got our bank up to 100% charge yesterday, so the first time in a month. We've been living aboard for that entire month, and based on our normal daily usage, more than 3000Ah have gone in and out of the bank during that time. The inaccuracy in the SoC determined by the BMS was 30Ah: it was showing 30Ah more charge than the batteries actually contained, so the charge continued for another 30Ah after the SoC reading reached 100%.   In percentage terms. that's about 7% of the usable capacity. 

 

Based on that I'm declaring success on my goal of a SoC meter which is sufficiently accurate at all times to avoid nasty surprises.

 

The figures above are the ones generated by the Kalman filter. The estimate based on straight Ah counting had diverged badly and was 120Ah out in the opposite direction, as we discovered at 5am one morning when an alarm based on the straight Ah-count triggered  that I left in the code as a back-up when I added the Kalman filter.

 

MP.

 

[nicknorman]

2 hours ago, MoominPapa said:

Apologies for going off-topic: I'm assuming this thread has taken on the role of the generic Lithium discussion thread now.

 

Just wanted to report that we got our bank up to 100% charge yesterday, so the first time in a month. We've been living aboard for that entire month, and based on our normal daily usage, more than 3000Ah have gone in and out of the bank during that time. The inaccuracy in the SoC determined by the BMS was 30Ah: it was showing 30Ah more charge than the batteries actually contained, so the charge continued for another 30Ah after the SoC reading reached 100%.   In percentage terms. that's about 7% of the usable capacity. 

 

Based on that I'm declaring success on my goal of a SoC meter which is sufficiently accurate at all times to avoid nasty surprises.

 

The figures above are the ones generated by the Kalman filter. The estimate based on straight Ah counting had diverged badly and was 120Ah out in the opposite direction, as we discovered at 5am one morning when an alarm based on the straight Ah-count triggered  that I left in the code as a back-up when I added the Kalman filter.

 

MP.

 

Yes I think you can give yourself a pat on the back for that one! Or some cake.

Hybridised data (ie where more than one type of sensor data is combined to give a result much better than any one) is very common in modern aircraft avionics and I would imagine that a Kalman filter is used to merge the data in many cases.

 

Typically one sensor is good for short term changes, but suffers from long term boundless integration errors, whereas another sensor isn’t very good in the short term but doesn’t have any cumulative errors. In your case of course that is the current and current integral (Ah) for the current sensor, and voltage and hence approximate SoC from a voltage sensor. The latter not instantaneously very accurate but better if taken over a while and not subject to cumulative errors.

 

Lots of similar examples in aircraft, eg simple one: vertical speed based on integrating delta g resolved into the geo-vertical direction, tempered by pressure and rate of change of pressure. Anyway, I digress...

[WotEver]

13 minutes ago, nicknorman said:

Hybridised data (ie where more than one type of sensor data is combined to give a result much better than any one) is very common in modern aircraft avionics

And the lack of it is one of the main causes of the 737 MCAS situation as I understand matters. 

[nicknorman]

1 minute ago, WotEver said:

And the lack of it is one of the main causes of the 737 MCAS situation as I understand matters. 

No I think in that case, it was a lack of redundancy / duplication of the same sensor. There was only 1 angle of attack sensor, and AoA is the main parameter used to drive the MCAS system. If that 1 sensor went faulty, all hell broke loose and people died. If there had been 2 sensors, when one went faulty there could have been a mismatch declared and the MCAS system inhibited. Ideally though, there would be 3 sensors with a voting system so if 2 said one thing and the third said something different, the 2 would win out over the faulty one, the MCAS system could continue to function with just a maintenance flag to indicate the rogue sensor needed fixing before the next flight.

 

Triplicated sensor systems are fairly common on aircraft for critical things like attitude, heading, airspeed, altitude etc. for this reason. If one goes faulty, it is pretty obvious which are the good ones and which is the bad one.

[WotEver]

1 minute ago, nicknorman said:

No I think in that case, it was a lack of redundancy / duplication of the same sensor. There was only 1 angle of attack sensor, and AoA is the main parameter used to drive the MCAS system. If that 1 sensor went faulty, all hell broke loose and people died. If there had been 2 sensors, when one went faulty there could have been a mismatch declared and the MCAS system inhibited. Ideally though, there would be 3 sensors with a voting system so if 2 said one thing and the third said something different, the 2 would win out over the faulty one, the MCAS system could continue to function with just a maintenance flag to indicate the rogue sensor needed fixing before the next flight.

 

Triplicated sensor systems are fairly common on aircraft for critical things like attitude, heading, airspeed, altitude etc. for this reason. If one goes faulty, it is pretty obvious which are the good ones and which is the bad one.

Yeah, that’s kinda what I meant. Okay, it’s not different methods of determining AoA but it’s more than one thing measuring it (or should be).  

[MoominPapa]

30 minutes ago, nicknorman said:

Yes I think you can give yourself a pat on the back for that one! Or some cake.

Mince pies are available Nom nom.

30 minutes ago, nicknorman said:

Hybridised data (ie where more than one type of sensor data is combined to give a result much better than any one) is very common in modern aircraft avionics and I would imagine that a Kalman filter is used to merge the data in many cases.

 

Typically one sensor is good for short term changes, but suffers from long term boundless integration errors, whereas another sensor isn’t very good in the short term but doesn’t have any cumulative errors. In your case of course that is the current and current integral (Ah) for the current sensor, and voltage and hence approximate SoC from a voltage sensor. The latter not instantaneously very accurate but better if taken over a while and not subject to cumulative errors.

 

Lots of similar examples in aircraft, eg simple one: vertical speed based on integrating delta g resolved into the geo-vertical direction, tempered by pressure and rate of change of pressure. Anyway, I digress...

 

It seems to work in this case. At first I was worried that the accuracy was like that of a stopped clock, but it does seem to track long-term and give sensible readings even when not getting to charge termination regularly. Out of interest, here's the graph. Green is Ah-counting, blue the estimate from cell voltage via linear-regression to zero current, and purple the filter output.

 

MP.

 

 

[WotEver]

14 minutes ago, MoominPapa said:

Out of interest, here's the graph. Green is Ah-counting, blue the estimate from cell voltage via linear-regression to zero current, and purple the filter output.

Interesting to see that SoC gets further and further out whereas voltage remains (as you would expect) pretty accurate. 

[MoominPapa]

2 minutes ago, WotEver said:

Interesting to see that SoC gets further and further out whereas voltage remains (as you would expect) pretty accurate. 

Small errors accumulate. I can't account for why they seem to always be on the down-side., except that zero-point of the current sensor is not particularly stable: large currents in either direction tend to leave remanent magnetism which biases the hall sensor until wiped by a large current in the opposite direction, so maybe the fact that we spend longer discharging the batteries than charging them is significant.

 

You can spot our three weekends away. in the data These really tend to mess things up because the small standing current makes any current measurement error relatively large, and the best-fit linear regression works badly when there's not a wide spread of current/voltage points to extract information from.

 

MP.

 

[nicknorman]

19 minutes ago, MoominPapa said:

Mince pies are available Nom nom.

 

It seems to work in this case. At first I was worried that the accuracy was like that of a stopped clock, but it does seem to track long-term and give sensible readings even when not getting to charge termination regularly. Out of interest, here's the graph. Green is Ah-counting, blue the estimate from cell voltage via linear-regression to zero current, and purple the filter output.

 

MP.

 

 

Although as you say it’s worked very well overall, the relationship between the filter output and the zero-currrent voltage derived SoC seems to be close at some times, and far out at other times. So perhaps there is room for improvement of this parameter? I am thinking in particular that the delta arising from charge /discharge current is perhaps not the same for charge as it is for discharge (not sure if you regression deals separately with + and - current?) but more importantly there is probably a significant temperature coefficient - reaction speeds faster at higher temperatures so less dV for a given current.

[nicknorman]

Edit: just re reading your post, it seems you model the battery “on the fly” and when there aren’t large variations in current, this doesn’t work well. Any particular reason for not using lots of data to calculate a fixed battery model that is then used “not on the fly” ever afterwards?

Edited December 20, 2019 by nicknorman

[MoominPapa]

2 minutes ago, nicknorman said:

Although as you say it’s worked very well overall, the relationship between the filter output and the zero-currrent voltage derived SoC seems to be close at some times, and far out at other times. So perhaps there is room for improvement of this parameter? I am thinking in particular that the delta arising from charge /discharge current is perhaps not the same for charge as it is for discharge (not sure if you regression deals separately with + and - current?) but more importantly there is probably a significant temperature coefficient - reaction speeds faster at higher temperatures so less dV for a given current.

The filter only operates during discharge: there are actually no points on the blue line whilst charging, but the plotting program has interpolated a straight line which makes that difficult to see.

 

History matters, in a difficult-to-quantify way. After charging and before significant discharge the voltage is higher than you would otherwise expect. You can see this during the last weekend in the data. We charged for a few hours, then shut down and left the boat. The fridge used some power for few hours until the boat cooled, and after that there was just the boat standing current. Throughout the whole weekend, the voltage-derived SoC was way high, to the extent that the filter registered increasing SoC despite the constant small current drain. Once we returned and started to use power again the voltage-derived estimate rapidly converges with  the filter output.

 

MP.

 

[MoominPapa]

12 minutes ago, nicknorman said:

Edit: just re reading your post, it seems you model the battery “on the fly” and when there aren’t large variations in current, this doesn’t work well. Any particular reason for not using lots of data to calculate a fixed battery model that is then used “not on the fly” ever afterwards?

No good reason. I should look at what the regression code calculates for internal resistance and see how much it changes. Unfortunately, that data got bumped out of the fixed-size log data frames long ago in favour of other stuff, so I don't have a record of it.

 

We're getting back to the tension between a system which works well enough and is required to do so to avoid the lights going out, and an R&D exercise.

 

 

MP.

 

 

Edited December 20, 2019 by MoominPapa

[peterboat]

M tupenth worth I just do voltage its easier its now at 26.4 the washing machine was on this morning and so was the whispergen to keep the batteries up. It really is that easy I dont want or need to know the SOC and I have used this system for 1.5 years, James has been doing the same for 3 years with similar success, I consider these batteries the ultimate fit and forget, ok I have a BMS in every battery to keep cells balanced, but apart from that the whispergen will start if the voltages gets to low and will turn off if or cut back if it gets to high, sort of similar to our engines except you control them

[Dr Bob]

1 hour ago, peterboat said:

M tupenth worth I just do voltage its easier its now at 26.4 the washing machine was on this morning and so was the whispergen to keep the batteries up. It really is that easy I dont want or need to know the SOC and I have used this system for 1.5 years, James has been doing the same for 3 years with similar success, I consider these batteries the ultimate fit and forget, ok I have a BMS in every battery to keep cells balanced, but apart from that the whispergen will start if the voltages gets to low and will turn off if or cut back if it gets to high, sort of similar to our engines except you control them

I agree with Peter. Just using voltage is the easiest way to track your battery performance. MPs system seems to have a very good correlation to SoC but that is very advanced for those of us just bolting bits of kit together. I rely on my BMV for battery monitoring and Ahr counting and whilst the Ahr counting is great for use on a day to day basis (so you can see you have used 120Ahrs overnight since the sun last shone) it is not good as an accurate Ahr out reading as it gets well out of sync  with the real position over 3 months. Yes, I could try and fine tune it over the 3 months by changing the settings but why bother when the voltage is the best indicator of battery SoC. I could chose to resync the BMV when the voltage gets to a point where I get to on my normal charge routine ie say 13.7v charging at 30A (which may be 90% ish) so it would say 100% when it is 90% but why? If you know your voltage limits then that is all you need.

I can see why MP has refined his system to get to the point where it predicts SoC and I do continually look at voltage and Ahrs etc but that is just because I am interested... it is total overkill. You just need to follow voltage once you have mapped it out and know your total bank and cell voltage limits. It really is fit and forget for those who are bothered about the technical stuff. If technical stuff is your interest then there are many many hours of fun investigative work and it becomes a great hobby. If not, sit back and relax.

[nicknorman]

3 hours ago, MoominPapa said:

 

We're getting back to the tension between a system which works well enough and is required to do so to avoid the lights going out, and an R&D exercise.

 

MP.

 

True. But for me it currently is an R&D exercise!

[MoominPapa]

14 minutes ago, nicknorman said:

True. But for me it currently is an R&D exercise!

Understood. I'm looking forward to reports of your results.

 

MP.

 

[nicknorman]

2 hours ago, MoominPapa said:

Understood. I'm looking forward to reports of your results.

 

MP.

 

So far only the battery monitor designed, PCB layout in progress.

 

Risk factors are soldering the miniscule AD7280 (LTQFP package, 0.5mm lead pitch. Eeeek!)

And whether I can decode the Masterbus Canbus traffic.

 

As a backup I’ve included provision for a temperature sensor, broken out an analogue input that could be used for current measurement, and included a real time clock. But the intention is to get those 3 parameters from the Masterbus.
There will be also be a connector to drive MOSFETS/resistors for balancing but that will be done off-board.

[Dr Bob]

2 hours ago, nicknorman said:

. But the intention is to get those 3 parameters from the Masterbus.

 

I've got a bus pass in Engerlung and Wales at the moment.

Edited December 21, 2019 by Dr Bob

[nicknorman]

Another good article in this month’s Canal Boat. Well done to Andy and his team of contributors!

 

For my part, too many distractions of late but I have nearly finished the first PCB design. I have also tinkered with the Masterbus and a cheap ebay CANbus sniffer. Easy to record the raw CANbus traffic and I am fairly sure I will be able to decode it with a bit more time (stupidly managed to blow up the CANbus sniffer, not a huge disaster as it was only £14. New one now arrived). Big learning curve for me about CANbus, I didn’t really understand the detail before.

[rusty69]

3 minutes ago, nicknorman said:

Another good article in this month’s Canal Boat. Well done to Andy and his team of contributors!

Yes, well done Dr Bob and team.

3 minutes ago, nicknorman said:

For my part, too many distractions of late but I have nearly finished the first PCB design. I have also tinkered with the Masterbus and a cheap ebay CANbus sniffer. Easy to record the raw CANbus traffic and I am fairly sure I will be able to decode it with a bit more time (stupidly managed to blow up the CANbus sniffer, not a huge disaster as it was only £14. New one now arrived). Big learning curve for me about CANbus, I didn’t really understand the detail before.

That sounds disgusting.This is a serious battery thread on a family forum. Please keep it clean.

[peterboat]

1 minute ago, nicknorman said:

Another good article in this month’s Canal Boat. Well done to Andy and his team of contributors!

 

For my part, too many distractions of late but I have nearly finished the first PCB design. I have also tinkered with the Masterbus and a cheap ebay CANbus sniffer. Easy to record the raw CANbus traffic and I am fairly sure I will be able to decode it with a bit more time (stupidly managed to blow up the CANbus sniffer, not a huge disaster as it was only £14. New one now arrived). Big learning curve for me about CANbus, I didn’t really understand the detail before.

Years of working on cars has meant knowing exactly how canbus works, fixed a jags non starting before Christmas with canbus problems [wire nearly broken through causing high resistance] I sold the garage four and a half years ago and still I end up working on the sodding things for them!