Author Topic: Max P5 Matrix size  (Read 514 times)

Online Cjaqua

  • Jr. Member
  • **
  • Join Date: Nov 2015
  • Location:
  • Posts: 61
  • Kudos: 2
Max P5 Matrix size
« on: January 28, 2018, 07:34:59 AM »
I have this idea of a 7x8 P5 matrix (434x256) using multiple ColorLight cards. Will FPP be able to drive this many channels? Would I have any refresh issues using 1/16 scan panels?

Offline k6ccc

  • Full Member
  • ***
  • Join Date: Mar 2015
  • Location: Glendora, Calif, U.S.A. (near Los Angeles)
  • Posts: 213
  • Kudos: 0
    • Newburgh Lights
Re: Max P5 Matrix size
« Reply #1 on: January 28, 2018, 01:10:20 PM »
First of all, your math is off a little - it would presumably be 448 x 256 with a total of 114,668 pixels and 344,064 channels.  That would be 672 universes.
I cant answer the limitations in FPP other than a few comments I have read on this forum.  How were you thinking of driving this matrix?  By that I mean a single FPP computer driving the panels, multiple FPP instances in master / slave mode, via E1.31 from one computer driving one or more FPP instances that are driving the matrix, etc.
With 672 universes, if driving via E1.31, that would require gigabit networking as you cant cram 672 universes into a 100mb/s connection.
As for refresh rates, the comments I have read is that you will have flicker issues with more than a few panels per output.  For what its worth, I am building a 3W x 2H P5 matrix this year that I plan to drive via E1.31 into a Pi with three outputs each driving only two panels each.  It will be several months before I have the panels (I expect), so I dont know what it will look like yet.



Sent from a $&@#% iPhone using Tapatalk
Jim

Offline CaptainMurdoch

  • Administrator
  • *****
  • Join Date: Sep 2013
  • Location: Washington
  • Posts: 9,012
  • Kudos: 179
Re: Max P5 Matrix size
« Reply #2 on: January 28, 2018, 01:50:05 PM »
If you have that many panels, you have to start asking yourself, is 'sequencing' data for them the right way to go.  ~345K channels is 7 MegaBytes per second at 20fps.  You might be better off using the sender and receiver cards to drive the panels.  The sender would be connected to the HDMI output of the PC or Pi and you could either play a video on the panels or use a Virtual Matrix to display sequence data.

Refresh rates shouldn't be an issue if you are within specs on the receiver card regarding panels per output, etc..  These things are built for commercial displays.

I haven't tested the ColorLight Channel Output with more than one board so far.  I need to pick up another ColorLight in order to test.  The bottleneck might come down to the USB network interface on the Pi
-
Chris

Online Cjaqua

  • Jr. Member
  • **
  • Join Date: Nov 2015
  • Location:
  • Posts: 61
  • Kudos: 2
Re: Max P5 Matrix size
« Reply #3 on: January 28, 2018, 02:57:41 PM »
K6cc, thanks for correcting my math mistake. I am open to whatever methods are available for driving that many channels. Captain, thanks for the suggestion of a sender card connected via hdmi and using a virtual matrix to display sequence data. I think I will give that a shot on a smaller matrix before trying to go big.

Offline pixelpuppy

  • Hero Member
  • *****
  • Join Date: Aug 2015
  • Location: Dallas, TX
  • Posts: 750
  • Kudos: 15
Re: Max P5 Matrix size
« Reply #4 on: January 29, 2018, 07:35:57 AM »

Question for Dan (dkulp) and Chris (CaptainMurdoch):

What is the P5 matrix size limit using BBB+Octoscroller?  How about Pi+MatrixHat?


With P10's I thought the absolute max size with BBB+Octo would be (8 ports)x(12 panels per port) but there is discussion in another post that seems to indicate fully loading the ports with 12 panels can result in scan/refresh visual issues.  So what is the realistic practical max limit? 8x8?  And that is with P10's.   If we swap them out for 64x32 P5's does that reduce the practical max to 8x4?


I need to know asap for planning/purchasing decisions coming up very quick.  I was hoping to swap out all my P10's for P5's this year, but unclear on the size limits per BBB+Octo.


{advTHANKSance}
xLights and Vixen3 for sequencing / FPP for scheduling and playing / Falcon controllers for pixels / DIY controllers for everything else

Offline dkulp

  • Developer
  • ******
  • Join Date: Sep 2013
  • Location: Framingham, MA
  • Posts: 729
  • Kudos: 27
Re: Max P5 Matrix size
« Reply #5 on: January 29, 2018, 07:58:03 AM »
What is the P5 matrix size limit using BBB+Octoscroller?  How about Pi+MatrixHat?

With P10's I thought the absolute max size with BBB+Octo would be (8 ports)x(12 panels per port) but there is discussion in another post that seems to indicate fully loading the ports with 12 panels can result in scan/refresh visual issues.  So what is the realistic practical max limit? 8x8?  And that is with P10's.   If we swap them out for 64x32 P5's does that reduce the practical max to 8x4?

I need to know asap for planning/purchasing decisions coming up very quick.  I was hoping to swap out all my P10's for P5's this year, but unclear on the size limits per BBB+Octo.


Honestly, I don't know as there are SOOO many factors that go into it.   If using bridge mode, the limits are lower as we cannot get that much data into the BBB via the network.   There's really not much we can do about that.  At some point, I want to test if using a USB network adapter (gigabit) or possibly a 300Mbit wifi or 1.3GB wifi (5ghz) would help, but I don't have time to even look at that right now.   The Pi would likely be even worse for this as it's network adapter is even slower than the BBB's.   


Another factor seems to be the panels themselves....   The P10's and P5's I have work perfectly for one panel per output (and that's how I run my tuneto).   Some of the newer panels seem to have a ghosting issue with that, but start working fine at some multiple as the refresh drops a bit while it takes longer to output all the data.   I may have to add some "delay" settings or something to account for some of that.   That said, this shouldn't really affect the longer chains, it's mostly the shorter chains that have this issue.


In non-bridge mode, you have to deal with the SD card.   In general, the SD card is faster, but "cheap" SD cards have been known to cause issues getting that much data off of it.   Using btrfs with compression can HELP limit that problem, but then introduces more processor overhead.   Since preparing 96 panels of data already taxes the CPU fairly hard, I don't know if it would cause new issues or not. 


The 64x32 P5 panels (assuming 1/16 scan) have two challenges:
1) Amount of data - 4x the amount.
2) Scan rate - 1/2 of the 1/8 P10's.   It literally takes twice as long to display a panel.


Combining both issues, I would likely say the limit is more around 8x3.  8x4 may be OK if you drop to 7bit or 6 bit color as that reduces the number of scans it needs to do.   The 64x32 P5 "outdoor" panels that are 1/8 scan eliminate the second issue and would be able to support more panels.   Those would likely be around 8x5 or 8x6, maybe.  Haven't tried.


For large matrices, you are likely better off using a Sender card (connected via HDMI to either Pi or computer directly) and a receiver card.  The receiver card control panel things provide all kind of settings and such to really control things and account for panel variability that there is no way we'll ever be able to reproduce.   
Dan Kulp

Offline CaptainMurdoch

  • Administrator
  • *****
  • Join Date: Sep 2013
  • Location: Washington
  • Posts: 9,012
  • Kudos: 179
Re: Max P5 Matrix size
« Reply #6 on: January 29, 2018, 10:53:44 AM »
Since preparing 96 panels of data already taxes the CPU fairly hard, I don't know if it would cause new issues or not. 

Part of the issue with this right now is that the data 'prep' occurs right before the data send.  I have started adding a 'PrepData()' member to the Channel Output classes and want to break that off so that data prep can occur before the channel output thread sleep rather than after the sleep.  When the output thread wakes up, we should be ready to send, but with some channel outputs, there is still a bit of prep that happens in RawSendData().  This is mainly true for the matrix panel and WS281x/WS2801 string outputs since the data has to be formatted into the correct output location and color order and that is a lot of single-byte copies.  There are also some optimizations that could be done to the data copies for the LED panels but I haven't had time to try to sit down and optimize that code.  In some cases, we could do one big memcpy() to catch one or two colors and then 'fill in' the gaps with byte copies.

Offline k6ccc

  • Full Member
  • ***
  • Join Date: Mar 2015
  • Location: Glendora, Calif, U.S.A. (near Los Angeles)
  • Posts: 213
  • Kudos: 0
    • Newburgh Lights
Re: Max P5 Matrix size
« Reply #7 on: January 29, 2018, 01:09:00 PM »
Another factor seems to be the panels themselves....   The P10's and P5's I have work perfectly for one panel per output (and that's how I run my tuneto).   Some of the newer panels seem to have a ghosting issue with that, but start working fine at some multiple as the refresh drops a bit while it takes longer to output all the data.   I may have to add some "delay" settings or something to account for some of that.   That said, this shouldn't really affect the longer chains, it's mostly the shorter chains that have this issue.

I have been seeing the ghosting on my P10 panels - 12 panels on a single output from a Pi 3.  I will be using the panel for mostly text.  What I though was odd was it was only noticeable when the text was stationary.  If it was moving, I did not see it.  I am generating the data from LOR so obviously using E1.31 bridge mode.  So far, I am NOT inspired enough to do a WireShark capture and analyze the data to see if the ghosting is in the data stream, but that is an option if I get desperate enough.  You can see some of that in the video link below.  Generally when the problem is visible, the ghosting is to the left of the intended text.  The cellphone camera somewhat washes it out, but the ghosting is visible at times.  Note this was a crappy cellphone video with the panels just laying on the floor because I have not received the mechanical parts to hold them together.  The video is 8 P10 panels.

https://youtu.be/isdJBSD16KQ

Offline k6ccc

  • Full Member
  • ***
  • Join Date: Mar 2015
  • Location: Glendora, Calif, U.S.A. (near Los Angeles)
  • Posts: 213
  • Kudos: 0
    • Newburgh Lights
Re: Max P5 Matrix size
« Reply #8 on: January 29, 2018, 04:01:52 PM »
For large matrices, you are likely better off using a Sender card (connected via HDMI to either Pi or computer directly) and a receiver card.  The receiver card control panel things provide all kind of settings and such to really control things and account for panel variability that there is no way we'll ever be able to reproduce.

Until I read this, I had no idea what sender and receiver cards were.  Did a little Google search, and maybe I understand.  As I understand it, a sender card takes a video input, converts it to raw Ethernet, and then a receiver card receives that raw Ethernet and drives a bunch of matrix panels.  So it should display whatever video that the sender card gets handed to it.  Do I have that right?  I also now understand what the ColorLight thread in this forum is all about.  If I'm right, this would be great for people trying to run video on a matrix, but does nothing for "normal sequencing".  Do I have the concept right?

Offline jchuchla

  • Sr. Member
  • ****
  • Join Date: Jul 2014
  • Location:
  • Posts: 290
  • Kudos: 0
Re: Max P5 Matrix size
« Reply #9 on: January 29, 2018, 10:10:35 PM »
Until I read this, I had no idea what sender and receiver cards were.  Did a little Google search, and maybe I understand.  As I understand it, a sender card takes a video input, converts it to raw Ethernet, and then a receiver card receives that raw Ethernet and drives a bunch of matrix panels.  So it should display whatever video that the sender card gets handed to it.  Do I have that right?  I also now understand what the ColorLight thread in this forum is all about.  If I'm right, this would be great for people trying to run video on a matrix, but does nothing for "normal sequencing".  Do I have the concept right?

The sender cards take a video input stream and convert it into a proprietary data format.  Some are Ethernet, some aren't.  But the actual format immaterial to this discussion.  Bottom line is that it travels over cat5 (or fiber)  and gets connected to a matching receiver board.  The whole video picture (or sometimes a subset thereof) is converted by the sender and streamed in a proprietary format over this link. Each receiver card is configured to use a portion of this stream and output it for the specific type of panel you have connected to it.  The receiver cards are designed to be daisy chained so that each card is configured to use a section of the overall picture. 

Some of the receiver cards can accept data in the form of specially formated raw ethernet frames over an gigabit ethernet network.  For some cards, this mechanism is actually how it works behind the scenes with the sender.  In other models, it's an alternate transmission mode.  In this way, they can be driven directly from a PC running the software from the card manufacturer.  Chris reverse engineered this format for the linsn and colorlight cards and is able to drive them directly from FPP.  WHen driving it from FPP, it's using sequence data and outputting it directly to the receive card.  The receive card is doing all of the heavy lifting of driving the panels themselves, and the FPP is just feeding it the data to display.

In the end, you have to ask yourself what are you doing with these panels.  Are they lights, or is it a video display.  How do you want to design the content?  There comes a point where is isn't appropriate to use a light sequencer to lay out channel data for every pixel for every frame.  It's just not efficient.  Not efficient to create the content, to render it, to store it, to transfer it, or to play it.   What you have there is a video display.  It's far more efficient to create the content with graphics/CGI software, to store it and move it around in compressed formats, to decompress it with hardware acceleration, and play it out over a digital video transport like HDMI or DVI.  The matrix array you're describing is close to a QVGA resolution.  That's huge when handling it with light sequencing mechanisms, but it's peanuts for video systems.

Online Cjaqua

  • Jr. Member
  • **
  • Join Date: Nov 2015
  • Location:
  • Posts: 61
  • Kudos: 2
Re: Max P5 Matrix size
« Reply #10 on: February 10, 2018, 12:37:46 PM »
I have been successful in getting the Pi to output a 1:1 pixel ratio over the HDMI to my small P5 2x3 test matrix (128x96) thanks to the help of darylc and his post on auschristmas. I used a Linsn TS802D sender card and an RV908M32 receiver card. This exercise was to ensure I could make it work before embarking on building a bigger P5 matrix since the Pi should be able to drive a larger p5 matrix over HDMI than it can over ethernet. The only issue that I have run into so far which is unrelated to driving them over the HDMI interface, is a trailing/ghosting effect on my 1/16 scan SMD3528 P5 panels. For example, if I set a single pixel on the top row of my matrix to white, the 15 pixels below it have a very faint green. It's almost like the white is bleeding over to the pixels on the same column of 16 it if they aren't lit up. Attached is an exaggerated picture of what I am talking about as I can play with the refresh rate to make this trailing/bleeding less noticeable but I haven't found any settings that would eliminate it. Anybody have any ideas on what I could try to fix it? I am seeing this issue on the 1/16 scan SMD3528 p5 panels I recently purchased from Coreman and also the ones I purchased from Ray Wu.

Offline CaptainMurdoch

  • Administrator
  • *****
  • Join Date: Sep 2013
  • Location: Washington
  • Posts: 9,012
  • Kudos: 179
Re: Max P5 Matrix size
« Reply #11 on: February 10, 2018, 12:51:16 PM »
In the Linsn software, you should be able to dial down the refresh rate, it sounds like it is refreshing too fast.  I'm not in my office to check, but it should be easy to find the setting.  The Pi and BBB have the same issue in that they are now so optimized that they can refresh faster than some panels can handle.

Offline ronp

  • Newbie
  • *
  • Join Date: Nov 2014
  • Location:
  • Posts: 30
  • Kudos: 1
Re: Max P5 Matrix size
« Reply #12 on: February 11, 2018, 06:40:39 PM »
The only issue that I have run into so far which is unrelated to driving them over the HDMI interface, is a trailing/ghosting effect on my 1/16 scan SMD3528 P5 panels. For example, if I set a single pixel on the top row of my matrix to white, the 15 pixels below it have a very faint green. It's almost like the white is bleeding over to the pixels on the same column of 16 it if they aren't lit up. Attached is an exaggerated picture of what I am talking about as I can play with the refresh rate to make this trailing/bleeding less noticeable but I haven't found any settings that would eliminate it. Anybody have any ideas on what I could try to fix it? I am seeing this issue on the 1/16 scan SMD3528 p5 panels I recently purchased from Coreman and also the ones I purchased from Ray Wu.


The ghosting is due to the driver for the LED's on the panel. Texas Instruments has an application note on a chip that will fix the problem. With that said you can adjust the sequence of software output to minimize the effect. Which means you can't do anything for the off the shelf cards.

Online Cjaqua

  • Jr. Member
  • **
  • Join Date: Nov 2015
  • Location:
  • Posts: 61
  • Kudos: 2
Re: Max P5 Matrix size
« Reply #13 on: February 11, 2018, 09:15:18 PM »
The ghosting is due to the driver for the LED's on the panel. Texas Instruments has an application note on a chip that will fix the problem. With that said you can adjust the sequence of software output to minimize the effect. Which means you can't do anything for the off the shelf cards.

So, we have to wait until they start producing some panels with the new LED driver? How long does that typically take? Also, how would we know which panels have the new led driver?
« Last Edit: February 11, 2018, 09:27:25 PM by Cjaqua »

Offline Sawdust

  • Sr. Member
  • ****
  • Join Date: Nov 2015
  • Location: Northern CA
  • Posts: 414
  • Kudos: 0
Re: Max P5 Matrix size
« Reply #14 on: February 11, 2018, 10:47:24 PM »
The only issue that I have run into so far which is unrelated to driving them over the HDMI interface, is a trailing/ghosting effect on my 1/16 scan SMD3528 P5 panels. For example, if I set a single pixel on the top row of my matrix to white, the 15 pixels below it have a very faint green. It's almost like the white is bleeding over to the pixels on the same column of 16 it if they aren't lit up. Attached is an exaggerated picture of what I am talking about as I can play with the refresh rate to make this trailing/bleeding less noticeable but I haven't found any settings that would eliminate it. Anybody have any ideas on what I could try to fix it? I am seeing this issue on the 1/16 scan SMD3528 p5 panels I recently purchased from Coreman and also the ones I purchased from Ray Wu.


The ghosting is due to the driver for the LED's on the panel. Texas Instruments has an application note on a chip that will fix the problem. With that said you can adjust the sequence of software output to minimize the effect. Which means you can't do anything for the off the shelf cards.


I am running Pi2, Pi Zero & Pi Zero W without ghosting.  Only Pi3 give me ghosting

 

Back to top