You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am seeing an issue where dmx_read will occasionally return more than 513 bytes. This is an issue because it's basically a partial packet at the front, then the next full 513 byte packet starting somewhere in the middle, which causes me to write zeroes to the DMX output and flickers the fixture.
Below is an example log where I have DMX input at ~40Hz. I see occasional errors which isn't great, but it's not the end of the world as I just drop those packets. I am blocking to wait on incoming packets with: size_t num_bytes_rxd = dmx_receive_num(INPUT_DMX_NUM, &rx_metadata, 513, portMAX_DELAY);
If there is an error I don't call dmx_read and just loop back around to the blocking receive function. If there is a length less than 513 I log it, but I still handle the bytes to support non-full-length packets. There is a weird case where often dmx_receive_num will unblock with no error, but the size field of the metadata will be set to zero. I also skip the call to dmx_read in this case.
What's causing the issue is that occasionally, after receiving either an error or a zero length packet, the next call to dmx_recieve_num will return more than the 513 bytes that I pass in as an arg. My call to dmx_read guards against an overflow by not reading out more than the 513 buffer size, but as I said in the beginning it's a problem because the 513 bytes I do read out is partially some previous packet, and then partially the new packet.
I can add a guard that basically drops all packets received > 513, but that's throwing away a valid incoming packet which I'd prefer not to do.
(I'm only logging the first 6 bytes of the DMX packet if they don't match my expected test incoming packet, which starts with 0x00, 0xFF, 0xFF. That's why those are the only ones logged out)
Here is roughly the code I'm using. I've taken some parts out that aren't relevant:
I am seeing an issue where
dmx_read
will occasionally return more than 513 bytes. This is an issue because it's basically a partial packet at the front, then the next full 513 byte packet starting somewhere in the middle, which causes me to write zeroes to the DMX output and flickers the fixture.Below is an example log where I have DMX input at ~40Hz. I see occasional errors which isn't great, but it's not the end of the world as I just drop those packets. I am blocking to wait on incoming packets with:
size_t num_bytes_rxd = dmx_receive_num(INPUT_DMX_NUM, &rx_metadata, 513, portMAX_DELAY);
If there is an error I don't call
dmx_read
and just loop back around to the blocking receive function. If there is a length less than 513 I log it, but I still handle the bytes to support non-full-length packets. There is a weird case where oftendmx_receive_num
will unblock with no error, but thesize
field of the metadata will be set to zero. I also skip the call todmx_read
in this case.What's causing the issue is that occasionally, after receiving either an error or a zero length packet, the next call to
dmx_recieve_num
will return more than the 513 bytes that I pass in as an arg. My call todmx_read
guards against an overflow by not reading out more than the 513 buffer size, but as I said in the beginning it's a problem because the 513 bytes I do read out is partially some previous packet, and then partially the new packet.I can add a guard that basically drops all packets received > 513, but that's throwing away a valid incoming packet which I'd prefer not to do.
(I'm only logging the first 6 bytes of the DMX packet if they don't match my expected test incoming packet, which starts with
0x00, 0xFF, 0xFF
. That's why those are the only ones logged out)Here is roughly the code I'm using. I've taken some parts out that aren't relevant:
The text was updated successfully, but these errors were encountered: