A better way to drive LED panels in Christmas displays

Re: Where do we go next?

darylc said:
I suspect it is possible to drive multiple matricies from the same FPP/LINSN sender card provided the panels are all the same model. I hope in 2017 to explore this further
Click to expand...
Yes this is certainly possible. And they can be any variety of panel types. One panel type per receiver card. the sending card sends out the video for the whole display. each receiver card is responsible for grabbing it's section of the picture and formatting it properly for the panels connected to it.

I just got sent over to this thread from a related thread over on DIYchristmas.org. While I have little personal interest in video matrices in Christmas displays, I'm interested in watching how others use them so we can adjust the software side of the workflow accordingly.
 
A better way to drive panels in Christmas display

jchuchla said:
darylc said:
I suspect it is possible to drive multiple matricies from the same FPP/LINSN sender card provided the panels are all the same model. I hope in 2017 to explore this further
Click to expand...
Yes this is certainly possible. And they can be any variety of panel types. One panel type per receiver card. the sending card sends out the video for the whole display. each receiver card is responsible for grabbing it's section of the picture and formatting it properly for the panels connected to it.
Click to expand...

Thanks for the tip. I've done a heap of testing and you are indeed correct :)

I now have a single LINSN sender card driving 2 sets of panels, FPP will need a bunch more hacks but Keith's new xLights scheduler would drive this perfectly based on what he's shown me.

Looks like I could drive many more panel matrix's than I'll ever want in my show off of a single PI & LINSN sender card. Just need a separate LINSN receiver card for each matrix - and these are the cheap bit US$15 each.

The more I look at this, the more I'm convinced that this is the future of driving panels. The only way to do better than this is to drive the receiver cards LINSN RV908's (or some other vendors equivalent). Technically it's possible because they use Ethernet, but realistically since it's a proprietary protocol and not even IP packets I doubt we'll get that far down the path.
 
Re: A better way to drive panels in Christmas display

darylc said:
The more I look at this, the more I'm convinced that this is the future of driving panels. The only way to do better than this is to drive the receiver cards LINSN RV908's (or some other vendors equivalent). Technically it's possible because they use Ethernet, but realistically since it's a proprietary protocol and not even IP packets I doubt we'll get that far down the path.
Click to expand...

And so CaptainMurdoch has now implemented something similar with a another brand of receiver board:

http://falconchristmas.com/forum/index.php/topic,6871.0.html

It won't work well from a PI because it makes less efficient use of the PI's ethernet port than E1.31 and the PI is already limited in terms of it's ethernet bandwidth.

Time will tell if this way of driving the panels will become as flexible as the LINSN hdmi method (due to the vast range of settings/panels types that Led Studio can configure into the LINSN cards)
 
I don't know if I'd say this is the future of driving panels. It's the long established standard. I've been using these cards (and their previous generation predecessors) for over 10 years now. The "new" thing is that they're finally at a price point where DIY folks can start playing with them.
There's a lot of power and flexibility with this system, and it's proven technology that's been in use for many years in outdoor installations all over the world. My one complaint has always been the LED Studio software. It's probably just because it's poorly localized. I'd imagine it makes more sense in it's native language to an Asian engineer's mind. But it's always been hard for me to remember the steps needed to do each task, and specifically what some of the settings field labels actually mean. Some of the translations just don't make sense in English. So it can be daunting for someone to set up the cards and get them working with the panels they have on hand.
 
jchuchla said:
I don't know if I'd say this is the future of driving panels.
Click to expand...

Compared to driving them with a BBB, I sure think it's the future for the Christmas Community. Sure Led Studio stinks, but with some documentation and tutorials it will serve us well I suspect.
 
With the new (beta) FPP channel output for the colorlight card, you only need to use the vendor software to setup the receiver and FPP just sends it the pixel data using the proprietary Ethernet frames. If I could get a short packet capture of network data sent to a Linsn card i could take a look sometime see if we might be able to support those directly as well.

I have some sample code from adafruit to capture image data from the Pi's video framebuffer so I will add support for that as well so FPP could use omxplayer to play a video using hardware video decoding and FPP could capture the data and send it out to a colorlight card directly or display on any matrix.

I think the Pi could be fine to drive a single colorlight card for most users even with the Pi USB Ethernet. "iperf" is able to shove over 100k UDP packets per second out a Pi v3 Ethernet interface so that would easily support the full 256x256 pixel resolution supported by a single colorlight 5a-75. FPP can shove 256 E1.31 universe packets out the Pi v2 or v3 in 15ms, so smaller display sizes will take even less. Comparing to a BBB, if the BBB supports 64 panels in a theoretical 8x8 config, that would only be 96 universes or around 6-7ms at most to send over Ethernet to a colorlight. Seems like pretty acceptable performance to me.
 
I think the colourlight code you've written will be great for the average user wanting to run a tune to sign or small matrix instead of using a BBB and be much much simpler for them.

I'm not fussed on LINSN/Colourlight cards, I'll probably order some Colourlights for testing - hopefully it's configuration software is much simpler.

Yesterday I wrote some FPP code to display multiple virtual matrix's on the HDMI port specifying the location of each one. I haven't yet had time to plug that into my linsn sender card and check the results. There is this pesky issue of finishing the tear down from the 2016 show.

In any case I like the direction we're heading :)
 
I was in chat with Daryl. One of the questions I asked, what panels are compatible with the Linsnled or/and Colorlight receivers. After speaking with Daryl (Thank You) and doing some reading it appears that most panels support the HUB75 outputs.


I have come across this site http://www.ledcontrolcard.com/ from Linsnled, they seem to sell all cards and panels. Of course there is Ray and other suppliers on Alliexpress.


I am going to order some different brands of test cards and panels. CaptainMurdoch, perhaps i could assist and do some beta testing of your new code.
 
The ColorLight software seems similar to screenshots of the Linsn software that I have seen. It was pretty easy to get working even with no prior experience.

Multiple virtual matrices sounds really nice, I will look forward to when we can merge your patches.. I used some new undocumented FPP code to give myself the same ability this year for my display. 3 matrices all connected to a single BBB. I could sequence them individually and run effect sequences on individual matrices.

I think the HDMI output is definitely the better way to go for high panel counts. I wrote some code this weekend to work with a HDMI/DVI to E1.31 adapter that Ron at Ron's Holiday Lights created. The board currently has a 100Mbit NIC but he is going to look into adding Gig-E capability. He also asked about the specs for the ColorLight packets so he could look at a firmware that could send those. We might end up with a cheap DIY sender board that could send to the ColorLight and maybe Linsn receiver boards. I found a packet capture from a Linsn card and their web page says they can also be driven over Ethernet directly from a PC. We have another FPP user with a set of Linsn cards who is going to get me some packet captures and I will take a look at supporting those receivers as well in FPP.

I should have the current code in the master branch in a week or so. It is currently only in my local checkout and is mixed in with some other stuff I have been working on for v2.0. I need to get everything committed and merged from my branch to the master branch and then I will probably back port the code to master-v1.x so others can test without having to run the master branch which will get broken shortly as we start focusing more on v2.0.
 
I would love to have CaptainMurdoch reply, but the last I heard he is on hiatus.
Hopefully he will rejoin all of us, and soon. He is missed!
 
I have the color light receiver board and the Linsn board. I have made the color light receive data from FPP directly but only in the test sequence mode. AND the code is in the non released branch. Also, the playlist code is broken in the non release branch. It is looking good, but agreed, Captain holds the secret sauce!
 
I noticed that the modified fbmatrix.cpp file is no longer on Dropbox. I am interested in driving a large matrix with a sending card but I am not sure on the modifications to this file. Would you mind re-posting it please?
 
You must log in or register to reply here.
Back
Top