This started as a bit of an experiment.  I needed the cheapest 10kW upgrade I could lay my hands on, and found these:

https://www.communica.co.za/products/batt-12-8v200-chp

I then went deep down a rabbit hole writing Bluetooth drivers to communicate with these batteries, and my existing Daly set up. Also to manage series and parallel banks. And to spit out Pylon compatible CAN messages to safely manage the combined packs through the inverter.

https://github.com/justinschoeman/BLE_Bat

So far, everything seems to be working, and all the basics are testing well.

Just be very aware that when paralleling dissimilar packs like these, the best pack will take for more than it's share of the load - so the strongest pack should be capable of handling the full inverter load, and it will also wear faster, as it will handle all transient charges/discharges...

What does work well:

• Bluetooth BMS comms (Vestwoods and Daly)
• Creating a virtual series battery out of 4x series batteries
• Balancing 4x series batteries
• Creating a virtual parallel battery out of 2x parallel batteries
• Sending Pylon compatible BMS protection parameters to a Deye inverter over CAN bus

There is still a lot of work to clean up/modularise the code, but it should be a good starting point for any-to-any battery/inverter combinations.

 

One thing about these Champion/Vestwoods batteries:

The cells are not well matched at all, but it has a very strong balancer to get them back together when fully charged. 

After a long, hard discharge:

Inverter current drops to 0, but the Daly bank is now recharging from the Vestwood bank (the Daly took more than its share of the load during the heavy discharge, and the Vestwood is now catching up).

As mentioned, mismatched banks are not a great idea - the strongest bank will end up wearing faster.

13 hours ago, JustinSchoeman said:

After a long, hard discharge:

Inverter current drops to 0, but the Daly bank is now recharging from the Vestwood bank (the Daly took more than its share of the load during the heavy discharge, and the Vestwood is now catching up).

As mentioned, mismatched banks are not a great idea - the strongest bank will end up wearing faster.

Interesting, solution.  👍 2.56kw lithium for just under R10k is indeed low. 

All said and done, do you foresee this configuration working for you as expected.? 

By the way, does these bms's, eg Daly, allow you to control the Charge and Discharge MOS switches of the BMS, under protocol control? . Example there may be a tine where I want to switch the Daly battery discharge off for some reason. 

Edited March 19, 20231 yr by BritishRacingGreen

2 hours ago, BritishRacingGreen said:

All said and done, do you foresee this configuration working for you as expected.? 

Yes - but only because my existing Daly bank is heavily overspecced. It should be able to handle the small equalisation charges without seriously impacting its life.

Personally I would not do this with marginally mismatched banks.  Either heavily mismatched, like I have, or try for perfect matching and balanced packs.

The software I have written should handle both cases quite well.

2 hours ago, BritishRacingGreen said:

By the way, does these bms's, eg Daly, allow you to control the Charge and Discharge MOS switches of the BMS, under protocol control? . Example there may be a tine where I want to switch the Daly battery discharge off for some reason.

Maybe.  Would need to do some more research.  The Daly doc I have only lists read ops.  The Vestwood doc I created by reverse engineering an app which only has read ops...  So it is possible that either or both of these BMSs do support manual MOS control - but I would need to get better docs and/or applications which support this to reverse engineer.

I did find this project, which has the protocol for turning Daly BMS FETs on and off:

https://github.com/maland16/daly-bms-uart

So it would be fairly trivial to add this. (Just use with extreme caution obviously. Turning off the charge FET while charging will cause bus voltage spikes which can damage the inverter.)

17 minutes ago, JustinSchoeman said:

I did find this project, which has the protocol for turning Daly BMS FETs on and off:

https://github.com/maland16/daly-bms-uart

So it would be fairly trivial to add this. (Just use with extreme caution obviously. Turning off the charge FET while charging will cause bus voltage spikes which can damage the inverter.)

Yes, I was thinking along the same lines, the BMS should ideally only allow an enable of MOS if its a  more or equal restrictive state, otherwise it should veto it. 

Better term would be enable/disable as oppose to on/off.

Edited March 19, 20231 yr by BritishRacingGreen

Balancer in action - 3 batteries getting 2A less that the other which the balancer tries to balance them:

And charge derating also working as expected:

First the Daly (blue) has a high cell and starts derating requested charge current (purple), then the Vestwood bank peaks, and it controls the derating.

Inverter charge current is always controlled by the most limiting bank, when any bank tries to limit it. (When no banks are limiting, then charge limits are set to the sum of all banks.)

After a disco show from those indicator lamps, the Vestwood bank is balancing nicely:

But I think I can conclusively say that the Heltec on my Daly bank is toast:

On 2023/03/20 at 2:51 PM, JustinSchoeman said:

But I think I can conclusively say that the Heltec on my Daly bank is toast:

Can you explain? 

EDIT:  is the Heltec a balancer? 

Edited March 22, 20231 yr by BritishRacingGreen

If I introduce a protocol converter like yours that produces canbus  traffic for the Sunsynk  (Pylon Canbus message ids),   will the sunsynk gracefully and silently drop  any other foreign message ids that it consumes   on the same physical can link.? Or will it abort with errors? 

I am thinking along the lines of adding battery packs in parralel with jbd bms, each with their own protocol converter, but one is master and others are slaves with ids from dipswitches. The master will produce bms messages for inverter, the slaves will produce battery metrics meant for master, all on one can link. 

EDIT : the preffered way would be for each protocol converter to have an uplink and downlink, ie two canbus instances per device, but that increases cost. 

Edited March 22, 20231 yr by BritishRacingGreen

57 minutes ago, BritishRacingGreen said:

EDIT:  is the Heltec a balancer? 

Heyup.

46 minutes ago, BritishRacingGreen said:

If I introduce a protocol converter like yours that produces canbus  traffic for the Sunsynk  (Pylon Canbus message ids),   will the sunsynk gracefully and silently drop  any other foreign message ids that it consumes   on the same physical can link.? Or will it abort with errors?

When I was initially testing, I got the frames wrong many times. The inverter certainly seemed to silently ignore all bad frames - but I can not guarantee this.

52 minutes ago, BritishRacingGreen said:

EDIT : the preffered way would be for each protocol converter to have an uplink and downlink, ie two canbus instances per device, but that increases cost. 

If you don't need bluetooth, then try an RP2040 board.  Can run 2 software CAN implementations (can2040), and only need transceiver boards per port (R6ea).  That way you can have a cheap solution with 2 separate CAN ports.

44 minutes ago, JustinSchoeman said:

When I was initially testing, I got the frames wrong many times. The inverter certainly seemed to silently ignore all bad frames - but I can not guarantee this.

Thanks, fortunately I will have a Sunsynk 8K on my bench for a week or so, courtesy of  @Steve87 for this integration purpose.

44 minutes ago, JustinSchoeman said:

board.  Can run 2 software CAN implementations (can2040), and only need transceiver boards per port (R6ea).  That way you can have a cheap solution with 2 separate CAN ports

😁 Guess what, I decided last night to migrate most of my baremetal requirements to RP2040. I was torn between the ESP32-C3 (RiscV)  and the RPI Pico W.   The Pico won on 3 scores : (a) picoprobe debugging, (b) USB Host and Device mode via TinyUSB , and (c) the PIO slices. Also the standout raspi documentation. 

I have integrated the MCP2515 and MCP2551 phy also  last night and its fast, I verified the production of  500kbps can messages at cyclic period of 5ms. 

I am aware of can2040. Its also well documented. Have you perhaps tried it.?  You are biasing me towards giving it a go. 

Edited March 22, 20231 yr by BritishRacingGreen

1 minute ago, BritishRacingGreen said:

I am aware of can2040. Its also well documented. Have you perhaps tried it.?

Have not used it yet, so the pointer is the best I could offer...

3 minutes ago, BritishRacingGreen said:

at cyclic period of 5ms. 

Which reminds me... You may notice a 5ms delay between CAN transmissions in my code. Not documented anywhere, but send much faster than this, and the inverter starts ignoring them.

14 minutes ago, BritishRacingGreen said:

MCP2551

P.S. why not a 3.3v transceiver?  This must cause needless headaches?

I am using the breakout module as in this link, along with a mod to power the 2515 by 3v3 and the 2551 by 5v:

https://forums.raspberrypi.com/viewtopic.php?t=141052

I know the 2515 has an operating range of 2.7 to 5.4 v, but i am not sure if is is strictly 5v tolerant when operating at 3v3. I have never actually checked.  

I will of course consider a 3v3 phy for production. 

 

I have done that, but it is not reliable.  The 2551 back-powers the 2515 to 4.3V through the pad diode, which pushes Vih to ~3V - which leaves no noise or timing margins, so you end up with lots of random glitches, especially when there is a lot of bus activity.

Probably OK for testing, but don't be surprised when you get SPI transaction errors every now and then.

@JustinSchoeman hi Justin,  i just couldnt wait after you wet  the appetite regarding can2040. I rolled out one instance of can2040 on pico,  and one MCP2551 phy. I powered the phy with 5V  but level converted its rxd output to 3v3 tolerances via 270R and 500R divider. 500kps can bitrate. 

I am really impressed with the performance and am currently producing at 2ms intervals  long term tests. The receive side is also very stable. 

Although one needs to test the claims that the author makes (low cpu usage overhead etc) , I can see a very low cost dual canbus controller, even with wifi.  This excites me, we talking ridicoulous low cost. 

Below is the entire hardware interface :

Edited March 23, 20231 yr by BritishRacingGreen

Excellent! Looking forward to seeing your results.

Hey @JustinSchoeman

 

I also bought the 200AH champ, but I am running just a single one of them in 12v with a victron inverter. I see you noted they were out of balance, something I've been dealing with badly now since I got mine months ago.  They still are quite different and I have had to set my actual bulk voltage for charging to 14v because it would hit the over alarm on one of them if I didn't

Are you seeing the same? Do you have any recommendations?

Also thanks for the BLE stuff. Going to set that up and hookup to my home assistant.

 

Matt

Yeah.  The cells are all over the place.  Mine are working fine, but only because I have active management of charging to allow them to balance every day.

Not sure what options you have with Victron.  Perhaps you can use Louis' serial driver together with ble-serial to get your inverter to manage charging/balancing of the batteries?

I'm confused, are these Lithium cells or lead acid cells?  They look a bit like lead acid.  Where did you buy them and at what price if you don't mind my asking?

Some thoughts:

• Daly are not great BMS.  You have what you have, so I guess that ship has sailed, but for someone starting over I'd look at other options.  It is kind of bad at everything 😅
• BLE is both the strongest and weakest part of this design IMO.  It is super flexible because you can easily add support for more batteries.  Almost all of them support BLE these days.  The weakest being that BLE is quite unreliable IMO, I prefer RS232/RS... based protocol but I think if you can get BLE to work reliable it is much more robust in the sense that it doesn't require creating wiring looms & pin diagrams.  Doesn't need to worry about voltage levels, isolation, etc.  I'm torn.  If I did this I'd start with serial.  But I actually think BLE is likely the more universal solution.  How reliable are you finding the BLE communication to be?

Edited April 24, 20231 yr by Gnome

11 minutes ago, JustinSchoeman said:

Yeah.  The cells are all over the place.  Mine are working fine, but only because I have active management of charging to allow them to balance every day.

Not sure what options you have with Victron.  Perhaps you can use Louis' serial driver together with ble-serial to get your inverter to manage charging/balancing of the batteries?

So I have have a single battery with the actual cells inside unbalanced. Not sure how I would actively manage a single battery to balance them?

 

Vestwoods rep hasn't been great to get resolved. My mate has suggested taking it apart and balancing the cells properly myself.

Edited April 24, 20231 yr by Matt de Haast

12 minutes ago, Gnome said:

I'm confused, are these Lithium cells or lead acid cells?  They look a bit like lead acid.  Where did you buy them and at what price if you don't mind my asking?

Some thoughts:

• Daly are not great BMS.  You have what you have, so I guess that ship has sailed, but for someone starting over I'd look at other options.  It is kind of bad at everything 😅
• BLE is both the strongest and weakest part of this design IMO.  It is super flexible because you can easily add support for more batteries.  Almost all of them support BLE these days.  The weakest being that BLE is quite unreliable IMO, I prefer RS232/RS... based protocol but I think if you can get BLE to work reliable it is much more robust in the sense that it doesn't require creating wiring looms & pin diagrams.  Doesn't need to worry about voltage levels, isolation, etc.  I'm torn.  If I did this I'd start with serial.  But I actually think BLE is likely the more universal solution.  How reliable are you finding the BLE communication to be?

BLE is turning out OK.  I would also have preferred wired comms, but so far BLE is doing the job.

I have a lot of timers and watchdogs, which generally reset the whole stack once every 2-3 days when one battery takes too long to respond.

At some point I may move the Daly back to RS485, as reading cell voltages requires a whole string of BLE comms to work perfectly (which is not great with 5 devices being polled in short intervals). So on the Daly side, you occasionally get 'steps':

But so far it is not causing any issues (primarily because the champion bank always ends up throttling charging).