ENNOID XLITE & VESC

I was thinking a little bit in the OW BMS solution. It started after having a conversations with other user about changing from 15s configuration to 18s or going 19s/20s. Being 24s version the only alternative for the latter and being way overkill for that need.
This is not meant to criticize or demand, but just to give an opinion of the needs about OW, and not in a more general use.

So find here a wishlist of the perfect BMS for OW (IMHO):

  • as good as current Ennoid BMS with all its features, bells and whistles
  • charge only (discharge too in the future depending on demandā€¦)
  • dimensions to fit in the OW battery box, doesnā€™t need to be much tinier if the cost increases (as it should be great keep under the $150). If doesnā€™t increase the cost, of course smaller is welcomed assuming always being easy to access the ports
  • no need for soldering, all connections have to be prepared to be connected via ports. Adapters may be needed (like XT60 inverted problem of the OWā€¦)
  • just one version capable for 15s-20s configurations. This is the sweet spot configuration for OW, no one wants less than 15s (useless) or more than 20s is just out of the scope for OW (having the current VESC solutions), being this range open for a nice improvement if wanted. Besides the less variants the easier production wise.
  • managing 15s as optimal as 20s (or as much as possible, as was stated that 24s BMS would not be as optimal working @ 15s as the 15s/18s version) and therefore the reason of a 15s-20s only version, being 24s way overkill for OW and not being optimal

I know you are busy, and I know that could be difficult or problematic. Maybe I am just dreaming about it, but if this could be feasible, just take my money right now :).

Thanks for reading

1 Like

I think (someone correct me if Iā€™m wrong) that the S number ranges come from the BMS ICs supporting up to 6 battery cells. So if you use 3 ICs you get 18 cells and if you use 4, you get 24 cells. Then it makes little sense to limit the number to e.g. 20 as the only significant difference would be in connector size?

That means both 13-18S and 19-24S versions make sense for a OW. Practically Iā€™ve read about people going for all of 18, 19 and 20S (if going up from the stock 15S):

  • 18 is a good number from the BMS perspective
  • Igor Samul on FB is designing a battery case for Onewheel XR that will fit 19S2P 21700
  • 20S if you want to max out the Little FOCer

(FWIW Iā€™m still pondering which S to go for, I have two boards and Iā€™d like the same S on both so that I donā€™t need two sets of chargers)

Regarding the discharge BMS, Iā€™m sort-of coming to the understanding itā€™s just the better way to do it, but either set discharge limit waaay above the VESC limits or have the BMS communicate with the VESC as @ENNOID already described. Plus there are the issues with size + heat managementā€¦ Iā€™m very much fine with the first iteration being charge only and Iā€™ll be using a fuse to protect against a shorted VESC.

Letā€™s wait for the first narrow version and iterate from there :slight_smile: and if the project moves forward with good Onewheel support and features Iā€™m sure there are a lot of people willing to spend money to support it. Igor told me heā€™s done some advertising :slight_smile: if you check back on my poll there are more votes now: DieBieMS fork: ENNOID-BMS for 6S to 24S battery packs - #189 by Zippy

2 Likes

I thought there are ranges of BMS ICs support: e.g. 2-5 cellsā€¦ If there is some up to 5 (and not 6), and we have 4, we could have from 15S to 20S.
I mean, maybe I am wrong, but I think could be ways with a proper design.
Anyway, letā€™s wait for the narrow version. I was just trying to find a solution which satisfy EVERY scenario (from vanilla to the max) for a OW user (well, except the charge/discharge version, but the rest), without the need of having more than one version, which is always more costly.

1 Like

The 24S version uses two LTC6811 IC.
18S version uses one LTC6813 IC
15S verion uses one LTC6812 IC.

There are some other alternatives for high end monitoring IC on the market, but they are not yet supported in the firmware. I donā€™t think it is worth spending time supporting those other IC at the moment. They all have similar prices and features and the LTC have still a good availability.

The 24S version could be bricked to 20S on the hardware side, so it would be more or less the same price than the 18S version. Going above 20S makes everything more expensive because there is not so much choice above 100V for power supply & mosfets and you must keep some headroom. 20S approx 84Vmax would be still ok.

3 Likes

If I understood well it sounds great to me. So, what I understood is that is feasible to make a 15s-20s version, at kind of the same cost as the 18s (so without the increase costs of 24s), as for OW is not needed going beyond 20s.
Just have a question, on 15s mode (meaning standard OW battery specs) will be as optimal as the 18s version? Or have the same problem as 24s not being optimal?
If it is optimal, this is what I was asking for: just one version to rule them all (OW), 15s-20s which has all the specs everyone could want from standard to the max!! The motivation is not having the need to buy another BMS if you wanna reach the max of OW, as you have everything in one.
Thanks Ennoid for all the info

1 Like

I confirm that a board having 2 x LTC6811 hardware bricked to 20S max. could be designed to be optimal for 15S to 20S packs in a narrow design. Might be more practical/easier to design while keeping the connectosr far from edges due to the LTC6811 narrow form factor.

2 Likes

Man, it could not be better. Thanks!!

Finally got around to use my 15S-SS. Pack is 15S4P Samsung 30Q

5 Likes

Iā€™m thinking of using the LITE version flat on top of my Pint battery pack. The available height is about 26.8mm, so thereā€™s 5.8mm on top of a 21700 pack. Looking at the 3D model it seems itā€™s well doable with room to spare for fishpaper and even a bit of padding, if I:

  • get rid of terminals and solder battery/charger wires directly
  • get rid of the JSTs and solder balance/thermistor wires
  • either remove the buzzer or again connect it via wires
  • position the pcb so that the USB connector hangs over the side of the pack

What do you think @ENNOID? I was also wondering, on the charge-only version, thereā€™s no need for thick wires and those big terminals is there? The maximum current going through those will be the charging current, so I could go as low as e.g. 0.3mm2 (AWG 22) on those?

@TheBoardGarage IIRC you were planning something like this, how did you want to do it?

I havenā€™t actually thought about it yet. I got so backed up with other stuff that the ENNOIDs are still sitting in storage until a month or so from nowā€¦

1 Like

If you want to use the build in shunt for current measurements your main negative has to pass through the BMS. If all you want from the BMS is the charging and balancing then thin wires are enough.
But maybe then another BMS would be better for your application if you have no use for all the other features the BMS has.
Iā€™m also not sure if you can remove the terminals without damaging the pcb because they are press fit.

1 Like

Main wurth terminals can be unpopulated at production upon request.

Getting rid of JST connector & direct soldering is a terrible idea. I tested this long time ago and resulted in many issuesā€¦best in your case would be to use horizontal JST connectors.

Even better would be to either find a way to make it fit as is or wait until the planned SS-XLITE-20S comes out. I have been thinking about building a compact XLITE version as mentionned above for 18S, but with all part shortage ongoing and the good results Iā€™m getting with the just released 24S version, I think it is better and cheaper to go straight to 20S or even 24S for the future XLITEā€¦ so basically one XLITE version to rule them all.

Oh and by the way. Just invested quite a good amount recently on inventory and tooling like a nice pick&place machine. So, I should be able to take more order soon.

4 Likes

I will be very interested in a 20s (100A) version also.

Iā€™m quite sure even horizontal JSTs will make the total thickness exceed those 5.8mm :frowning:. Also, the balance connectors are in two rows on the PCB, so I donā€™t think I could fit the horizontal JSTs anyway?

Could you please list the issues? I still might give it a go if I donā€™t find a better way to do 20S and the issues could be alleviated. Is it just the wires not holding well soldered to the small pads? Could I maybe use very thin wires and stick them through the holes? :grimacing:

That is really great and thank you for that. I know I have been asking for it and Iā€™d use it, but in the end I want to go for 20S and I can only fit 4 cells into the controller box, meaning I have to fit 16 cells into the battery box and the only way to do that is to remove the BMS slot wall and use all the space for a 2x8 cell layoutā€¦

The ballance connectors are the one on the edge of the pcb. the 2nd row is all temperature.

Have you thought about moving the bms to the controller box? or is there no space either?

1 Like

5.8mm is very little thickness. I donā€™t think it will fit there. I would need to measure directly, but there is the inductor for 3.3V that might be higher a bit than what is on the step file and cannot be removed.

Direct soldering of 19 thin wires on a PCB is a very bad idea. Problem is: the thin wires soldered ends cannot be bended at all otherwise they break. It is very rare that you donā€™t have to bend just a bit one of those in the long run. The break point is sometimes invisible because the wire skin still hold it in place. Trying to trobleshoot and resolder a broken wire end up into shorting stuff unless you can disconnect the pack on the other end.

4 Likes

SS-24-HD which should be good up to 120A & 24S can be pre-ordered on the website already.You can connect a 20S pack to itā€¦

@ENNOID Is the can implementation on your bms the same as on the DieBieMS or did you change it?

I tried to see if the ennoid will work with the davega since it does with the DieBieMS and ennoid is a DieBieMS fork.
But the davega only shows the icon for communication error.

The implementatiom is almost the same, but some very small changes are needed as mentionned somewhere on this thread long time ago. I changed some packet ID in order to add new functionnality and make sure they donā€™t go into conflict with latest VESC commands. I suspect that the packet ID used on DieBieMS might have some issues with the latest VESC firmwares. I donā€™t know who I should contact exactly at Davega to make this works. Would be better to have an option specifically for EBMS instead of DieBieMS

2 Likes

Iā€™m happy to add support to DAVEGA. It would be difficult to do without being able to test though. Would it be possible for you to provide me with a BMS to test with? I would send it back when finished.

4 Likes