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

macOS extremely slow refresh rate when using a serial-based controller due to break time

Abierto
#58 0 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
30/100
Tipo de issue
Error
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
python
Área
embedded-iot, operating-systems

Línea de trabajo

Comienza en PyDMXControl/controllers/_SerialController.py, en el bucle Ticker y la llamada send_break de PySerial. Investiga el comportamiento del break-time en macOS y el workaround documentado de break_condition; el trabajo estará terminado cuando se consiga una refresh rate más rápida sin incumplir los requisitos de timing de DMX.

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

Descripción

This is more of an FYI for anyone else that tries to use this on macOS than an issue I expect fixed, but I'll document it here in case anyone wants to implement a more elegant solution.

When running PyDMXControl on macOS, the refresh rate for packets sent out is capped around ~2Hz due to the underlying implementation of sending a break in PySerial. A user in this thread helpful did some digging into the tcsendbreak function and found that it's hardcoded to 400ms on macOS, no matter what duration is passed in: link.

That means that the Ticker loop in this module blocks on the the call to PySerial's send_break function for 400ms and cannot spin any faster than that. My current workaround is to comment out the send_break and sleep calls here and instead replace it with:

self.__device.break_condition = True
sleep(5e-6)
self.__device.break_condition = False
sleep(1e-6)

Those sleep times are actually way shorter than what is supported by the DMX standard (min 88uS and 10uS respectively I think), but since the python sleep module isn't really accurate below 1ms, the actual break and MAB measured with a logic analyser ended up around 200uS and 300uS respectively. That will probably vary greatly depending on the system, but thankfully the DMX spec only mandates minimum lengths for both, and most DMX devices will do just find with longer breaks/MABs.

I don't know enough python to know if there are more reliable ways to do timing on a microsecond level, but this hack works well enough for the basic bringup I need to do with this module.

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.