Author Topic: FPP driving P10 panels over Ethernet via a $30 ColorLight 5a-75B receiver board  (Read 8405 times)

Offline CaptainMurdoch

  • Administrator
  • *****
  • Join Date: Sep 2013
  • Location: Washington
  • Posts: 7,854
  • Kudos: 139
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.
-
Chris

Offline nosilent

  • Newbie
  • *
  • Join Date: Feb 2017
  • Location:
  • Posts: 2
  • Kudos: 0
My tests or investigations resulted until now with this:

It seems the ethernet frames are having a 0x2d bytes long header. It is only set in the first ethernet frame.
The two bytes at 0x0e (LSB) 0x0f (MSB) are a consecutive ethernet frame number.
The actual frame is inside several ethernet frames (starting with 0, 0).
The frame lines (or after some pixels) are separated with a (repeating) 0x00 byte offset. This depends on the header.
The header data is only filled in the ethernet frame number zero. After the frame header pixel data may appear.
Pixels are encoded BGR (might be wrong), each 1 byte blue, 1 byte green, 1 byte red, after each other.
The header of the first frame also defines the size (as you already also discovered).
For me it looks like that some bytes in it (at 0x and at 0x) select one resolution out of many (perhaps related to the selectable resolutions of the LINSN sender card, which has DVI and a configurable resolution). It seems that the bytes are not directly encoding the resolution.
0x10 in the frame header at position 0x20 means enable LED error open detection reporting (or some other "enhanced" LED driver funcitionality).
At 0x1b in frame header: select resolution
At 0x2d in frame header: select resolution or checksum maybe?
The four f's are not for brightness directly I guess (maybe select another function?, like brightness sensor or so).
Global brightness, White balance, Gamma curve selection are in the header at position 0x21 to 0x26 and are sent only one time (only one frame). New frames do not include the brightness (etc.) settings, the card "saves" it until it is powered off/on.

How do you detect the different sizes of the frames? I selected the area to send to a specific receiver in the LINSN software at the "Display connection" tab of the "Setup hardware parameters" window and entered different/usual screen resolutions in the Width/Height fields, then Send to receiver to test. By increasing or decreasing the number only a few pixels nothing changed, therefore I also assume that there might be predefined resolution, which can be chosen.

Destination address was (not always): 00:00:00:00:00:00 (sometimes 00:..:fe, do not relate to screen resolution)
Source normal ethernet adapter address
Length: always 1486 byte, Protocol: always 0xaa55

There are also sometimes frames form the receiver card (I guess to report, hey I'm ok, no error here), they are longer (1496 bytes, protocol 0xaa56) and had always the same content (914f0000000000000000000000feff00...). Seems to be ignoring it is ok.

Moreover the configuration about panels (ICs, size, arrangement, etc.) is all stored at the receiver card (including the receiver size and position). If more cards are used then their position must be set (and there resolution) in the "Display connection"  setup. After this a receiver card can put freely in the ethernet chain, they will display their intended content area. So it is also possible to display the same content on many receiver cards, simply by programming the same positions into them.
« Last Edit: March 06, 2017, 01:33:07 PM by nosilent »

Offline neilric99

  • Supporting Member
  • ******
  • Join Date: Aug 2013
  • Location:
  • Posts: 190
  • Kudos: 1
Has there been any progress on driving these boards from the FPP? Looking forward to going this route for the P10 panels this year.

Offline JonB256

  • Supporting Member
  • ******
  • Join Date: Mar 2013
  • Location: Granbury, Texas
  • Posts: 3,559
  • Kudos: 74
    • Granbury Christmas Lights
Has there been any progress on driving these boards from the FPP? Looking forward to going this route for the P10 panels this year.
The thread about FPP 2.0 lists these as an addition.

Offline CaptainMurdoch

  • Administrator
  • *****
  • Join Date: Sep 2013
  • Location: Washington
  • Posts: 7,854
  • Kudos: 139
Has there been any progress on driving these boards from the FPP? Looking forward to going this route for the P10 panels this year.
The thread about FPP 2.0 lists these as an addition.

I have new FPP Channel Output code for driving both ColorLight and Linsn receiver boards, but I need to spend a bit more time working on the Linsn code.  The Linsn card only listens to the MAC address of the NIC that was used to configure the card, so when I configure the card on a Windows computer and move the receiver to the Pi, I have to fake the Windows MAC address in FPP code.  I don't want users to have to do that, so I am doing more testing to see if I can work around that somehow or if I can figure out how to configure the card from Linux.  One other possibility is that there might be some form of broadcast that I can use which will allow the receiver card to listen to any MAC address, but I haven't found that yet.  There is no documentation available on the proprietary protocol used to talk to the receiver cards, so everything I have working so far has been based on reverse engineering network packet captures.

Offline arw01

  • Hero Member
  • *****
  • Join Date: Oct 2013
  • Location:
  • Posts: 821
  • Kudos: 0
Would that mean that the Colorlight would be the preferred card to use over the Linsin?


If one card is sucking up more time for you, then why not drop it and just use the one.  It was not like they were significantly more money for one vs the other, or was the configuration on the windows side the reason you sought out the Linsin?

Online Bshaver

  • Developer
  • ******
  • Join Date: Aug 2014
  • Location: Denver, CO
  • Posts: 1,230
  • Kudos: 20
I have both the LINSN and Colorlight card. With proper instruction I can do a setup and test both for you :)

Offline Unibits

  • Falcon Beta Team
  • **
  • Join Date: Apr 2013
  • Location:
  • Posts: 71
  • Kudos: 3
I now have both the LINSN and Colorlight cards here too.  (too a while to get them) 

I too could help you test any config you think needs help with additional testing

Offline arw01

  • Hero Member
  • *****
  • Join Date: Oct 2013
  • Location:
  • Posts: 821
  • Kudos: 0
Ordered up a Colorlight card.  Does it come with the software or does one have to go find it on the web?

Online Bshaver

  • Developer
  • ******
  • Join Date: Aug 2014
  • Location: Denver, CO
  • Posts: 1,230
  • Kudos: 20
Yes, you download the software from the interweb. I dont have the links handy with me and i am not home for another 7 days. In Vegas for a convention.

Offline JonB256

  • Supporting Member
  • ******
  • Join Date: Mar 2013
  • Location: Granbury, Texas
  • Posts: 3,559
  • Kudos: 74
    • Granbury Christmas Lights
Also ordered and waiting (colorlight) now staring at them.
Waiting on Trendnet USB/Gigabit dongles now. Always something.


« Last Edit: May 04, 2017, 01:36:49 PM by JonB256 »

Offline JonB256

  • Supporting Member
  • ******
  • Join Date: Mar 2013
  • Location: Granbury, Texas
  • Posts: 3,559
  • Kudos: 74
    • Granbury Christmas Lights
Patiently. Not

Offline neilric99

  • Supporting Member
  • ******
  • Join Date: Aug 2013
  • Location:
  • Posts: 190
  • Kudos: 1
free shipping is only good if you are prepared to wait forever

Offline darylc

  • Supporting Member
  • ******
  • Join Date: Oct 2013
  • Location: Australia
  • Posts: 111
  • Kudos: 3
Has there been any progress on driving these boards from the FPP? Looking forward to going this route for the P10 panels this year.
The thread about FPP 2.0 lists these as an addition.

I have new FPP Channel Output code for driving both ColorLight and Linsn receiver boards, but I need to spend a bit more time working on the Linsn code.  The Linsn card only listens to the MAC address of the NIC that was used to configure the card, so when I configure the card on a Windows computer and move the receiver to the Pi, I have to fake the Windows MAC address in FPP code.  I don't want users to have to do that, so I am doing more testing to see if I can work around that somehow or if I can figure out how to configure the card from Linux.  One other possibility is that there might be some form of broadcast that I can use which will allow the receiver card to listen to any MAC address, but I haven't found that yet.  There is no documentation available on the proprietary protocol used to talk to the receiver cards, so everything I have working so far has been based on reverse engineering network packet captures.

Hi Chris,

Had a go at making this work on my Linsn RV908 tonight.  A couple of suggestions for the Setup-Linsn_RV908.txt

1. Need to add the sourceMAC to channeloutputs.json eg
                        "sourceMAC": "50:7b:9d:55:84:3d",
2. Change subType rather than type to "LinsnRV9"

Trying with 1 single panel.  Works OK showing what is on the PC, but once I put fpp into test mode, I am finding that whilst packets are going out eth1 ok to the receiver, the panel just displays the last thing it received from the PC once plugged into eth1.

Any hints on what to look for next?

Daryl

Offline CaptainMurdoch

  • Administrator
  • *****
  • Join Date: Sep 2013
  • Location: Washington
  • Posts: 7,854
  • Kudos: 139
Had a go at making this work on my Linsn RV908 tonight.  A couple of suggestions for the Setup-Linsn_RV908.txt

1. Need to add the sourceMAC to channeloutputs.json eg
                        "sourceMAC": "50:7b:9d:55:84:3d",
2. Change subType rather than type to "LinsnRV9"

Trying with 1 single panel.  Works OK showing what is on the PC, but once I put fpp into test mode, I am finding that whilst packets are going out eth1 ok to the receiver, the panel just displays the last thing it received from the PC once plugged into eth1.

Normally the "last image" issue has been related to something wrong in the data going to the card, it's like it just gets confused and shows the last frame of data it received.

I just re-tested the code in master with my 4-panel layout and it is working fine.  Is the MAC you specified the MAC of the interface on the windows machine that was used to configure the receiver card initially?  This is the issue I'm trying to work around now. the reciever card only wants to listen to the MAC that was originally used to configure it.  I need to see if there is some form of broadcast MAC that can be used.  I believe this might be possible since the cards can work with two different sender cards in a failover situation.

I corrected the subType reference in the setup file.

 

Back to top