Possible idea to fix slow Break time on serial-based controllers degrading refresh rate

[ThierryMGTX]

Hi.

Having the same problem on another platform (Linux, PC), I found another solution : instead of explicitely sending a Break, if we send a null byte at a slow enough baudrate, it will be interpreted as a Break followed by the Mark-After-Break on the fixtures' side.
(I thought about this trick first for microcontrollers with rudimentary UARTs which can't explicitely send Break states).

Therefore, in the _transmit() method from the SerialController class, instead of :

        # Write
        self.__device.send_break(100e-6)
        sleep(10e-6)
        self.__device.write(data)

I would do something like :

        #self.__device.flush()
        self.__device.baudrate = 80000
        self.__device.write(bytearray(0))
        self.__device.flush()
        self.__device.baudrate = 250000
        self.__device.write(data)
        #self.__device.flush()

Because the serial device stays opened, we need to flush the write operations before changing the baudrate (it is not done in the Serial class, despite the reconfiguration), especially just after writing the null byte at a slower baudrate.
However, whereas a flush after writing the DMX data is required in a raw test of this code snippet, it seems to break things when done inside the SerialController class, for an unknown reason.

So the fix can unfortunately not be validated yet, not counting that I can't test it on several platforms.
By the way, the raw test shows a refresh rate of 34Hz or a bit more (VS the theoretical maximum of 44Hz) for a 512-channel frame : it seems not so bad, given the processor time consumed by the Python interpreter and all software layers down to the kernel.

What do you think about it ?

[MattIPv4]

That sounds like a logical approach, though I don't have a setup with which I can test the serial controller. So, I am reliant on community contributors like yourself to validate that a change to a controller works as expected, and then open a pull request with it (I also don't really maintain this library generally anymore, as I no longer have a setup to use it with).

[ThierryMGTX]

Oops ! I made a mistake in my code : I should have put 1 as constructor parameter for bytearray(), which is the length. Or [0], not 0... which explained the weird unexplained behaviour regarding flush().
Therefore, the correct code (with flush() at the explainable expected places) is :

        self.__device.baudrate = 80000
        self.__device.write(bytearray(1))
        self.__device.flush()
        self.__device.baudrate = 250000
        self.__device.write(data)
        self.__device.flush()

(being not so familiar with GIT version control system, I'll deal with the pull request a bit later)