Jump to content


Photo

Maxim S - Usb Capture Protocol Bug

usb capture citp

  • Please log in to reply
3 replies to this topic

#1 mbit

mbit

    Newbie

  • Members
  • Pip
  • 2 posts
  • Gender:Male
  • Location:Germany

Posted 21 June 2017 - 01:07 PM

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.

Hello,
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.

Best regards,
Martin

Attached Files


  • 0

#2 LSC TechSupport

LSC TechSupport

    Guru

  • Admin
  • PipPipPipPipPip
  • 2,270 posts
  • Gender:Male
  • Location:Melbourne, Australia
  • Interests:My wife and two daughters, Water skiing, Sleeping :-)

Posted 12 July 2017 - 09:33 PM

Wow, that is some detailed fault finding :-)

 

The CITP protocol we are using is a 'custom' hybrid implementation that was developed between Capture and LSC. It was developed to allow us to sell a special LSC Capture version of their software with the maXim consoles. I suspect that this is the 'strange' large packet that you are seeing, as if the console is fitted with a dongle then the message will indeed be encrypted with a challenge/response unlock code that Capture replied to.

 

However this was developed in 2009 and then abandoned by 2011 due to very slow sales. I expect that the protocol has long since been disabled in the Capture product, which might explain why it now glitches. I used to use it with all the maXim consoles and never saw a problem, but have not tried again since early 2012.

 

For us to fix it would be a fair bit of work, and we no longer are actively developing the maXim line, so the software has not been touched for many years.


  • 0
Regards
Richie Mickan
TechSupport
LSC Lighting Systems
LSC Web Site
Email me

#3 mbit

mbit

    Newbie

  • Members
  • Pip
  • 2 posts
  • Gender:Male
  • Location:Germany

Posted 13 July 2017 - 11:06 AM

Hello Richie,

 

thanks for your response.

 

Please note that the PInf/PNam message also has a wrong size value in its header, leading to one dropped DMX message, so it shouldn't be a leftover from the encryption dysfunctionality.

To me it rather looks like the Maxim has some problems with sending strings over the protocol, specifically with determining the string length for the message size, since these two faulty message types are the only ones that transmit strings ("LSC maXim Console" in the PInf/PNam message, "LSC NC" in the SDMX/EnId message).

 

I tried the (locked, non saving) special LSC Capture version, it stops for a second on the faulty messages, just like Capture Polar.

 

However, in the meantime, I went with solution 2, and developed a small program that translates the Maxim's CITP into Art-Net while correcting the wrong message sizes on the fly.

It works well with all versions of Capture that we tested (Polar, Atlas, Argo, Nexum).

 

Let me know if I am allowed to post that program here, for others who might have the same problem with their console.

 

Best regards,

Martin


  • 0

#4 LSC TechSupport

LSC TechSupport

    Guru

  • Admin
  • PipPipPipPipPip
  • 2,270 posts
  • Gender:Male
  • Location:Melbourne, Australia
  • Interests:My wife and two daughters, Water skiing, Sleeping :-)

Posted 17 July 2017 - 07:04 AM

Hi Martin,

 

Of course you can post it here.

 

If you send me a copy we can post it on the website for all users.


  • 0
Regards
Richie Mickan
TechSupport
LSC Lighting Systems
LSC Web Site
Email me



Also tagged with one or more of these keywords: usb, capture, citp

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users