TL;DR: Maxim S encodes wrong CITP message size into SDMX/EnId and PINF/PNam messages, causing visualizers to freeze for a second, every 4.5 seconds.
we have recently started to plan some lighting setups with our Maxim S connected through USB to Capture Polar.
The console runs software version 3.20. The USB/Midi and VGA modules, along with 2048K of RAM were installed a few years ago.
It works so far, however, every ~4.5 seconds the USB-DMX connection freezes for about 1 second.
This gets annoying for rapid fades or chases, since any smooth animation comes to an abrupt halt every 4.5 seconds.
After some research, I found this:
- The Maxim S is connected to the PC via a USB Serial Converter, providing a virtual Serial (COM) Port to the PC.
- However, this Converter also allows direct communication with its driver, without having to go through the virtual COM Port.
- Capture Polar loads ftd2xx.dll (part of the driver) and uses that to communicate directly with the device
- The Maxim console speaks the CITP protocol over this serial connection.
Then I looked up the CITP specification and wrote a small C program, which reads the data stream from the virtual COM port.
Using the COM Port seemed a little easier to me than using the dll method. The program splits all incoming data into CITP messages and displays some information about them, including the Message size and type, in real time.
Looking at the incoming list of about 19 messages per second, I immediatly noticed that there is a 1-second break every 4.5 seconds (every 87 messages). The message immediately after the break was 8192 bytes in size, while all other messages are only 542 bytes. The message type was SMDX/EnId, which according to the spec, contains proprietary DMX data encryption information.
Of course these huge messages were the cause of the freezes in Capture Polar, I thought. Over the 9600 baud serial port these messages would surely require almost a second to transmit, prohibiting any DMX data transfer in that timespan.
I dumped the contents of such a message and found a surprise: It contained not only the encryption information, which stated that no encryption is used, but after that came some more standard DMX data messages, those that Capture polar and my program were apparently missing, during the freeze.
How come this? In the CITP message header the size was clearly given as 8192 bytes, but this was clearly wrong, since the Encryption info message looked like it was only 31 bytes long.
Any program that parses the CITP data stream correctly, such as Capture Polar and, to some extent, my program, thus wrongly splits the message stream and 'loses' the following 16 DMX data messages, which are wrongly accounted to the SDMX/EnId message, causing a freeze in DMX updates.
I found a similar issue in the PINF/PNam messages, which are regularily sent to inform the visualizer of the console's name. This message devours one DMX data update, which apparently was never visually noticeable to me.
Now thinking of possible solutions:
- LSC fix this bug in the firmware (my favourite solution!).
- Write a proxy that works around this problem, receives and splits the corrupt messages correctly, and send them on to Capture in some other supported network protocol.
- Write a DLL injection for Capture that fixes the data when read using ftd2xx.dll.
Some more thoughts:
- Does this bug affect all Maxim S or just ours?
- I would find it strange if the bug were to be present on all Maxim USB modules, surely someone would have reported this?
- Can it be patched in the firmware, or does the USB module run its own, non-replacable bit of firmware?
The attachment contains a captured, raw data stream from the virtual COM port.
Please ask if you need more information to investigate this issue.