Vmapper #1009

marcmerlin · 2020-03-18T04:12:54Z

Ok, this was more work than I thought for something seemingly simple (well, it's likely just that I suck at it), but it works!
Hopefully this puts me in the lead for the highest usable resolution display on a single rPi (384x256) :)

pull upstream

hzeller · 2020-03-18T04:37:29Z

Cool!
Only potential user-support issue I see is that the panels are fed from the top while the 'usual' way is to feed them from the right.

So to reduce potential user-support in the future, I suggest to not deviate too much from the 'things are fed from the right side', and think about stuff rotated by 90 degrees (it is probably just a little x/y swap fiddle somewhere).

To make sure there is no confusion about how to connect each of these panels, can you add an text-art that indicates how they are exactly chained ? I find that the Macron-Character is excellent for this kind of stuff:

[v]¯\_[v]¯\_[v]¯\_[v]¯ ch1
[v]¯\_[v]¯\_[v]¯\_[v]¯ ch2
[v]¯\_[v]¯\_[v]¯\_[v]¯ ch3

(if you still want to operate it from the top in your specific application, you then can use the Rotate transformation to get it back rotated)

hzeller · 2020-03-18T04:38:34Z

(also, this brings out much more of the V-ness)

marcmerlin · 2020-03-18T05:13:02Z

Mmmh, so the whole point of vmapper is that the panels are fed up-down. Sure, I can rotate everything and then force the use of a second rotate:90 mapper to get it the way you're suggesting, but the whole point of V-mapper is that the panels are fed from up to down (or down to up).

I think you're saying that I can pretend that my panel is like this, is that what you meant?

If so, I'm not sure I'm not sure if your suggestion actually makes thing more obvious given that the point of V stacking is that you want matrix is naturally higher than wide, so it's not very obvious to rotate it 90 degrees. In that picture the panel is rotated so that it fits better in the picture, but in actual use, it is up-down.
That said, if somehow you have a usage case where you want it that way, you can always use rotate:90, but by default I think it ought to be the way I coded it, wouldn't you agree?
I'm happy to change the ASCII to show how the wiring is (as per your suggestion).
Would that sole change be ok?

hzeller · 2020-03-18T05:26:56Z

mmh ok, so the reason why you want to feed it from the top is that then the panels are 'upright' as they are meant to be ? (because sometimes the LED shielding sideways is a little different than up/down). I could be convinced by that.

Let's do the ASCII art improvement for now, but since you turn it 90 degrees than in my suggestion, you probably need some sort of 'right side pipe symbol' and 'left side pipe symbol' and backslash to illustrate.

marcmerlin · 2020-03-18T05:48:00Z

Just to answer your question, yes, the panels are upright as they were meant to be, check the picture I included at the top.
This is their natural position given the writing on the back, so I felt it made sense to keep them that way by default.
Of course if someone needs a resolution that is the other way around, they can use rotate.

hzeller · 2020-03-18T05:51:19Z

examples-api-use/README.md

+  Ch1     Ch2     Ch3
+   v       v       v
+  [I > O] [I > O] [I > O]
+   ,---'   ,---'   ,---'


Oh, pretty :)

hzeller

so the natural direction of these panels is actually with the input on the right side, so right now they are upside down. So we still have to change that and 180 degree change it.

(I have seen outdoor panels that actually have a strong directional component downwards as they are meant to to be mounted high-up)

(In the case of your set-up that means you have to then Rotate:180 the output if you can't have the Pi at the bottom of the display)

lib/pixel-mapper.cc

hzeller · 2020-03-18T15:52:22Z

Do you have a picture of the panel backside ? Every panel I have ever seen has the input on the right side (seeing from the face of the panel), not on the left.

hzeller · 2020-03-18T16:04:16Z

Looking at the three-chained V-example you have above, I don't see arrows but the text is indeed up only if the input is on the right.

So looking to the front of the panel, the input is on the right, so we need to make sure to have the code reflect that.

marcmerlin · 2020-03-18T16:06:11Z

hzeller · 2020-03-18T16:07:51Z

See, input is on the right of the panel, output on the left
(looking from the back, the input is on the left, output on the right)

marcmerlin · 2020-03-18T16:09:13Z

connector is left when seen from the back, right when seen from the LED (front) side.
The new graph I sent you is showing I on the left which is where it is when you are wiring the panels and the connectors are facing you.
Regardless of whether we show one side or the other, it should be clear enough to someone repeating this hopefully :)
That said if you feel strongly about the graph showing from the LED side, which ultimately is not the side you see when you are wiring, I can flip it around for you.

hzeller · 2020-03-18T16:11:38Z

The wiring diagrams in all of the rpi-rgb-led-matrix done are all with the panel fronts looking toward you.
So if you have this already wired and programmed this way, then just the graphics needs to be flipped.

marcmerlin · 2020-03-18T16:28:03Z

Sure, PTAL

examples-api-use/README.md

hzeller · 2020-03-18T16:35:52Z

lib/pixel-mapper.cc

+    *matrix_x = (x % panel_width) +  int(y/panel_height)* panel_width;
+    *matrix_y = (y % panel_height) + int(x/panel_width) * panel_height;
+
+    //fprintf(stderr, "%s: Panel-W:%d Panel-H:%d. X: %3d -> %3d, Y: %3d -> %3d\n",


Don't leave commented-out code in the final version.

So, I left it there on purpose it case it helps someone (possibly me) writing the next mapper. Understanding how things worked without it would have been hard (it was non obvious to see how things were mapped)
If you'd prefer, I can put it under an #ifdef 0 or something else, though, but if you really don't want it, I can remove it and apply it again in my tree as I will definitely want it again in the future if I write another mapper.
What's your call?

Removing commented-out here. Someone who will want to debug this will add something very similar in the working copy, but here, we should leave out the clutter.

Also above in the GetSizeMapping(), the output should not be there, but you can #if 0 that out if you want.

hzeller · 2020-03-18T16:37:47Z

Cool, almost ready to go: just some leftover debug printf to be removed.

hzeller · 2020-03-18T17:18:56Z

Thanks for your contribution! Merged.

hzeller · 2020-03-18T17:34:18Z

Do you have a picture of the back of your panel that you'd like to share ? I think similar to the U-mapper example image, that will help people in the wiring.

marcmerlin · 2020-03-18T18:25:39Z

@hzeller I don't have rails, it's sadly all like just sitting on my desk, so I can't really flip it around
The picture I gave upthread of a single set of 3 panels is basically what a chain looks like (different panel, but identical wiring)

marcmerlin · 2020-03-21T00:45:09Z

@hzeller Well, I will owe you a new matter soon, Vumapper :)

And I have the back of this one

hzeller · 2020-03-21T01:12:30Z

You're really going to town with these panels :)

marcmerlin · 2020-03-21T01:41:33Z

those old 64x32 panels that were donated to me, were gathering dust, I felt bad about it, and like many I have a few extra hours at home right now :)
Don't worry, after a not too long while, I'll get bored with this, and switch to another hobby like RC planes :)

rijotech · 2020-03-27T15:22:03Z

I'm trying to replicate the panels setup but can't seen to find the right set of commands to get a straight image. @marcmerlin care to provide an example? I already haverything wired the same way with 12 64x32 panels.

marcmerlin · 2020-03-27T15:39:09Z

@rijotech please try
~/rpi-rgb-led-matrix/examples-api-use/demo --led-gpio-mapping=regular --led-rows=32 --led-cols=64 --led-row-addr-type=0 --led-chain=4 --led-show-refresh --led-slowdown-gpio=1 --led-parallel=3 --led-panel-type=FM6126A --led-pwm-bits=7 --led-pwm-dither-bits=1 --led-pixel-mapper=V-Mapper:Z -D0
If that fails, please post picture of what you are seeing.
Obviously, your led chain will be 4 for 3x4 panels (mine was 5)

rijotech · 2020-03-27T17:12:23Z

@rijotech please try
~/rpi-rgb-led-matrix/examples-api-use/demo --led-gpio-mapping=regular --led-rows=32 --led-cols=64 --led-row-addr-type=0 --led-chain=4 --led-show-refresh --led-slowdown-gpio=1 --led-parallel=3 --led-panel-type=FM6126A --led-pwm-bits=7 --led-pwm-dither-bits=1 --led-pixel-mapper=V-Mapper:Z -D0
If that fails, please post picture of what you are seeing.
Obviously, your led chain will be 4 for 3x4 panels (mine was 5)

Thanks a lot @marcmerlin I already figured out I cloned your repo and figure it how to make it work. Thanks to you both! and stay with this pandemic.

lehni · 2022-01-21T16:36:25Z

@marcmerlin is there a way to reverse the sequence of the chains, so I can go right to left, bottom to top in my wiring?

hzeller · 2022-01-21T16:48:45Z

could you use use the mirror or rotate mappers stacked on the v-mapper ?

marcmerlin · 2022-01-21T18:06:12Z

Henner's answer is best, my code was indeed only written for one direction, but hopefully the transforms on top will sort you out

lehni · 2022-01-22T21:17:27Z

I've reversed the cable routing instead, all good :) Thank you both for the quick feedback!

marcmerlin added 2 commits March 17, 2020 20:49

Merge pull request #1 from hzeller/master

1c51f89

pull upstream

Added V-mapper.

5a10b55

marcmerlin mentioned this pull request Mar 18, 2020

No support for panels stacked up high instead of wide? #1003

Closed

Updated ASCII art for panel connections.

64bf6fa

hzeller reviewed Mar 18, 2020

View reviewed changes

hzeller requested changes Mar 18, 2020

View reviewed changes

lib/pixel-mapper.cc Outdated Show resolved Hide resolved

V-mapper should allow chains of 1, and update ASCII graphic.

775378b

marcmerlin requested a review from hzeller March 18, 2020 15:02

Flipped V-mapper graphics.

118c2e4

hzeller reviewed Mar 18, 2020

View reviewed changes

examples-api-use/README.md Outdated Show resolved Hide resolved

Flip ch1 <-> ch3

b92bfe0

hzeller reviewed Mar 18, 2020

View reviewed changes

Removed debugging info.

eb8fa7f

marcmerlin requested a review from hzeller March 18, 2020 17:14

hzeller merged commit 7032742 into hzeller:master Mar 18, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Vmapper #1009

Vmapper #1009

marcmerlin commented Mar 18, 2020 •

edited

Loading

hzeller commented Mar 18, 2020

hzeller commented Mar 18, 2020

marcmerlin commented Mar 18, 2020 •

edited

Loading

hzeller commented Mar 18, 2020

marcmerlin commented Mar 18, 2020 •

edited

Loading

hzeller Mar 18, 2020

hzeller left a comment

hzeller commented Mar 18, 2020

hzeller commented Mar 18, 2020

marcmerlin commented Mar 18, 2020

hzeller commented Mar 18, 2020

marcmerlin commented Mar 18, 2020 •

edited

Loading

hzeller commented Mar 18, 2020

marcmerlin commented Mar 18, 2020

hzeller Mar 18, 2020

marcmerlin Mar 18, 2020

hzeller Mar 18, 2020

marcmerlin Mar 18, 2020

hzeller commented Mar 18, 2020

hzeller commented Mar 18, 2020

hzeller commented Mar 18, 2020

marcmerlin commented Mar 18, 2020

marcmerlin commented Mar 21, 2020

hzeller commented Mar 21, 2020

marcmerlin commented Mar 21, 2020

rijotech commented Mar 27, 2020

marcmerlin commented Mar 27, 2020 •

edited

Loading

rijotech commented Mar 27, 2020

lehni commented Jan 21, 2022

hzeller commented Jan 21, 2022

marcmerlin commented Jan 21, 2022

lehni commented Jan 22, 2022

Vmapper #1009

Vmapper #1009

Conversation

marcmerlin commented Mar 18, 2020 • edited Loading

hzeller commented Mar 18, 2020

hzeller commented Mar 18, 2020

marcmerlin commented Mar 18, 2020 • edited Loading

hzeller commented Mar 18, 2020

marcmerlin commented Mar 18, 2020 • edited Loading

hzeller Mar 18, 2020

Choose a reason for hiding this comment

hzeller left a comment

Choose a reason for hiding this comment

hzeller commented Mar 18, 2020

hzeller commented Mar 18, 2020

marcmerlin commented Mar 18, 2020

hzeller commented Mar 18, 2020

marcmerlin commented Mar 18, 2020 • edited Loading

hzeller commented Mar 18, 2020

marcmerlin commented Mar 18, 2020

hzeller Mar 18, 2020

Choose a reason for hiding this comment

marcmerlin Mar 18, 2020

Choose a reason for hiding this comment

hzeller Mar 18, 2020

Choose a reason for hiding this comment

marcmerlin Mar 18, 2020

Choose a reason for hiding this comment

hzeller commented Mar 18, 2020

hzeller commented Mar 18, 2020

hzeller commented Mar 18, 2020

marcmerlin commented Mar 18, 2020

marcmerlin commented Mar 21, 2020

hzeller commented Mar 21, 2020

marcmerlin commented Mar 21, 2020

rijotech commented Mar 27, 2020

marcmerlin commented Mar 27, 2020 • edited Loading

rijotech commented Mar 27, 2020

lehni commented Jan 21, 2022

hzeller commented Jan 21, 2022

marcmerlin commented Jan 21, 2022

lehni commented Jan 22, 2022

marcmerlin commented Mar 18, 2020 •

edited

Loading

marcmerlin commented Mar 18, 2020 •

edited

Loading

marcmerlin commented Mar 18, 2020 •

edited

Loading

marcmerlin commented Mar 18, 2020 •

edited

Loading

marcmerlin commented Mar 27, 2020 •

edited

Loading