I’m offering here hardware based on our modified version of DieBieMS renamed (ENNOID-BMS → EBMS) that will allow more than 12S.
Full EBMS version :
Charge only version “LITE” :
Extra compact charge only BMS:
**Update November 2021: we are shipping production units for SS-24 FULL BMS only at the moment due to the global part shortage. 15S & 18S FULL versions production is temporarily suspended. Charge only version named XLITE-12 & XLITE-24 are being produced in small batchest. Lot of stuff ongoing, please follow the thread for latest updates.
Also a 100V 125A ESC hardware is available:
Buy directly on the website if interested by one of our product.
There is also 24S capable versions that have the same footprints, but will come later.
Dimensions are :
Charge only version: 60mm x 100mm
Full version: 60mm x 140mm
Charge only version: 60mm x 65mm
Full version: 60mm x 100mm
I have a Ubox sitting here, no BMS for the battery yet. Planning a 16S7P 25R.
definitely would want to check this out
Nice work !
Can’t wait to read feedbacks.
BTW, where are the sources ?
Just wonder what the deal is with licencing on this?
AFAIK there’s no open source licence on the original DieBieMS hardware, firmware or tool repos. How does this work with you guys selling/redistributing derived work?
Well, project files are all on github and freely available.
But the original code doesn’t seem to have an OS licence attached so in theory the original author retains all rights for the bootloader, firmware and tool. this means that you cannot modify/redistribute/sell this code without explicit permission from the original author.
I had those discussions with Danny last year. No issue there on licensing.
I’m just pushing his baby a bit farther.
cool, just making sure its considered. Might be wise business choice to make sue you have records of that conversation just in case.
Or i guess the better solution ( if hes happy to share and you are to) would be to talk him into attaching a GPL licence to his projects then it officially becomes open source and free for all.
personally Im excited to see more charge only options for smart BMS’s and the more DieBieMS variants that exist the better the support and features will be.
This looks pretty sweet, my only reservation is the humidity sensor. What happens if the sensor trips? Does it give a warning or does it shut the bms down? I live on a boat and humidity is a constant. Also what are the dimensions?
Still working on implementation of the humidity sensor. This can be helpfull to know if there is water ingress in your battery pack.
Right now, it is just reading value. Should have configurable options IMO.
Super interested in the charge only version. I’ll defo sign up to test when ready.
Can this rebalance a pack that is very far out of balance? What if it’s a combination of 3.5V and 4.2V parallel packs?
(Taking a long time is expected, just wondering if it works)
Glad to see this being actively developed.
Sure, voltage limits according to LTC6813 IC datasheet.
A small update to show the full version “discharge & charge” 18S BMS.
Main differences with the “charge” only version:
- Discharge path is going through the PCB, so an additional LOAD+ output terminal is mounted onto the PCB
- Mounted fuse
- Precharge circuit (no need for anti-spark connector or other external circuits)
- Load voltage measurement circuit (for validating precharge is ok)
- SW connector for disconnecting the BMS power supply through an external XT90i plug for LOAD+ connector (Prevent accidental connection to the load while the BMS is powered ON, the BMS simply cannot power ON without the load connected)
This is looking great. are you planning to update these 18s designs onto your git with the other master/slave style boards?
Yes, once ready. At least for the schematics
The design is still evolving through the alpha prototypes.
Will these have Davega and METR compatibility like the original DieBieMS?
There is no major changes with the UART/CAN/USB communication interface between the ENNOID firmware & DieBieMS.
There is only more cells values that are sent during some specific communication requests like COMM_GET_BMS_CELLS. If modifications are required, they will be very small.
COMM_GET_VALUES command should be the same
There is a new command: COMM_GET_BMS_AUX used for temp sensors that will require new code into METR and DAVEGA.