Closed jlohmoeller closed 8 months ago
Thanks for reaching out and thanks for your patience while I got back to you!
I haven't heard any reports from users about blackouts while sending DMX. I'm mildly surprised to hear about issues with DMX sending in particular because the DMX send logic is much simpler than the DMX receive logic in the codebase for the library. The bug reports I get are from people who found my mistakes in my DMX receive code.
A few things pop in my mind to check. I apologize in advance if you're already tried any of this - just trying to be thorough! :)
What happens to your PARs when you set them to full and disconnect the DMX cable? In my experience, lights generally hold the last DMX value they received for a few seconds but I am not familiar with these particular PARs. If they do indeed hold the last DMX value they received, I am wondering if somehow the DMX code is sending a blackout for a few seconds.
What is the return value of dmx_send()
during the blackouts? If no DMX data was being sent, dmx_send()
should return 0.
Let me know your thoughts and if you have any questions!
EDIT: As soon as I wrote the above text, I noticed a potential issue with the DMX send task:
void IRAM_ATTR dmx_loop(){
while (true) {
if(!recvDMXA && !recvDMXB){
vTaskDelay(1000);
continue;
}
if(recvDMXA)
dmx_send(dmx_a_num, DMX_PACKET_SIZE);
if(recvDMXB)
dmx_send(dmx_b_num, DMX_PACKET_SIZE);
}
}
Do I understand correctly that if ArtNet is not received on neither universe A nor B, that the task will delay for 10 seconds (1 tick == 10ms, 1000 ticks * 10ms == 10000ms)? If so, this would be an issue. DMX needs to be constantly sending packets in order to function correctly.
Try this DMX send loop; feel free to make any edits you would like:
void IRAM_ATTR dmx_loop(){
dmx_wait_sent(dmx_a_num, portMAX_DELAY); // Wait forever, until DMX A is done sending
dmx_send(dmx_a_num, DMX_PACKET_SIZE);
dmx_wait_sent(dmx_b_num, portMAX_DELAY); // Wait forever, until DMX B is done sending
dmx_send(dmx_b_num, DMX_PACKET_SIZE);
}
}
This loop will block while DMX is sending. It will unblock when DMX is finished sending and then send DMX A. This way you will have a constant stream of packets being sent out. I suspect that using a separate task to send each DMX universe may be more efficient but I haven't tested this use-case.
Let me know your thoughts!
I've built an ArtNet to DMX converter based on this library. At first, it seemed to work quite well, but I'm noticing short random breaks in the DMX output every few minutes (every 30s to 5m at random). Has anyone experienced a similar issue so far?
I've tested with a Showtec Compact Par 7 Q4 and Futurelight SlimPar 18. Both turn dark for a few seconds during the "breaks".
I've experimented with setting various DMX break times (from 176 to 10000), switching UARTs (currently using 1 and 2), and disabling the second universe, none of these removes or reduces the random breaks. The ESP32 (OLIMEX ESP32-POE module) runs ESP-IDF with two user tasks (dmx send and artnet receive). Network is Ethernet, WiFi was left uninitialized.
DMX logic
part of ArtNet logic that sets actual DMX data (called from separate task that loops over incoming packets)