"IMU" stands for "current monitoring unit", based on "I" being the quantity symbol for current, since we already have "CMU" standing for "cell monitoring unit".
In the MX-5, the IMU also performed insulation testing, but in this solar application the reed relays were replaced with MOSFETs and their drivers, for switching contactors.
In this solar application the IMU acts as the BMS master, and the system controller. It accepts regular status bytes from the string of CMUs twice a second, and acts to protect the cells by turning off load or source contactors if required.
The IMU tells the CMUs what the current is, twice a second, so they can compensate for their cell's internal resistance in calculating undervoltage or overvoltage stress. All the communication mentioned so far is at 9600 b/s.
The IMU also sends commands to the PIP-4048MS inverter/charger at 2400 b/s. Initially it was planned to run a PI-control loop for charging, based on the stress level of the cell with the highest voltage. And indeed this was successfully implemented for charging from the AC input. However it was discovered that this was not possible with the MPPT charging from the PV array.
So the only things the IMU sends to the PIP now are commands for various non-default settings, on startup, since it seems the PIP will forget its settings and return to factory defaults if it is turned off for long enough.
It's quite tricky how the IMU can send 2400 b/s commands to the PIP and 9600 b/s commands to the CMUs because in fact it only has one serial output. The two Industrial Fibre Optic LEDs on the IMU are simply driven in parallel with 10 ohm current sharing resistors. So the CMUs see all the 2400 b/s data sent to the PIP and the PIP sees all the 9600 b/s data sent to the CMUs.
It turns out that, to a 9600 b/s receiver, 2400 b/s data can appear as one of only four different byte values, none of which need to be used by the CMUs and so CMU-1 simply deletes them.
To a 2400 b/s receiver, 9600 b/s data can look like any value, however the probability that they will accidentally compose a valid PIP command, let alone one with a valid CRC-16 followed by a carriage return, is small enough to ignore.
