Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
#60 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
python
Área
embedded-iot

Línea de trabajo

Comienza leyendo el método SerialController._transmit() y compara su secuencia send_break actual con la secuencia propuesta de velocidad en baudios y byte nulo. Reproduce la prueba serie sin procesar y, después, valida el comportamiento del controlador en las plataformas disponibles; se considera terminado cuando se haya mejorado la actualización de DMX sin los problemas de vaciado ni de reconfiguración descritos.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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 ?

Lenguaje dominante
Python
Estrellas
143
Forks
23
Sin PR fusionados en 30 d

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de MattIPv4/PyDMXControl

Todos los issues de MattIPv4/PyDMXControl

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.