Build: 2023.12120
OS: macOS
When using the typical ENTTEC DMX USB Pro (mkI) black box, if the incoming DMX universe doesn’t supply a full 512 byte DMX universe, the ENTTEC packet stop byte (0xE7 or 231 decimal) is shown in the DMX In CHOP.
See attached photo of a simple 12-channel mixer sending only 13 DMX slots, the start byte + 12 data slots. You can see the stop byte in channel 50 (12 channel mixer is sending a 50 byte DMX universe, 1 start code + 49 slots).
Here is a link to the Pro API: https://cdn.enttec.com/pdf/assets/70304/70304_DMX_USB_PRO_API.pdf.
I would expect TD to be properly reading the DMX data length fields and not displaying this packet stop byte to the user. If whatever DMX device is connected is sending a full 512-byte universe, I’m assuming this isn’t a problem, since this stop byte would be out of the 513-byte chop table.
Maybe this logic is already implemented in TD, but maybe a mistake was made by not including the DMX ‘error’ byte in the data length calculation? The data_len field in DMX input packets is one larger than the actual DMX data sent back, because it also is prefixed by a byte that enttec can put error codes into.
