I am not a big adept of the "all in one" philosophy (BMS/controller/display/charger), but more adept of the linux philosophy : a single and simple tool for a single/simple function.
And combine these simple (and then highly reliable because very specialized) tools together to do complex and sophisticated things.
For the openRevolt controller, there is absolutely no obstacle to directly connect and read the BMS slave board daisy chain, and do all we can imagine in internal controller firmware. For example SoC, limit discharge current to not have a brutal power off when battery are low, and so on.
To connect my BMS slaves, just need a free uart and very very simple interface, just some resistor/transistor, opto-isolation is directly on the BMS, on the first and last slave boards.
From my opinion, the perfect EV infrastructure is :
- A mother board calculator (brain of the EV), manage all input/output, precharge/main contactor, throttle/breake, charge relay, current measurements, motor temperature and so on.
- The daisy chained slaves board directly connected to calculator to always have in real time all cell voltage and temperature, and be able to do SoC and other useful function
- One or more controller which receive their torque consign from the mother board (with CAN bus). Very useful configuration for multiple controller/motor EV, because the differential gear is totally natural in torque consign mode (current mode).
- A tactile optionnal display, connected on the mother board calculator, and deported on the dash board. Display which can be a smarphone if motherboard implements bluetooth
I designed the power train of this
without driving license vehicle, and exactly used this architecture. There is a controller on each hub motor wheel, thus 4 motors/controllers (the controller I talked about in the Paul and Sabrina AC controller topic), connected to the mother board with CAN bus, and this architecture is really simple, evolutionary and reliable !!