New batteries from FreedomOne. About R25k per module. Looks pretty good on paper.
They look ok. They have exactly the same cells that Freedom Won use in their other batteries, but instead of the Orion BMS, it has the same BMS that Hubble uses.
What would this mean to the end user?
I suspect it would mean very little, but I like the Orion BMS that Freedom Won use in their other batteries. I’m not sure how good this other Chinese BMS is, so that’s the only thing I would be slightly concerned about.
1 Like
At least it has a 10 year warranty unlike the 5 year on the Pylon UP5000
@plonkster I know you really like the Freedom Lite BMS for interfacing with Victron… Have you got any thoughts on this new one?
No. It’s not the first time they used a cheaper BMS, they had a 24V battery some years ago also with a simpler non-CAN-bus BMS, also without precharge. But when it comes to Victron, I’ve only worked with sites that has the OrionBMS, so I cannot offer much of an opinion at present.
They mention Victron on the product sheet. I assume an integration just need to be written and then pushed to the GX.
• CAN Bus (RJ45 Socket x 1) - for interfacing with compatible inverters and system controllers (the eTower is fully compatible with all common CAN bus compatible brands)
• Inverter interface CAN Bus cable at 1,8m length for connecting compatible CAN bus equipped Victron inverters
Yes, I saw that. I don’t doubt that it will work with Victron equipment out of the box since they even supply the correct cable in the pack.
The Freedom Lite BMS does however communicate a “requested charging voltage” from the inverter over CAN which works better / nicer / faster (some or all of those) when compared to “requested charging current”. (It does both, for compatibility I presume, and Victron equipment prefers to follow the voltage requests, but this is second-hand knowledge at best.)
@plonkster mentioned in the past that the voltage control is very nice and preferred (by him personally), so I was wondering whether we lose that in the new e5000 BMS.
I have no way of knowing. I assume FreedomWON tested it properly. You will note that the eTower is not on the battery compatibility page (yet?). But if FreedomWON says it is supported, then you at least have the support of the manufacturer, and it should be perfectly safe to go there.
Yes, I confirmed with Antony that it is supported and the charge parameters are as per existing Victron / FreedomWon documentation. I’ll also get my hands on one and confirm for myself. I will update that to reflect the eTower and there’s also a change to the documentation required about the lifting of the 3000A limit in VenusOS > 2.7 (iirc).
It should be supported. As far as I could tell it was sending the same CAN messages that Pylontech use. So since the Pylontech protocol is supported then the eTower must be supported as well. It reports the manufacturer name as eTower iirc.
I kinda smile at the fact that that has become the name 
The original protocol comes from SMA, if I have my facts straight. They made up something so batteries could talk to their equipment. As is often the case, everyone copied it, and added some of their own stuff.
Pylontech has their own set of extensions. BYD has some of their own stuff. And Victron has added their own extensions as well, something I can report has been well accepted and implemented by battery makers.
The one basic difference between Pylontech (and a few others which I will not disclose just in case some NDA is involved), is the alarms/warnings mechanism is different. Pylontech sends this on 0x359. The others send it on 0x35A. Pylontech also identify the battery by sending the letters PN in the relevant locations in 0x359, while the others send 0x35E with an 8-character manufacturer name.
But on top of all of this… Pylontech has implemented the Victron extensions. But it only activates if it is in a Victron system, and this was actually designed into the extensions as well (with input from BYD): Victron systens sends the frame 0x307 with the last 4 characters spelling VIC and a zero (so it can be incremented if necessary). When the battery sees that it is in a Victron system, it activates additional parts to the protocol.
Soooo… there is a lot more to “protocol” than most people know
Now this reminds me somehow of the Boeing 737 Max, though I am sure the analogy is not perfect. So Boeing had a problem, Airbus were giving them a hiding in fuel economy stakes and to compete, Boeing had to shove a better turbine under the wing of a 737 airframe. But the turbine wouldn’t fit, so they had to move it slightly forward and up, and this caused the machine to be a little prone to handling issues, so they fixed it in software. And then we know what happened there…
The reason for all of this hacking, is they needed the new 737 to be the same as the old one, otherwise airlines would be less likely to buy it, because going to a new plane means all your pilots have to do a conversion. It is not like a car where being able to drive one qualifies you to drive them all. They needed to be able to tell the airlines: Your existing 737 pilots can just get into this thing and fly it! No conversion required!
Well… when a BMS is swapped, I feel just a little like that. I feel like it is a different battery. It is probably fine… it is not a plane after all… 
1 Like
I suppose I think of it as the Pylontech protocol since that was the first battery whose CAN protocol I had to implement. Pylontech sent me their protocol documentation. Since then I did notice that most batteries use a very similar protocol. I wasn’t aware the SMA started it, so that is quite nice to know. Should we call it the SMA protocol then?
1 Like
CVL \o/ yey
Aaah the manufacturer string is eTower then, so it is being recognised as a generic battery. Well, that is perfect from my perspective. Seems like it supports the whole protocol too.
Ps. This was on 2.73. So DVCC is not automatic (forced on) on this version - and perhaps never will be as I think it is only for officially supported batteries?
Yup. The forcing of options is to set it up as the manufacturer wants it, and to make it easier for installers as well as reduce the required support. For generic batteries, that’s up to the installer/user