Electronic – Identify this open collector serial protcol

I'm trying to analyze the serial link between two devices, respectively a motor controller board and a Li-Po battery manager, which battery powers both devices. The application is a battery-powered gardening tool.

The two devices use the same microcontroller, a Holtek HT66F018, and use what seem to be GPIO pins for the serial link, as the microcontroller doesn't seem to provide any I2C or UART or any other dedicated serial interface. The link uses an open-collector (or open-drain) connection, with external pull-up resistors and separate Tx and Rx lines, on the same wire. Q1 and Q4 are 2N5551, not 2N3055, but I didn't have the part ready and put a similar NPN. Q2 and Q3 wew unmarked in the schematic.

In the schematic uC_2 is the motor control microcontroller, and uC_1 is mounted on the battery management board.

I've tried to read the signal with a scope, but I currently struggle to identify the protocol. uC_1 seems to act as a master, as it always transmits first, and then uC_2 (not always) replies. You can tell one from the other because they pull the line low to different levels: most likely because uC_2 has a 200 Ohm series resistor on the emitter of Q3.

The figure shows an example of an exchange between the two devices: the bus is normally high, the sequence is initiated by uC_1 with a long low pulse and follows with a sequence of pulses with the reply of uC_2.

Things I've noticed:

• the baud rate seems to be about 3.2 kbaud, though there is a decent amount of jitter;

• the protocol doesn't have a separate clock, but looks a lot like the one in this question, where it was suggested that the series of pulses may be used to synchronize the devices, or that the clock may be embedded in the transmission sequence.

• So far, excluding the stop bits, there seem to be no high pulses of more than one bit-length (could also be interpreted as half-bit if this was Manchester coded); there are longer low pulses though, never longer than two bits in a row, except for the start sequence.

• The battery manager (uC_1) is expected to monitor battery voltage and temperature, though experiments we made of simulating varying battery voltage and temperature are different to interpret: the message seems to be varying in length, and seem to only change significantly when the battery voltage is critically low.

There are some more considerations, but it's already getting quite long, I'd like to see if anyone has some pointers about what the coding may be.