PDA

View Full Version : New P10 panels not matching



jwamsley07
01-10-2017, 04:57 PM
I had my p10 grid working for Halloween and Christmas but decided I wanted to add on, going from a 3X5 to a 4X6.
I ordered some more P10's from the same vendor I purchased before and they don't match. The newer ones are darker almost more bluish/purple. It is very noticeable with brighter colors. I played around with the voltage a bit hoping to fix it, but no go. I emailed the vendor asking for advice but thought I would see what others in here may have done when expanding P10 grids.
Attached is a picture to show the difference.

Not My Monkeys
01-10-2017, 05:23 PM
Very common, but not sure there is a good answer for you. Even same vender different runs can look different. Almost every single p10 post recomends ordering as big as you think you'll need all at once, and some spares to best ensure you get stock from the same run and avoid this issue.

Sorry there is no better news / advice I can offer.

Wolfie
01-10-2017, 05:38 PM
Your only option is to sell them as 2 groups and then use that money to buy a complete set all at once.

didjareally
01-10-2017, 06:43 PM
Before doing anything major, try it out in a real world scenario. What are you using the matrix for? Text, video, effects, all of the above? Whatever you are going to use it for, try it out with that and see how noticeable it is. It may not be as bad as trying out solid colors. You can also run into this problem even if you had ordered them all at once, it just depends on if the panels came from the same batch or not from the manufacturer.

jchuchla
01-10-2017, 08:17 PM
the professional panel driver boards (linsn, colorlight, novastar) all have per panel calibration functionality to compensate for exactly this situation. This requires quite a bit of realtime processing power though for the value transformations, so I wouldn't expect it coming to FPP anytime soon.

Ruppro
01-10-2017, 10:53 PM
Maybe mix the panels in a staggered pattern to minimize the differences.

CaptainMurdoch
01-11-2017, 12:45 AM
the professional panel driver boards (linsn, colorlight, novastar) all have per panel calibration functionality to compensate for exactly this situation. This requires quite a bit of realtime processing power though for the value transformations, so I wouldn't expect it coming to FPP anytime soon.

I am assuming this is configured in the software and pushed to the receiver board? Or is it on the sender side? If it is on the receiver side then FPP can do it in a development branch since I committed code to drive one of the ColorLight cards directly from FPP. FPP already does a lot of byte shuffling to map the pixels into the right positions since we allow zig zag and other non-standard layouts. I might be incorrect but I haven't seen any option for the ColorLight to support wrapping or a mix of horizontal and vertical panels in a single matrix. Theoretically we could add per panel brightness adjustment to FPP but it is a low priority. FPP v2.0 will allow global brightness adjustment with a performance impact depending on the number of channels being used. I think my testing showed that a Pi B could perform 64K array lookups and assignments in 4ms so there is a slight delay for something like that in software.

jchuchla
01-11-2017, 02:08 AM
I am assuming this is configured in the software and pushed to the receiver board? Or is it on the sender side? If it is on the receiver side then FPP can do it in a development branch since I committed code to drive one of the ColorLight cards directly from FPP. FPP already does a lot of byte shuffling to map the pixels into the right positions since we allow zig zag and other non-standard layouts. I might be incorrect but I haven't seen any option for the ColorLight to support wrapping or a mix of horizontal and vertical panels in a single matrix. Theoretically we could add per panel brightness adjustment to FPP but it is a low priority. FPP v2.0 will allow global brightness adjustment with a performance impact depending on the number of channels being used. I think my testing showed that a Pi B could perform 64K array lookups and assignments in 4ms so there is a slight delay for something like that in software.
I honestly don't remember off hand if the processing is done in the sender or receiver. I forget which tab that's on. But i'd venture to guess it's in the receiver. It makes more sense there because the way the receiver drives the panels. The sender is sending it out in video picture order. The receiver takes that data and transforms it for the order of the connected panels. So it already has the blocks of data lined up in a per panel order. It would make more sense to apply the per panel brightness transformations there. It's been a while since I balanced a wall myself and may be forgetting the software steps, but I'm pretty sure, the adjustment is a config time adjustment, not part of the datastream being fed to the receiver. So it's a constant for each module that's part of the receiver card's config file that gets sent to the receiver as part of it's config file. I seem to remember it being a "tweak, send, check, tweak, send again, check" type of process.
Are you configuring the receive cards from this new plugin, or just sending channel data to them?

Keep in mind that most of these sender/receiver cards are designed for a one sender to many receiver topology. In most actual products and installations, there's a fairly small number of panels per receiver card. They're generally something like 4x8 panels or so. Usually it's the same ratio as power supplies. e.g. one receiver and one power supply for whatever number of panels can be driven by that power supply. The exact number varies a lot based on pixel pitch and LED type. This unit of several panels, one PS, and one receiver along with it's enclosure or frame is usually called a tile, or a panel. (what we call panels, they usually call modules). So to straighten out terminology and concepts further, what we call a whole matrix, is what's usually called a panel or tile. Several panels/tiles connect together to make a bigger screen. The difference being that in our mind, we're used to a one to one relation between sender and receiver, or that there's only one electronic driver thingy that controls all of the panels in the matrix. In the real world, the typical topology is master sender to many slave receivers, each slave driving a section of the screen,.
I bring this up because it helps to understand/interpret the config options in the software of these cards. For example, it's at this level where you can change panel types and layouts. Each tile (each receiver card) can be a completely different arrangement. Different pixel pitch, different module layout/orientation/quanity. But within a tile (behind the receiver card), the arrangement and led module type is the same.

CaptainMurdoch
01-11-2017, 04:21 AM
The FPP ColorLight channel output just sends data currently, it does not configure the receiver board. Given the amount of time it takes to push the config to the receivers using the config utility, I am assuming it is probably something I don't want to try to reverse engineer right now and would rather spend my time elsewhere like maybe figuring out the Linsn data protocol, or getting back to other v2.0 features I should be working on instead.