-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide a way to extend the chain that just mirrors the first part. #1000
Comments
Also, 1000! :) |
mmh, usually if you add another panel beyond the length, the output is very poor there: the bits are shifted there, but the timing of course does not line up (the bits are off-by-one), so colors are horrible. Not sure how useful such feature is given that the can just declare a larger frame and set the pixels twice. |
@hzeller Check out https://photos.app.goo.gl/iH1BeCyrtAKFfLBS8 for how it looks like. I refreshed my memory with #947 Long story short, you are correct that the colors are not exactly the same, but they are close enough that it doesn't really matter for my use. I'm not sure how you would send the data twice without splicing cables. Is there a good way to do this? I think I already sent you this, but in case you were wondering why the need for mirror display, it's for this use. I have the same display front and back, and to ease wiring, I simply shift the front panels into the rear ones. |
And basically my previous comment is saying "feel free to close this issue as WONTFIX" if you don't think there is a reasonable need to support this (there probably isn't), and I'll patch my way around it (will probably send the patch to this issue if anyone finds it later with google and wants it) |
Changed this to feature request. Essentially we want a |
Hi @hzeller and @marcmerlin, I know this thread is from a while ago, but I'm curious, I am now wanting to do the same thing, and was wondering if there were any updates or workarounds found for this in the last 3 years? Here's how far I got with my attempts tonight: I have a square 128x128 panel (2 x 64x128) that I want to mirror. Similar to you Marc, I'm displaying these as screens on the front and back of an outfit, so I want to mirror and not extend these squares (extending ends up being too many pixels for the CPU to display nicely) Tonight I made some custom daisy-chained ribbon cables to try and achieve this goal: This results in:
To my surprise, this actually worked pretty well. The top panels of the screens (chain 1) create an almost identical duplicate (even the colors look the same). However, the bottom panels of the screens (chain 2), display some tearing/ghosting/blinking/imperfections. It's hard to show this with a static image, but the area in the circle is aggressively flickering. Any idea why this might be happening, or what steps I could take to fix it? Do the ribbon cables need to be more of a 'Y' split cable, rather than a single ribbon with a drop-off point in the middle? Any suggestions welcome, I'm pretty new to this level of LED debugging! Thanks. |
ha, right after I posted this, I experimented with changing the gpio slowdown, and seemed to have stumbled into a solution! I was previously slowing it down to 3. Then set the value to 4 and these imperfections magically disappeared. Out of curiousity.. Any idea why slowing down the GPIOs helped with this issue? If not, no probs, I'm happy with this as it is! |
Yes, slowing down helps. Also, making the data cables as short as possible is probably good, but I guess given the size of the panels, that might not be possible. There can be weird reflections at the end of the cables, so playing with a y-configuration might be interesting. You use an active adapter as an interface between your Pi and the boards, right ? Another thing to look out for is that the panels have a solid power supply. I have seen panels glitch in the way you describe if they didn't get full 5V, or the cable to the power supply was too long. Sometimes a low-ESR capacitor at each power input at the panels can help as the panels draw very spiky load from the power supply (There are some musing about this in the a word about power section). |
@andytheengineerguy : Another possible fix is to use two active boards, connected to RPI in parallel. |
@ledvinap I already use active board with 3 outputs to get my 128x192 at max speed, and then divide speed by 2 since I shift pixels from the first display to the 2nd one for mirroring. |
@marcmerlin : IMO, when connected this way, you get bitplanes shifted one one PWM period on second panel. It will always ruin colors. |
hi @hzeller, thanks for your response. I am using an active-3 board from electrodragon yes. I might try with Y-ribbon cables, if I do I'll post results here. I indeed read your section on power and was considering experimenting with the low-ESR capacitors. The final product will be battery driven, so I'm motivated to reduce the current spikes regardless, so thanks, I'll give this a shot 💪 @marcmerlin I'm not understanding your approach just yet; if you simply want to mirror/duplicate your display, can you not just connect the data bus in parallel using custom cables as I have above (keeping all else the same)? What is the reason behind dividing the speed by 2 and then sending pixels twice? @ledvinap I'm also not 100% sure I understand this too. Are you recommending using 1 active board per LED chain? |
@andytheengineerguy, the reason for my approach simply ease and length of cabling. It's easier to take the hub75 out connectors on the front panels and connect them to the hub75 in connectors of the rear panels I run 3 busses in parallel, but indeed I have to push the pixels twice for each frame, so each panel runs at half speed, but since I'm only pushing 256x64 per bus, it's still fast enough. If I had easy to find Y cables of the right length, I would consider them, it would double my refresh rate. I'm just not equipped to make my own. And to answer your question to @ledvinap , I recommend you use one active board chain (you have 3 on electrodragon) per chain. If at all possible, you should always use 3 chains on any layout of 3 panels or more, simply to maximize the refresh rate for each panel (that is unless you have something very small like 64x64 where it really doesn't matter) |
@marcmerlin ahhh ok, that makes sense. Given that the refresh rate is enough for your needs, it's a good call to simplify the wiring by just pushing the pixels twice / frame. Btw, if you're interested, you can use this IDC crimp tool to easily make your own cables, I bought this recently and it works great 👌 Regarding the active board chains, I see what you're saying, but for the sake of keeping the 128*128 screens 100% equal I think I'll stick with what I'm already doing, which is using 1 chain for the top 2 panels and the other chain for the bottom 2 panels. Each chain has its own logic buffer and 1 chain will be remain unused, but I seem to be getting high enough refresh rates anyway (~240). |
@andytheengineerguy totally for 128x128, 2 chains is more than plenty. And if you tweak some colors/precision settings, you should be able to get over 500Hz :) |
Python bindings are just bindings, the actual code still runs in C++ at full speed, so you should get the same refresh rate.
|
I was always under the impression that anything above ~250Hz was diminishing returns; our eyes are good at ~100 and phone cameras never work well with this highly multiplexed scan architecture that comes with screens like ours (assuming yours is 1/64 or 1/32?). whats the reason for aiming for such high Hz? Are you filming in slow motion or something? |
EDIT: I meant 1/32 scan, not 1/64 Ahh I was wondering - I'm also creating some LED art to show at music festivals, and yeah, want to be able to take pictures with it. But I'm finding that we're limited by the architecture more than anything else.... This is a screenshot of 3 pics I took @ 470Hz, absolutely bonkers FPS under normal circumstances, but apparently still not good enough when only 1/32 of the screen is illuminated at once. Even when the black lines don't appear, there are noticeable white lines that make it look weird. I think thats why I said the defeated-sounding "dimishing returns" comment haha - if 500Hz doesn't cut it, what will. A DSLR camera maybe? |
Mmmh, that's disappointing indeed :-/ |
Just purchased some 1/16 scan rate, and also a less common 1/13 scan rate to experiment with. Will see how it goes. Happy to share results if you're interested. |
Sure thing, thanks |
I have a panel setup where my display is mirrored onto a 2nd display, so I use ribbon cables to plug the 2nd set of panels as output of the first ones.
I don't get or want a wider display, I just use the fact that the pixels get shifted out to load the 2nd panels.
This works fine, except that with FM2616A, the init sequence doesn't get sent wider than the display size, so the mirrored display doesn't get initialized.
Workaround: send a bogus frame that is twice as wide to init all the panels
Better workaround, some init option to give a width init factor (default to 1, but could be 2, 3, whatever)
The text was updated successfully, but these errors were encountered: