I'm also that guy, that you probably found at the german board (including the capture): http://www.mikrocontroller.net/topic/352894
In the past i tried to get it somehow working and somehow succeded, in a very limited way that I can control some pixels, but the protocol as you already noticed understands different formats (or so).
I have also contacted Linsn directly regarding informations, but I got only interesting data for the USB serial connection to a sender card, which is in this case not that interesting (the sender to receiver card work in another way, they did not use normal ethernet framing, only the PHY for physical making 8b10b and so on are used).
I saw your posts on the german board, thanks for helping get the ball rolling on this. I emailed Linsn as well but never heard anything back.
I have been able to determine at least 4 different image sizes sent in 8bpp mode. So far, these seem to be just different buffer sizes:
0xd2 = 512x256 image in 274 packets per frame
0xc2 = 1024x512 image in 1094 packets per frame
0xe0 = ??x?? image in 4 packets per frame
0xe1 = ??x?? image in 2 packets per frame
I have seen all of these used at various times when only one 32x16 panel was configured. My test code currently sends 0xd2 with 512 pixel wide images but only sends the number of lines necessary for the rows configured. I want to figure out the 0xe0 and 0xe1 codes, but haven't seen them in a packet capture lately. Once I connect more panels I should be able to reverse engineer those by just turning on certain channels and seeing which pixels light up.
I haven't had much testing or coding time in the past week so I'm not much further along other than examining existing packet captures. Now that I have the ColorLight card working on my 14-panel matrix I will probably swap in the Linsn card as soon as one of the newer models arrives. If that works fine I will post model number and links to the models I know will be supported by FPP. I'm also trying to document the packet formats in the header of the source code. It wouldn't surprise me if we saw direct support for these implemented in xLights and/or Vixen 3 if we can get the protocols documented well enough.
(I'm also interested in the dimm/brightness function, which seems to be in the header of the first packet), then I can maybe help.
Thanks. I noticed the four 0xff in the header but didn't know what they were. As a test, I changed those all to 0x7f and the brightness was reduced. I tried 0x3f and it was further reduced. Other values didn't work, the display went dark. That is a good piece of useful information though and will help.