In that case I would have added my opinion on some of the design options.
Sure, that's what this thread is for
I like the option of plugging in a buzzer for notification of disconnects or other issues.
Already included on the HMI board, disablable by a jumper for those who are annoyed by beepers ?
There's no display? Just LEDs?
Main data feed is the ethernet one. The HMI has only LEDs because it's meant as a very simple and quick to read summary of the most important informations only.
You can use your phone/tablet/PC/... check the data via the ethernet or if you want a standalone unit like some other BMSs you can strap a raspberry pi on the back of any screen you like (you want a 50" screen for your BMS? you can!
).
Data streaming? I like it simple like RS232.
Yes, of course ? lots of data and also lots of parameters you can adjust if you don't like the default values. The ethernet com will be via a JSON API so you can write your own client with or without a GUI as you prefer (I'll obviously make a GUI client, ideally just a single file web app, but if for some reason you don't like it or want to make a hardcoded mobile app or whatever, well, you can). The main reason is that APIs are very versatile, low overhead (I use an arduino nano, not a PC...), and I'll have lots of other things on the same network who will be able to get/send data from/to any other node on the network to make better and more efficient decisions (like for example activating the water heater if the battery is full and there's still plenty of sun). And the main reasons for the ethernet instead of serial, BT, wifi, ... are detailed in the first pages of the thread (but mainly: reliability, distance, speed, widespread, ...).
Now, the ethernet is just a shield and talks to the arduino via a SPI port. So if you don't like it you can totally ditch it and use the SPI directly or any other protocol that can fit on 4 wires (pretty much all of them ^^); you just need to be careful as the port is shared for the ADC so you need to stop talking when the ADC is selected but that's all.
What's your estimated fet (disconnect) ON resistance for a 300A unit?
Typical will be 0.38 mOhm (for Tj = 120 °C, 0.22 mOhm @ Tj = 25 °C) and max will be 0.48 mOhm (for Tj = 120 °C, 0.28 mOhm @ Tj = 25 °C). You need to add the PCB traces resistance but it'll be very low (basically I made it as low as I could) given the busbars and short distance.
That translates to those power figures per mosfet (for Tj = 120 °C, values are slightly rounded; design is based on 300 A continuous and 400 A peak for 20 sec constraints):
typ 0.19 W @ 100 A (3.8 W total)
typ 0.76 W @ 200 A (15 W total)
typ 1.7 W @ 300 A (34 W total)
typ 3.0 W @ 400 A (61 W total)
max 0.24 W @ 100 A (4.8 W total)
max 0.96 W @ 200 A (19 W total)
max 2.2 W @ 300 A (44 W total)
max 3.8 W @ 400 A (77 W total)
Which is 99.78 % efficient (99.72 % worst case) for 300 A at 3.2 V nominal/cell.
Edit: for fun I calculated at 100 A and I get 99.93 % typical, 99.91 max.
Would you be using the same (high voltage) fets for a 4S & 8S system?
No because there's no good reason to do that and lower voltage mosfets are less expensive and have a lower Rdson, but I'll leave more margin as here the 80 V mosfets are a bit tight for a 64 V max system so the TVS don't protect the them as much as I'd want (but the mosfets are avalanche rated well over what they should see, so that's okay; I'd just wanted more margin ideally).
But if you change a few components on the 16S disconnect board (IIRC just the 4 power resistors and the PTC fuse, and maybe the resistor biasing the zener) you'll be able to use it with the 4S and 8S BMS board if you want (no changing of the connector type or pinout BS like apple likes to do...). Actually you'll be able to use it as is but the precharge/recovering currents will be far lower than what they should be (and V_PRECHG_TEST might not be in specs so you may still need to change the zener bias resistor).
