Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#60 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
python
Ambito
embedded-iot

Direzione di ricerca

Inizia leggendo il metodo SerialController._transmit() e confronta la sequenza send_break attuale con la sequenza proposta di baud rate e byte nullo. Riproduci il test seriale grezzo, quindi valida il comportamento del controller sulle piattaforme disponibili; il lavoro è completato quando l’aggiornamento DMX è migliorato senza i problemi di svuotamento o riconfigurazione descritti.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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 ?

Lingua principale
Python
Stelle
143
Fork
23
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di MattIPv4/PyDMXControl

Tutte le issue di MattIPv4/PyDMXControl

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.