ABC panels with fm6126A (128x64) require --led-row-addr-type=3

[marcmerlin]

This is starting to get annoying...
I get output on them after sending the fm26126A init sequence, but the output is all wrong given the line addressing having changed again. It seems that you only select one of 8 lines, and push 4 times 128 pixels to reach the other 3 rows after filling the first one.
Why, oh why do "they" have to keep changing how to do things? I got those as replacements for a perfectly working ABCDE panel

[jake653]

Previous discussions of the quirky fm6126A"

#746

There is some code and comments regarding that chip, in this driver
https://github.com/2dom/PxMatrix/blob/master/PxMatrix.h

http://ledpixelart.com/pixelv2board/ declares the FM6126A is not compatible with their setup.

One guy suggests that only init code must be added to solve his FM6126A problem:
"I just ported this file so that it works on my rPi, ran it, and then plugged my Teensy with SmartMatrix code (unmodified), and things just worked.
So this confirms that the only problem is indeed the init necessary with those FM6126A chips"

https://community.pixelmatix.com/t/smartmatrix-doesnt-support-fm6126a-driver-chips/421

[marcmerlin]

@jake653 "One guy suggests that only init code must be added " => that was me :)

Sorry that my message was unclear, the problem is not FM6126A which is solved with the out of band init code (hopefully will get integrated in the lib proper soon), it's the ABC addressing.
@hzeller can you confirm that ABC addressing is not currently supported by your lib (or any other lib I've seen actually)? I've only ever seen AB or ABCD or ABCDE

[mcpgza]

Sorry that my message was unclear, the problem is not FM6126A which is solved with the out of band init code (hopefully will get integrated in the lib proper soon), it's the ABC addressing.

I have ABC addressing panel using ICN2037, and I was not able to make it work.

[hzeller]

If this is an FM61A but only has three address lines, would this probably be working with (the new flag) --led-panel-type=fm6126 and one of the --led-multiplexing options (because outdoor panels do different multiplexing).

[mcpgza]

My 64x128 panel is not fm6126, but ICN2037, and it has only ABC lines:

and this is how the demo with -D 3 looks like:

It is written on the panel: P2-128X64-32S-V4.0, LED1515, 2018/06/16

(I have other panels with HUB75E with ICN2037, and those working fine)

[hzeller]

ABC sounds like a different led multiplexing. Did you try through the available --led-multuplexing options?

[mcpgza]

Yes, I tried them, none of them worked.

This is how demo 0 looks like:

sudo ./demo --led-cols=128 --led-rows=64 --led-slowdown-gpio=5 -D 0

It seems for the half of the panel, it repeats 4 line, and the other half, it repeats another 4 line.

[hzeller]

ABC could also means some different row address type; there are a few implemented, but they don't do three address lines. It might be worthwhile doing some reverse engineering, then implement this.

It looks a bit like the AB row address type but maybe split into top and bottom half ? So I would try with --led-row-addr-type=1 and see if that at least gives some partial usable output. Then we can go from there.

[5onix]

Hello, I might have the same led panel with the same issue.
https://www.aliexpress.com/item/32855350927.html?spm=a2g0s.9042311.0.0.78ba6c37sxIajI
I tried all sorts of combination with the parameters but it will give at best the animation shown above (demo0).

sudo ./demo --led-rows=64 --led-cols=128 --led-slowdown-gpio=3 --led-multiplexing=0 --led-scan-mode=0 --led-row-addr-type=0 led-chain=1 led-parallel=1 -D 0
--> this will give the output with two semi cubes rotating exactly like mcpgza's GIF above.

The same demo with --led-row-addr-type=1 will give nothing but a black screen.

[themultiplexer]

I also have one of these ABC-panels and have the same issue as @5onix, @marcmerlin and @mcpgza.
I'd love to see this awesome library work with my panel. I would like to help but I don't know where to start 😅
Maybe I can help after hearing computer graphics this semester.

[hzeller]

Good starting point is to get hold of a datasheet

[gustavoalara]

Hi,

I have the same case as @mcpgza. I received two days ago two 128x64 led-matrix with the same ABC addresses and same information written on the panel (P2-128X64-32S-V4.0, LED1515, 2018/06/16). I asked the chinese store from Aliexpress where I bought the panel for some schematics or something useful but they said that their have no information about it

[gustavoalara]

Hi again,

According to the adafruit site (https://learn.adafruit.com/32x16-32x32-rgb-led-matrix/new-wiring), the ABC addresses is the pin arrangement used by 32x16 panels

I don't know if this could be useful to someone. Maybe this panel needs a custom internal mapper...

[bk313]

I also have this 128x64 panel with the ICN2037 and the ABC lines. No luck getting it to work, I get the same image as @mcpgza posted above. Would like to help any way I can.

[mcpgza]

It seems it requres a new RowAddressSetter, and I would like to wrtire it, but unfortunately I dont understand how it works, dear @hzeller, can you provide a short descrption how it works, what it does. Thanks.

[gustavoalara]

According to Adafruit for the 32x16 Led matrix,

A is the lowest bit of row address
B is the second lowest bit of row address
C is the highest bit of row address
LE is Latch of row
CLK is Clock
EN is Enable
R1 is Red data 1
R2 is Red data 2
G1 is Green data 1
G2 is Green data 2
B1 is Blue data 1
B2 is Blue data 2
GND is Grounding (and 4 GND must be connected)

I think ours panels is the same pinout but with a 1:32 scan multiplexing... Anyway, I've contacted the manufacturer of my led matrix (Coreman.cc). Let's see if I'm lucky and they answer me with the information I've requested

[gustavoalara]

Hi,

I found this forum with some information that can be useful https://community.pixelmatix.com/t/led-module-p2-128-64-1-32-driver/414

[mcpgza]

I made a huge progress, the panel does not contain inverters, so it use "positive logic", and it seems tha panel has AB type addressing, but B is not used, C used instead.

sudo ./demo --led-cols=128 --led-rows=64 --led-slowdown-gpio=5 --led-row-addr-type=1 -D 0

This is the relevant code:

class ShiftRegisterRowAddressSetter : public RowAddressSetter {
public:
  ShiftRegisterRowAddressSetter(int double_rows, const HardwareMapping &h)
    : double_rows_(double_rows),
      row_mask_(h.a | h.c),
      clock_(h.a),
      data_(h.c),
      last_row_(-1) {
  }
  virtual gpio_bits_t need_bits() const { return row_mask_; }

  virtual void SetRowAddress(GPIO *io, int row) {
    if (row == last_row_) return;
    for (int activate = 0; activate < double_rows_; ++activate) {
      io->SetBits(clock_);
      if (activate == double_rows_ - 1 - row) {
        io->SetBits(data_);
      } else {
        io->ClearBits(data_);
      }
      io->ClearBits(clock_);
    }
    io->SetBits(clock_);
    io->ClearBits(clock_);
    last_row_ = row;
  }

private:
  const int double_rows_;
  const gpio_bits_t row_mask_;
  const gpio_bits_t clock_;
  const gpio_bits_t data_;
  int last_row_;
};

The only problem is a missing line at the end of one part.

[bk313]

Great work @mcpgza !

[hzeller]

Thanks @mcpgza ! I have added your code to the master branch now and it can be selected with --led-row-addr-type=3 so that it is easy to try for everyone.

This then allows others who also have the panel to help figure out the remaining issue with the missing line.

[gustavoalara]

Hi guys,

I'm trying the new option for our 128x64 ABC modules. Apart of the black line, I see two things:

1. some LEDs with incorrect colours near the right and left laterals
2. If I try to connect 2 128x64 modules in chain, the modules don't show anything and the application freezes

I'll upload some images of these things

[gustavoalara]

Forget the second issue... I incremented the nanoseconds from 300 to 450 and now the chain works fine. Only the of issues with some LEDs:

[5onix]

For your 1st problem, have you tried the demo #4 - Pulsing color or #11 - Brightness pulse generator ?
Those demos made me realize that my panel had a few bad subpixels on the edges.
The edges are kinda fragile. I had to remove a few leds which weren't working anymore ; due to some accidental bumps they were falling apart.

[gustavoalara]

Hi @5onix I've tried with demos and images (as you can see in my previous message) and the result is the bad subpixels on the edges. My second matrix module is failing and the low quarter of the module has no light (I thing something has broken)

Following a picture of the two modules working together, (the left one is the broken module). I have 3 LEDs broken too (in the right corner of the right module)

[5onix]

Too bad that one of your module has an issue. But overall the result looks very promising.
Here's 2 photos of mine which show broken and malfunctioning pixels.

The broken pixels are surrounded in blue, the bad ones are in pink.

[marcmerlin]

speaking of P2 panels and pixels that fall off, have you found some kind of glue spray that you can layer on top of them to glue them all in place so that they don't get lost? (and without affecting display quality and/or the space between panels if you put them adjacent to one another)

[gustavoalara]

Good point @marcmerlin, this panels look very fragile and is very easy to lost pixels. (I found 2 of the pixels, but I don't know how to glue them to the panel again)
In the other hand, I'm arguing with the seller because I think the panel arrived broken

[arash1221]

@mcpgza thanks for the answer, can you please guide me how to control any pixel of led panel,
very simple code.

[hzeller]

@arash1221 Please don't hijack an existing issue with an unrelated problem; open a new issue.

To your problem: try to gpio slowdown your output (--led-slowdown-gpio) depending on the internal wiring you're increasing the load on the gpio pins, which will make them switch slower.

Also, you really want a level shifter, as not only will be the digital voltage correct (and right now you're just essentially playing jeopardy if it might work), but also, you can't really drive long lines with the GPIO pins directly.

[arash1221]

Thanks @hzeller I recall it.

[xsrf]

Thanks @mcpgza . I'll probably pay a bit more for pristine panels, I don't want missing pixels for my setup :)
#985 explains why ABC is slower than ABCDE. In a nutshell, ABC panels are ABCDE panels with 2 address lines missing, so it takes longer to send the 5 bits of addresses over 3 bits.
you can benchmark this yourself with
~/rpi-rgb-led-matrix/examples-api-use/demo --led-rows=64 --led-cols=128 --led-chain=1 --led-show-refresh --led-parallel=3 --led-pwm-dither-bits=1 --led-pwm-bits=7 --led-panel-type=FM6126A --led-row-addr-type=0 -D0 and then use led-row-addr-type=3
You can do the speed test even without the right panels and look at the Hz value you get.

Hey, I've seen your discussion about ABC being slower than ABCDE. This is because the code is not using the Shift-Register that is connected to the row selection as it is meant to be used (I guess).

To select one out of N rows, you are shifting out N-1 zeroes and one one out to the display. Of course this needs more than N clock cycles which is way longer on 1/16 or even 1/32 panels than just setting 5 GPIOs at once.

However: This is actually not necessary if you scan your rows incrementally, which is usually what is done. In this case you actually do only have to shift out one bit for every cycle. You shift out 1 for row 0 and 0 otherwise.

Here is the code I contributed to PxMatrix few days ago:
https://github.com/2dom/PxMatrix/blob/178054b3021892cb9185c3a92051ba2b2afc8977/PxMatrix.h#L1012

If you don't require random row access, it boils down to:

      // Just shift the row mux by one for incremental access
      digitalWrite(_C_PIN, (value==0) ); // Shift out 1 for line 0, 0 otherwise
      digitalWrite(_A_PIN, HIGH); // Clock out this bit
      digitalWrite(_A_PIN, LOW);

Hope this may also help you :)

[hzeller]

Nice, thanks xsrf

[hzeller]

Nice, thanks @xsrf .
Could someone who has such a panel (I Ithink I don't have any if these in mystash) implement and test that in the rpi-rgb-led-matrix library and send me a pull request (e.g. @marcmerlin :)
I could implement it blindly, but it is better with a board to test that it actually works :)

[mcpgza]

@hzeller please implement it, i will test and fix it if necessary. I dont know how to translate that code to your library api.

[marcmerlin]

So, I do have ABC panels somewhere in my garage, but I'm not using them, as my main array is ABCDE, so honestly my enticement to spend time on them for a small improvement that i won't see because I don't use them, is kind of limited :)
That said, I'm happy to confrim that new code works on them if that helps.

[javiervalero31]

Hi. I read your comments to try to solve my problem but could not solve it.
I have 4 LED arrays with 32x16 size.
I want the image or Demos to be centered in my panels but I have not been able to configure the parameters to achieve this.

Each matrixs connected in a only matrix of 64x32 size...

The closest thing to what I want (DEMO 0)....

Any idea?

[marcmerlin]

I believe those panels are not ABC, so this is not the place to ask for him on those panels.
Unfortunately there isn't a support group yet for this library, @hzeller was consideirng options, otherwise for now try to file a new issue with all the details on your panels, how they are wired, what command line options you used to run the demo, etc.

[marcmerlin]

@javiervalero31 actually there is a support group now, I just created one :)
https://rpi-rgb-led-matrix.discourse.group/

[Sl-Alex]

@xsrf I implemented it in my code and after that I found your message.

Here is the code I contributed to PxMatrix few days ago: https://github.com/2dom/PxMatrix/blob/178054b3021892cb9185c3a92051ba2b2afc8977/PxMatrix.h#L1012

If you don't require random row access, it boils down to:

      // Just shift the row mux by one for incremental access
      digitalWrite(_C_PIN, (value==0) ); // Shift out 1 for line 0, 0 otherwise
      digitalWrite(_A_PIN, HIGH); // Clock out this bit
      digitalWrite(_A_PIN, LOW);

Hope this may also help you :)

If you implement it like this then it also fixes the problem with the black line in the middle of the module (which was reported many times in this issue).
I also have the panel with ABC row addressing and I found something interesting today. Just look at ICND2019 datasheet. The control sequence is exactly the same as you proposed. Also it seems that B line could be used in order to configure some extended register (haven't tried it yet). Here is a line from the datasheet:
For control card, SDI is the C of 3-8 decoder, DCK is the A of 3-8 decoder, RCK is the B of 3-8 decoder

[marcmerlin]

this has been fixed for a while, closing

[marcmerlin]

@mcpgza @Sl-Alex @xsrf @javiervalero31 , since apparently these ABC panels still exist and are still being shipped, could someone re-confirm my understanding to make sure I'm correct:
Is there any advantage to these panels whatsoever (maybe brighter?) or they are really just the same as ABCDE but with slower addressing to save a few pins and maybe a few cents of construction?

[rowanG077]

The big advantage is you can support an arbitrary amount of rows. with ABCDE you are limited to 32 rows. Although it is slower it's not like it's a lot. A single cycle extra every row you are clocking out.

[marcmerlin]

@rowanG077 let me rephrase to make sure I understand.
You are saying with ABC you can support let's say 128 rows instead of 64 rows, but if you do, now you are refreshing one row out of 64 instead of one row out of 32, so the refresh bar problem is going to be even worse unless you can push updates at very high speed.
So if we're back at 64 rows in 1/32 updates, is ABC better in any way than ABCDE outside of saving 2 GPIOs on the rPi?

[rowanG077]

with a good FPGA implementation 128 rows wouldn't really be a problem. Some LED panel usage requires only 1-bit depth for simple signage applications. There you could even imagine 256 rows or 512 rows.

Personally I think a uniform interface is much better then just add a pin everytime. It makes connectors and clients much more expensive. But besides that there is no advantage I'm aware of,

[marcmerlin]

Thanks @rowanG077 that's a reasonable answer, In my easier tests ABC seemed slower for ABCDE, but maybe it was just the current implementation. Your point that ABC allows adding even more rows without adding more pins, is indeed valid.

[JavierSNZ]

This issue is a duplicate of #1025

[marcmerlin]

I just bought from P1.875 flex panels, they are quite nice outside of the lack of output port (so you you can only put one panel per chain):

They are indeed ABC panels which is not ideal, but they work with
--led-row-addr-type=3
however, they also needed --led-slowdown-gpio=4 for the display not to be garbled, and that was on a rPi0 2w which is equivalent in speed to an rPi3, so with an rPi4, they may need an even higher lowdown

[marcmerlin]

I forgot to give the link for the rpi0 2w vs rpi3 speed tests: https://rpi-rgb-led-matrix.discourse.group/t/rpi0-2w-speed-compared-to-rpi3a/913 (basically they are just as fast)