The conclusion I think I get, out of all that has been said so far: @Louisvdw driver, now that we know we can stop the charge at any SOC we want, is a huge win.
What @Stanley mentioned about large amp BMS’es and FET’s and the challenges with that, something to keep in mind. @plonkster feedback overall and his suggestions/advices. @Phil.g00 throwing a curve ball of 18 x 280ah cells @Gman and what he sees “others” do in their R&D
I think we need to take what we know so far, are ordering in, and master it.
Methinks, setting these large AH banks, any bank for that matter, to run between 20/80/20/80 SOC, giving the BMS more than enough “headroom” to do its thing IF there is an issue, with the 20/80 SOC supposedly further opening more opportunity for a much longer cycle life, is a whole new world we are opening up.
And IF we/I find that this latest model JBD BMS must really REALLY still have separate Charge/Discharge ports, then we source another brand on Alibaba, much cheaper than AliExpress. BMS’s are not that expensive if one imports wisely.
Also, I’m keeping in mind, with all the back and forth with JBD the last few weeks having had to explain why we would like to have the ports separated, MAYBE they picked up on that and make one.
All the above assuming no one comes up with a clever idea to split the charge/discharge with what we have, like using one BMS for charging, a 2nd one for discharging, by using the settings, of which JBD has a lot of.
Would be neat if one can do something to base the charge voltage on the maximum cell voltage.
Long time ago this is the one I used. In this example, mcv is the measured voltage of the highest cell, and cv is the charge voltage I’m going to aim for. bms.voltage is the measured total voltage of the battery now. This has an exponential decay filter on it (the previous calculated value is worked into the next calculation), to smooth it out. That is why 80% of the old cv is used in calculating the new one.
if mcv > 3.6:
offset = 3.6 - mcv
new_cv = max(bms.voltage - 1, min(56.8, bms.voltage + 8 * offset))
cv = 0.8 * cv + 0.2 * new_cv
else:
cv = 57.6 # or max cell voltage times cell count
When I made this, I didn’t have access to all 16 cell voltages. You can make this a lot better if you have access to all the cell voltages. I only had access to the highest and lowest. The assumption here is that at least half the cells are low (hence the 8 * in the calculation, it estimates how much room we really have above the current battery voltage).
The other trick is to make sure you don’t generate too harsh a step with the if > 3.6 branch in the code.
By running this every few seconds, you get a charge voltage that smoothly drifts downwards when a cell exceeds 3.6V. It automatically makes room for it.
If you have access to all 16 cell voltages, you could much more accurately calculate how much room you have. The charge voltage should be the current battery voltage, plus just enough to keep some current flowing, but to keep the highest cell below 3.75V. And smooth it down.
After spending a day watching Andy’s videos at The Off Grid Garage, jis he likes Victron and Amy, really enjoying watching his learning curves, AT LAST I have this scenario below, even with the Grid Setpoint set 50watts … NOTHING is going to the batts!!!
And FWIW, these 150ah cells, using them in 12v batches, they are staying perfectly in balance … so far at least. Yesterday’s batch of 4 needed no balancing whilst they were being charged.
@Louisvdw driver, the last “protection” at 95% SOC to stop dead all charging, just in case a cell shoots out again.
I think I’ve got the settings now … there is nothing like learning from a unbalance bank, just like Andy experienced.
If that can be added to Louis driver … man, then I think all bases are covered “dubble en dwars”.
That’s not too hard, I’m sure @Louisvdw could add something like that to his driver.
(I am assuming the driver set’s a charge voltage limit which can be adjusted on the fly)
For my battery balancer I just made it do a linear taper of the charge voltage based on the highest cell voltage. I have settings for the ‘nominal’ voltage (in my case I set it to 3.450VPC so the target voltage is 55.2V on a 16 cell pack if all the cells are ok), then 3 more settings that define the charge voltage limiting. The ‘start limiting’ voltage (I am using 3.500VPC) and the ‘max limiting’ voltage (In my case 3.600VPC) then also the ‘minimum target’ (Not in VPC. I think I made mine 54V). So basically if all cells are below 3.500V then the target voltage for the system is 55.2V, but if any cell is above 3.500V then the system target is reduced in such a way that by the ‘max limiting’ voltage the target will be the minimum (54V in my case).
The big issue I found while playing with the charge voltage limiting based on what the battery votage is, is that the voltages is not always measured the same in the inverter/MPPT/BMS. In most cases we are talking about small voltage adjustments (0.15V-0.3V) and those are the measurement tolerances between systems as well. I will need to have an option to set an offset or something.
This is also where I started looking at the CCC (Charge Current Control) cause trying to adjust mV battery charge voltage adjustments while the chargers are pushing 50A or more is just imposible.
Yes, that is indeed an issue sometimes. You need to allow a “window” (as Stanley said, 3.5V to 3.6V), where you start reducing the charge voltage early enough so you have some room to work with. What happens then is that the difference in calibration gets absorbed into this window. The BMS (or the driver) would reduce the voltage setpoint until it the highest cell(s) are where they should be. If at that point, the battery is 0.5V higher than it asked for… who cares!
Also, the use of an exponential decay filter helps a lot to keep it stable. You can adjust your alpha factor so that new readings weigh heavier than old ones, and this depends a lot on how often you get new readings (my algorithm was implemented on top of a BYD battery that only send data every 3 seconds or so… really slow).
Some experimentation may be required. What you want to do is not adjust the charge voltage so suddenly (unless you must) that the Multi is dumped into a large overvoltage situation. In systems that feed excess DC-coupled PV into the grid, this causes them to go into full discharge-into-the-grid mode
Aaaai you Windows people. The other day I had to watch (from the sidelines) a developer squirm when asked to generate a cryptographic keypair for SSH login on the Linux servers of my wife’s previous employer… apparently it took like three tries to get it right
I am well aware… I occasionally have to use TV to access a shell-impaired OS
Do not take me too seriously… I am only kidding around. My wife hates TV even more than me. Her previous job involved working on farmers’ windows computers via TV. They always have it set so you only get in once. The farmer gets up at 6AM and expects you to be around… then he is never around for the rest of the day should the connection drop and you need to get in again… and if he needs to do something on the computer, he simply kicks you off. So so sooo many days we were wishing for a Linux computer we can just ssh into
This is for those who don’t know how powerful remote support can be, not all of us “hate it”.
Yonks ago I used PC Anywhere, then Remote Desktop (kinda like to ssh) came out, today Teamviewer, Anydesk, to support clients, friends, family.
You guys obviously know TV/Remote Desktop/Anydesk can be temporarily made to auto-start/login … so that one can reboot whatever without client intervention, as the people I help also have lives and cannot sit there all the time watching a boring screen, so they can go. If I need them to do something, I WhatsApp / phone them.
Once and just because, using TV and Skype video call, I talked a client remotely through in replacing their old HDD’s with SSD drives, had to Ghost their PC’s onto new the new SSD drives at night. They were so chaffed to learn how to replace HDD and add more memory modules themselves.
That reminds me of pushing envelopes … I even show clients how to run SQL DB Scripts, their DB, their data … remotely.
IT people want to “die”, me, I wonder how anyone in their right mind can break any DB with a select statement …
I’m just really thankful that you can run the Linux version of teamviewer without having to install it (straight from the tarball/zipfile). If I need to support someone remotely, I can do it without violating the purity of my laptop
(It’s proprietary code. You don’t know what is in it, and there have been cases of security breaches. Man… I sound like a digital anti-vaxer! ).
We speak a lot about the volts and SOC and all that.
What I’ve noticed for a long time now, even though I set the charge volts at 3.45v per cell, I seldom if ever see the system getting to those voltages.
Reason being, the Ah counted going back into the bank, gets to the 100% SOC before reaching 3.45v.
Just more confusion … anyone want to try and explain to me how that works?
The SOC is prone to drift since it relies on counting the AH in and out of the bank. If possible I would set it to continue charging up to 3.45VPC even though the SOC reads 100%
I think that could be a question for @plonkster if it can be set in your GX device, or it could be a question for @Louisvdw if that is controlled by his driver.
I’m not sure what the problem is. Victron systems don’t stop when the BMV/BMS says 100%. It stops when it reaches the mandated charge voltage. Unless you are doing something weird, it should continue on “past 100%” until your cells are at the required voltage.
