ESP32 DMX Libary packet size read problem

[nnovation]

esp dmx library very help full for me but i noted one issue please solve this is issues - issues when read dmx so packet size read but when run greater then more packet after run less packet size value of packet size before data tranfered packet size. for more understand give example - when i run 200 channel packet size so read 200 but after run more then 200 like a 250 but read packet size 200 if i send data less then 200 like 150 then read packet size so read 150 but after then mote then 150 but in actual shw 150 packet size. so not increass but decrease packet size. if i reset esp32 then ok to read more packet size.

Thanks you

[someweisguy]

Thanks for the question. Which version of this library are you using and what version of ESP32 are you using?

[nnovation]

Thanks you for reply

I used latest version 4.1.0 esp_dmx library and I used ESP32 Devkit module and esp32 board version 2.0.17.

[2345lug]

Hello! I have a same problem with latest version.

[nnovation]

Hello someweisguy. This is library for me very usefull. Please solve this issue.

[putzlicht]

Still unsolved. Time to take a look on the math?

A first workaround for me is just always reading 513 bytes, no matter what packet.size tells me...

And it seems to be the right way. A closer look at the examples shows two different statements for the bytes to be read:

1. Arduino_DMXRead.ino: dmx_read(dmxPort, data, packet.size);
2. ESPIDF_DMXRead.c: dmx_read(dmx_num, data, DMX_PACKET_SIZE);

I guess that both examples should produce the same result, but the Arduino example could simply be wrong. The DMX standard specifies 513 bytes in a frame. Therefore the ESPIDF example should be the reference if it works. And it does for me. The fact that the packet.size adapts to the last number of slots received now looks more like a feature to me than a bug. However, I don't know how to use it yet :-/

After reading some of the really great documentation, here's the important part: "The function dmx_receive() can be viewed as a wrapper for dmx_receive_num() where the number of slots to receive is equal to the packet size of the last DMX packet received. When the desired number of slots to receive is greater than the actual number of slots received (e.g. when waiting to receive 512 slots, but only 128 are received) the function will unblock upon receiving the DMX break for the subsequent packet and the packet.err will be set to DMX_ERR_NOT_ENOUGH_SLOTS."

If, for example, only 120 slots are sent by the transmitter and a break is received, dmx_receive() only expects 120 slots in the next frame. dmx_receive_num(), on the other hand, waits until the number of slots given has been received. dmx_receive_num() takes a little more CPU time, but that's okay. However, dmx_receive() cannot distinguish between fewer slots sent intentionally and too few slots due to a hardware problem. I managed to reduce the slots to 1 within a short time using targeted loose contact. That makes this feature unusable for me, even if it's supposed to be nice. But in principle, the way is to always read 513 bytes or using dmx_receive_num(), if I understand correctly.

[maxroseGIT]

Hi @putzlicht,

interesting insight and thanky for the interpretation of the documentation of esp_dmx.

Do you think that your findings play a role when using esp_dmx with professional DMX gear like Wolfmix W1?

I have some trouble getting all channels read on my ESP32 when it receives data from the Wolfmix DMX controller. I wonder if this controller sends different packet sizes to obtains its claimed performance? Which then in turn gives me the troubles to read the packets correctly.