hzeller / rpi-rgb-led-matrix

Controlling up to three chains of 64x64, 32x32, 16x32 or similar RGB LED displays using Raspberry Pi GPIO
GNU General Public License v2.0
3.67k stars 1.17k forks source link

Pins to solder for using with DADAFRUIT_RGBMATRIX_HAT_PWM? #74

Closed danielvy closed 8 years ago

danielvy commented 9 years ago

Sorry if this is the wrong place to ask questions but I saw that other questions were opened here as issues.

I am new to RPI, got the 64x32 matrix from Adafruit with the RGB Matrix HAT. Managed to make it work with the Adafruit version of the library. The performance seems to be a lacking (flickering, artifacts) so I thought to try this library, it seems well maintained and more optimized.

I noticed there are flags in the make file for this lib to work with the Adafruit HAT, I want to try the DADAFRUIT_RGBMATRIX_HAT_PWM as suggested but I want to make sure which pins I need to solder so I don't ruin anything and I was not able to find more detailed instructions.

Attaching an image of the HAT, I marked the places I think I need to solder, are these the correct pins to connect?

Thanks!

adafruit hat

hzeller commented 9 years ago

I don't have the HAT myself, but adding @flowztul to this thread who tested this and contributed the define in the Makefile.

hzeller commented 9 years ago

(but it looks right to me)

danielvy commented 9 years ago

Great, I will wait for his response then. Thanks.

Also, I am currently testing without DADAFRUIT_RGBMATRIX_HAT_PWM on RPI 2 and I see some noticeable artifacts. Is this something that is expected to improve once I solder these pins and enable PWM?

hzeller commented 9 years ago

The PWM will make flicker and brightness glitches in single lines go away almost entirely (if the Pi is heavily loaded, you still might see brightness variations).

If you see artifacts, such as areas of pixels not showing up properly or erratically, then this might be due to too high IO speed of the Pi2 (compared to what the panel can handle) and you might want to try the RGB_SLOWDOWN_GPIO define.

danielvy commented 9 years ago

I will try that.

Thanks for the quick response and the great work on the library!

flowztul commented 9 years ago

Yes those are the pins that I connected to use PWM with the Adafruit HAT.

hzeller commented 9 years ago

Thanks Lutz! I should probably order an Adafruit HAT to test their hardware that they derived from my project to document things properly.

danielvy commented 9 years ago

Soldered the pin and compiled the library with DADAFRUIT_RGBMATRIX_HAT_PWM, the flickering seems to be mostly gone but I still see some artifacts (leds that are lit where they are not supposed to).

These are clearly visible when displaying text or running demo #6.

Here is an example (hopefully it is clear from the image, there is a halo from the bright leds but you can see the more dimmed ones at the bottom and around the text):

led matrix artifacts

And demo #6:

led matrix artifacts 2

I tried using RGB_SLOWDOWN_GPIO=1 (or even 2 and higher values) but it doesn't seem to make any noticeable visual difference.

The cable running from the HAT to the matrix is about 15cm (5.9") long .

Refresh rate when displaying text is reported as ~460Hz and with demo #6 ~220Hz with RGB_SLOWDOWN_GPIO=1

Anything else I can try to get rid of these artifacts?

hzeller commented 9 years ago

I have seen these kind of artifacts on some panels, in particular with very constrasty things, and I think it is a hardware problem on the panels that we can't work around in software. Next step would actually be measuring on the panel to see why it does what it does to see if there is a hardware fix. but I haven't done that yet.

It is not the software or data transmission - the pixels you see are never transmitted.

What I would try though is to see if stabilizing the power supply (with some low-ESR caps close to the power input of the panel) helps.

hzeller commented 8 years ago

(Closing now: the original issue (what pins to connect) is successfully resolved, the other tangent issue is a hardware problem we can't do anything about)