64x32 RGB LED Matrix Adafruit RGB Matrix HAT + RTC

[blakebr]

Mike,

Got your image and burned it to one of my 32GB SD cards.

Most Python3 programs run without glitch on the screen using:

Code: Select all

sudo python3 graphics.py --led-cols=64 --led-slowdown-gpio=4

pulsing-colors.py and grayscale-block.py still exhibit tearing/static in the image. I believe it's because they are more computationally intensive.

Bruce

[mikeysklar]

I just ran both examples without any tearing. They were smooth and consistent in patterns / timing.

pulsing-colors.py && grayscale-block.py

This might not be a big deal, but at this point I should mention it. I do have a heat sink on my main processor on my Pi3B+.

IMG_2023-5-17-172016.jpeg (195.22 KiB) Viewed 272 times

[blakebr]

Mike,

Got a heat sink too and that blurry thing is a 0.1 ohm resistor between the HAT and 32x64 panel. That way I can tell the display Amp load. Never more than 1.5 amps from a 3 Amp power supply. The RPi 3B+ draws less than an amp. Power goes to the HAT before the display and RPi 3B+.

Bruce

[mikeysklar]

A few things thing come to mind that could be worth comparing between our setups. Let me know if you would like to pursue these.

1. EEPROM settings and version
2. chipsets on panel
3. cpu usage while running pulsing-colors.py || grayscale-block.py

[blakebr]

Mike,

I am willing to try anything. (Le`gal`ity optional. ;-) [banned word]

#1 I am intrigued. What EEPROM? Where is it? What does it do?
#2 Can do easy! What chips? Where are they located?
#3 The image you sent me was run without modification. It connected via Cat 5e Ethernet, WiFi was not configured or connected. RPi >> Switches >> My boundary router >> FIOS router >> FIOS OINT >> Fiber

I believe pishrink.sh requires I run it on a full-up Linux PC. I don't have one. Sounds like a very handy piece of code.

Bruce

[mikeysklar]

There Raspberry Pi does have a firmware. You can see the version you are running and opt to update when prompted by running:

Code: Select all

sudo rpi-update

I had been running v5.10.103-v7 and just updated this morning to rpi-6.1.y

On the back of the RGB Matrix there are three types chips U* (RGB), T* (decoding) and two unlabeled that look like buffers.

My panel model should match yours: P4-2121-64*32-16S-HL1

U*: Chipone ICN2037BP D0442BNA
T* : DP32019A 2B2802
Buffers: 74HC245KA NDC429000J8

I ran pishrink on my Ubuntu laptop.

I doubt this is an issue, but a difference between our setups is that I'm using WiFi and you are on a hard wire ethernet connection.

I do think it would be worth running top as you run the demos to see how much CPU % they take and maybe some other resource that is getting burned up.

[blakebr]

Mike,

OS and applications totally up-to-date.

Code: Select all

pi@raspberrypi-LED-Clock:~ $ sudo rpi-update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** Performing self-update
 *** Relaunching after update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
FW_REV:38d69e35292e129700ef50443c3ecc37e4124d91
 *** Your firmware is already up to date (delete /boot/.firmware_revision to force an update anyway)
pi@raspberrypi-LED-Clock:~ $

Yup, P4-2121-64*32-16S-HL1 (S/N? 2303BP40079-700) (MIL-PN 04N008P2E688B1-(HL))
Chips match.

Code: Select all

pi@raspberrypi-LED-Clock:~/rpi-rgb-led-matrix/bindings/python/samples $ nohup sudo ./pulsing-colors.py --led-slowdown-gpio=4 --led-rows=32 --led-cols=64 --led-gpio-mapping=adafruit-hat-pwm --led-brightness=50 --led-pwm-bits=11 --led-pixel-mapper="rotate:180" &
[1] 1310
pi@raspberrypi-LED-Clock:~/rpi-rgb-led-matrix/bindings/python/samples $ nohup: ignoring input and appending output to 'nohup.out'

pi@raspberrypi-LED-Clock:~/rpi-rgb-led-matrix/bindings/python/samples $ uptime
 13:24:52 up 6 min,  3 users,  load average: 0.57, 0.71, 0.43
pi@raspberrypi-LED-Clock:~/rpi-rgb-led-matrix/bindings/python/samples $ uptime
 13:24:59 up 6 min,  3 users,  load average: 0.60, 0.72, 0.44
pi@raspberrypi-LED-Clock:~/rpi-rgb-led-matrix/bindings/python/samples $ sudo kill 1310
[1]+  Terminated              nohup sudo ./pulsing-colors.py --led-slowdown-gpio=4 --led-rows=32 --led-cols=64 --led-gpio-mapping=adafruit-hat-pwm --led-brightness=50 --led-pwm-bits=11 --led-pixel-mapper="rotate:180"
pi@raspberrypi-LED-Clock:~/rpi-rgb-led-matrix/bindings/python/samples $ nohup sudo ./grayscale-block.py --led-slowdown-gpio=4 --led-rows=32 --led-cols=64 --led-gpio-mapping=adafruit-hat-pwm --led-brightness=50 --led-pwm-bits=11 --led-pixel-mapper="rotate:180" &
[1] 1325
pi@raspberrypi-LED-Clock:~/rpi-rgb-led-matrix/bindings/python/samples $ nohup: ignoring input and appending output to 'nohup.out'

pi@raspberrypi-LED-Clock:~/rpi-rgb-led-matrix/bindings/python/samples $ uptime
 13:26:36 up 8 min,  3 users,  load average: 0.49, 0.64, 0.44
pi@raspberrypi-LED-Clock:~/rpi-rgb-led-matrix/bindings/python/samples $ sudo kill 1325
pi@raspberrypi-LED-Clock:~/rpi-rgb-led-matrix/bindings/python/samples $ nohup sudo ./my-clock.py --led-slowdown-gpio=4 --led-rows=32 --led-cols=64 --led-gpio-mapping=adafruit-hat-pwm --led-brightness=50 --led-pwm-bits=11 --led-pixel-mapper="rotate:180" &
[2] 1331
[1]   Terminated              nohup sudo ./grayscale-block.py --led-slowdown-gpio=4 --led-rows=32 --led-cols=64 --led-gpio-mapping=adafruit-hat-pwm --led-brightness=50 --led-pwm-bits=11 --led-pixel-mapper="rotate:180"
pi@raspberrypi-LED-Clock:~/rpi-rgb-led-matrix/bindings/python/samples $ nohup: ignoring input and appending output to 'nohup.out'

[2]+  Exit 1                  nohup sudo ./my-clock.py --led-slowdown-gpio=4 --led-rows=32 --led-cols=64 --led-gpio-mapping=adafruit-hat-pwm --led-brightness=50 --led-pwm-bits=11 --led-pixel-mapper="rotate:180"
pi@raspberrypi-LED-Clock:~/rpi-rgb-led-matrix/bindings/python/samples $ nohup sudo ./my-clock.py --led-slowdown-gpio=4 --led-rows=32 --led-cols=64 --led-gpio-mapping=adafruit-hat-pwm --led-brightness=50 --led-pwm-bits=11 --led-pixel-mapper="rotate:180" &

All usage times are about 0.50. Should not be an issue, but...

Bruce

[blakebr]

Mike,

I forced an OS update and ran my update.sh script.

Code: Select all

root@raspberrypi-LED-Clock:~# bash update.sh

*** apt-get update

Hit:1 http://raspbian.raspberrypi.org/raspbian bullseye InRelease
Hit:2 http://archive.raspberrypi.org/debian bullseye InRelease
Reading package lists... Done

*** apt-get upgrade

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

*** apt-get dist-upgrade

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

***apt autoremove

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

*** rpi-update

 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** Performing self-update
 *** Relaunching after update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
FW_REV:38d69e35292e129700ef50443c3ecc37e4124d91
 *** We're running for the first time
 *** Backing up files (this will take a few minutes)
 *** Remove old firmware backup
 *** Backing up firmware
 *** Backing up modules 6.1.28-v7+
WANT_32BIT:1 WANT_64BIT:1 WANT_PI4:1
#############################################################
WARNING: This update bumps to rpi-6.1.y linux tree
See: https://forums.raspberrypi.com/viewtopic.php?t=344246

'rpi-update' should only be used if there is a specific
reason to do so - for example, a request by a Raspberry Pi
engineer or if you want to help the testing effort
and are comfortable with restoring if there are regressions.

DO NOT use 'rpi-update' as part of a regular update process.
##############################################################
Would you like to proceed? (y/N)
 *** Downloading specific firmware revision (this will take a few minutes)
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:00:05 --:--:--     0
100  116M  100  116M    0     0  1546k      0  0:01:16  0:01:16 --:--:-- 4060k
 *** Updating firmware
 *** Updating kernel modules
 *** depmod 6.1.28-v7l+
 *** depmod 6.1.28+
 *** depmod 6.1.28-v8+
 *** depmod 6.1.28-v7+
 *** Updating VideoCore libraries
 *** Using HardFP libraries
 *** Updating SDK
 *** Running ldconfig
 *** Storing current firmware revision
 *** Deleting downloaded files
 *** Syncing changes to disk
 *** If no errors appeared, your firmware was successfully updated to 38d69e35292e129700ef50443c3ecc37e4124d91
 *** A reboot is needed to activate the new firmware

*** update finished, reboot

Bruce

[mikeysklar]

Same tearing effect?

What would you like to do from here? I think we are running out of options.

[blakebr]

Mike,

I see three options.

1) Until I or someone else has a project that this issue impacts, put it on a back burner.

2) Swap out the HAT and/or the display and see what happens. I do not have a near term or far term need for two 64x32 Matrix systems, so I can't see spending $80 to isolate the issue. It also may devolve into a good money after bad.

3) Wait and see what happens with my project as its complexity increases. If my project is impacted, get back with you. This is kinda like 1) but me centric.

I got these parts partly to learn/play and because of thread Adafruit RGB Matrix Hat for Raspberry Pi, which you were involved in. I have wanted an RGB matrix for a while but didn't have a project. The other thread gave me the excuse I needed.

I may have an unrealistic expectation for the 63x32 Matrix/HAT/RPi marriage be able to provide a rock solid display.

A few questions:
How does it all work? Does the RPi send the HAT a static screen then go off and do other things, or does the RPi have to actively tell the HAT what to do for each scan.

Does the HAT send the MATRIX a static screen then go off and do other things, or does the HAT have to actively tell the MATRIX what to do for each scan.

Is the python3 library managing things in the background during a time.sleep()?

I ask because of the tearing I saw in a static screen while Python3 was just sitting there in a time.sleep() loop.

Bruce

[blakebr]

Mike,

Is this device compatible with my display? It may be a better fit to my final project, and free up my RPi 3B+.

Adafruit Matrix Portal - CircuitPython Powered Internet Display, Product ID: 4745.

Bruce

[mikeysklar]

Yes, you can use the MatrixPortal with your display. It is an elegant way to drive these. There is also an easy to troubleshoot with "simpletest.uf2" image for the MatrixPortal.

It might make sense for you to purchase a MatrixPortal and if it fails simplest then we can swap the panel for you.

FYI, I do currently have an open thread with a pair of 64x32 panels not passing simpletest so nothing comes easy.

Another option to consider would be the Pi Bonnet which comes with no soldering requirement (besides possible jumper settings) and requires less obscure flags.

If you want to swap out or return the RGB LED panel or HAT I can approve those for you.

Good question about how the panels work. There is a guide that describes this to some degree. The takeaway is that the entire matrix is being PWM'd and takes a > 50 MHz processor to do it. The HAT/Bonnet is making a simplified connector for the HUB-75 panel interface.

[blakebr]

Mike,

I read Phillip Burgess's description on how the matrix works. It was a good start, but didn't answer all my questions. Re-reading the HAT documentation after reading the article and chasing down what RPi pins go where, I got the answer to one of my questions. The HAT does not do the scanning, the RPi 3B+ does using 13+ GPIO pins. The Raspberry Pi 3B+ is continuously driving the Matrix. The HAT does power routing, level shifting and possibly some minor logic.

I had noticed before but not taken into account that the my_clock.py I had put in rc.local to run at boot would flicker for 15 or so seconds at start. It would then settle down to a stable clock display. Those 15 seconds were when the RPi was finishing its boot process. So I now believe the issue resides in an overworked RPi. Any display less that 64x32 does not tax the RPI enough to be an issue.

Because I could, I tried an 8 Amp industrial grade power supply with no change in symptoms.

I will probably not try the MatrixPortal because then I would have the HAT with nothing for it to do.

I think we are done here. Good luck with the other threads.

Bruce

rc.local:

Code: Select all

/usr/bin/python3 /home/pi/rpi-rgb-led-matrix/bindings/python/samples/my_clock.py --led-slowdown-gpio=4 --led-rows=32 --led-cols=64 --led-gpio-mapping=adafruit-hat-pwm --led-brightness=50 --led-pwm-bits=11 --led-pixel-mapper="rotate:180" &

my_clock.py

Code: Select all

#!/usr/bin/env python3
from   samplebase import SampleBase
from   rgbmatrix  import graphics
import time

DoW = ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday", "Beerday"]
Date_old = ""
Time_old = ""
Misc_old = ""
Day_old  = ""
'''
  94333 Dec  2  2021 4x6.bdf
 194747 Dec  2  2021 5x7.bdf
 154919 Dec  2  2021 5x8.bdf
 211073 Dec  2  2021 6x10.bdf
 549703 Dec  2  2021 6x12.bdf
 159441 Dec  2  2021 6x13B.bdf
 512118 Dec  2  2021 6x13.bdf
  95801 Dec  2  2021 6x13O.bdf
 144785 Dec  2  2021 6x9.bdf
 124748 Dec  2  2021 7x13B.bdf
 400761 Dec  2  2021 7x13.bdf
 103390 Dec  2  2021 7x13O.bdf
 128518 Dec  2  2021 7x14B.bdf
 327838 Dec  2  2021 7x14.bdf
 141768 Dec  2  2021 8x13B.bdf
 459959 Dec  2  2021 8x13.bdf
 160613 Dec  2  2021 8x13O.bdf
 270622 Dec  2  2021 9x15B.bdf
 765675 Dec  2  2021 9x15.bdf
 133756 Dec  2  2021 9x18B.bdf
 835008 Dec  2  2021 9x18.bdf
 974681 Dec  2  2021 10x20.bdf
   2405 Dec  2  2021 AUTHORS
 145955 Dec  2  2021 clR6x12.bdf    # 5x8
 234648 Dec  2  2021 helvR12.bdf    # 5x9
  15259 Dec  2  2021 README
   2472 Dec  2  2021 README.md
 221573 Dec  2  2021 texgyre-27.bdf # 14x20
  19964 Dec  2  2021 tom-thumb.bdf  # 3x5
'''
L = 8
##########################################################################
class GraphicsTest(SampleBase):
##########################################################################
    def __init__(self, *args, **kwargs):
        super(GraphicsTest, self).__init__(*args, **kwargs)

##########################################################################
    def run(self):
      global Date_old, Time_old, Day_old, Misc_old
      while True:
        canvas = self.matrix
        font = graphics.Font()
        if L == 8: font.LoadFont("/home/pi/rpi-rgb-led-matrix/fonts/tom-thumb.bdf")
        if L == 6: font.LoadFont("/home/pi/rpi-rgb-led-matrix/fonts/5x7.bdf")
        if L == 5: font.LoadFont("/home/pi/rpi-rgb-led-matrix/fonts/6x10.bdf")
        if L == 4: font.LoadFont("/home/pi/rpi-rgb-led-matrix/fonts/8x13.bdf")

        red     = graphics.Color(255, 0, 0)
        green   = graphics.Color(0, 255, 0)
        blue    = graphics.Color(0, 0, 255)
        cyan    = graphics.Color(0, 255, 255)
        magenta = graphics.Color(255, 0, 255)
        yellow  = graphics.Color(255, 255, 0)
        black   = graphics.Color(0, 0, 0)
        white   = graphics.Color(255, 255, 255)

        t = time.localtime()
        print (t,end='   \r')
        year = t.tm_year
        mon  = t.tm_mon
        mday = t.tm_mday
        hour = t.tm_hour
        min  = t.tm_min
        sec  = t.tm_sec
        wday = t.tm_wday
        yday = t.tm_yday
        dst  = t.tm_isdst

        s1 = str(year)
        s2 = str(mon)
        s3 = str(mday)
        if len(s2) == 1: s2 = "0"+s2
        if len(s3) == 1: s3 = "0"+s3
        Date = (s1+'/'+s2+'/'+s3)
        if L == 4: s1 = s1[2:]; Date = (s2+'/'+s3+'/'+s1)

        s1 = str(hour)
        s2 = str(min)
        s3 = str(sec)
        if len(s1) == 1: s1 = "0"+s1
        if len(s2) == 1: s2 = "0"+s2
        if len(s3) == 1: s3 = "0"+s3
        Time = (s1+':'+s2+':'+s3)
        Day  = (DoW[wday])
        Misc = ('DoY:'+str(yday)+',DST:'+str(dst))

        if L == 8: M = 5; Q = 1
        if L == 6: M = 6; Q = 1
        if L == 5: M = 8; Q = 0
        if L == 4: M = 10; Q = 1
        graphics.DrawText(canvas, font, 0, 1*M,   black,  Date_old)
        graphics.DrawText(canvas, font, 0, 1*M,   yellow, Date)
        graphics.DrawText(canvas, font, 0, 2*M,   black,  Time_old)
        graphics.DrawText(canvas, font, 0, 2*M,   cyan,   Time)
        graphics.DrawText(canvas, font, 0, 3*M,   black,  Day_old)
        graphics.DrawText(canvas, font, 0, 3*M,   magenta,Day)
        graphics.DrawText(canvas, font, 0, 4*M+Q, black,  Misc_old)
        graphics.DrawText(canvas, font, 0, 4*M+Q, green,  Misc)
        graphics.DrawText(canvas, font, 0, 5*M+2*Q, black,   "01234567890123456789")
        graphics.DrawText(canvas, font, 0, 5*M+2*Q, blue,    "01234567890123456789")
        graphics.DrawText(canvas, font, 0, 6*M+2*Q, red,     "ABCDEFGHIJKLMNOPQRSTUVWXYZ")

        Date_old, Time_old, Day_old, Misc_old =  Date, Time, Day, Misc

        while t == time.localtime(): time.sleep(0.01)

##########################################################################
if __name__ == "__main__":
    my_test = GraphicsTest()
    if (not my_test.process()):
        graphics_test.print_help()

[mikeysklar]

Bruce,

Thank you for your persistence once again. I certainly learned some new tricks even if we did not get to root cause.

[blakebr]

Mike,

I think we did. The RPi 3B+ has to handle all the multiplexing lines along with the data that must be sent to the matrix display. With a 64x32 display it is at the edge of what the 3B+ can handle. The user code.py hands off its workload to SampleBase.py for the drudge work. (flickering while in time.sleep(20) explained) With all the LEDs lit up SampleBase.py has its hands full and any higher priority task causes SampleBase.py to miss something now and then. If a fraction of the LEDs are lit at any brightness SampleBase.py can keep up. No need to Mux OFF LEDs.

The question/answer that will have to wait until the RPi 4 becomes available is "Will the RPi 4 keep up?"

I too enjoyed working on this issue with you. Your persistence and experience are appreciated.

Bruce