Update: status of in joint investigation with @"Roy Eltham":
We found that the panels showing the text doubling and overlap are using a different (and lately less common) addressing scheme.
To explain I have to introduce a topic briefly. (if you are not interested in how we send data to these panels, you can skip this post, just know that we've identified the problem.)
In Detail:
When buying panels you'll see that 1/16 scan and 1/32 scan panels are more common lately and use ABCD and ABCDE addressing respectively. When looking at these panels one sees that there are 2x more rows than addresses (e.g., 1/16 scan has 32 rows, while 1/32 scan has 64 rows, etc.)
For this to work, we emit RGB1 values simultaneously with RGB2 values effectively sending 2 pixels of data in a single clock. For 1/16 scan we are sending pixels for rows 0 and 16, 1 and 17, 2 and 18, etc. at the same time. We paint the top half rows 0-15 simultaneously with the bottom half rows 16-31 (or 0-31 with 32-63.)
The ⅛ scan panels, in this specific case, 64x32 are a different animal in that we now have 32 rows and only addresses 0-7 (ABC, only, addressing.) HUB75 limits us to still sending only RGB1 and RGB2 values at the same time. So a ⅛. scan 16-row panel works in our current scheme but a ⅛ scan 32-row panel doesn't.
This will cause a different pixel ordering on the serial stream and sending 4 pixels for each address but I'm not yet finding good examples for how this stream has to look. A visual example of this painting of 4 lines at a time can be seen in this Sparkfun post (scroll down to the black/red animated images.)
I do want to address ⅛ scan panels in the driver, but after discussion with Roy, we decided that I will first clean up 64x64 single panel display timing, and get the multi-panel display working before I try to add code to handle the ⅛ scan panels.
I've attached the specification for the HUB75 panel we'll be stocking.
"Excellent" choice Ken, as the ICN2037 driver chip for the 64x64 1/32 scan panel quoted in the .pdf is already supported by this driver and is the same panel a @Twyyx had sent to me to use during awakening of this support!
In HP parlance, an "Excellent question" is one for which we already had an answer ;-)
Based on the number of chips on this 64x32 1/8th scan panel, I think it's arranged as if it were two panels chained together. So it's very likely that once you get multi panel working, that it may just allow these to work, however, I suspect the arrangement of the 2 panels worth of stuff on these might be interleaved instead of a top/bot or left/right type of thing.
Latest Progress
- Multi-panel now works in development code (not yet released, sitting on develop/ branch in repo)
- I have a better understanding of what's needed for our ⅛ scan panels (just a bit more code... ;-)
-- To the user of a 64x32 ⅛ Scan panel it appears as 64x32 pixels (internally the driver treats it as a 128x16 panel, just fun!)
-- Oh, also they draw 8A @5v at full-on for each 64x32 panel.
Latest Issues I'm chasing
- I'm having difficulty with my most-performant panels (FM6126A-based) as these need custom init code at power-on. I can init a single panel. Multiple panels don't init correctly.
-- The related chips are FM6126A, FM6126Q (w/2 init registers), and FM6127 (w/3 init registers). The Chinese datasheets don't cover the needed initialization serial chains. Lots of RPi and Arduino users refer to a working snippet of code... which also works for me when ported for single panels but not for multiple panels. Unless I find more online references I may be down to stepping thru likely bit patterns until I hit one that works.... (mumble...mumble...)
-- FYI: (links to the various posts about this init stuff.) which are also in my code.
I use to save the meetings chat sessions very often, but sometimes, my 4G connection simply drops, closing the Zoom session, and I feel like a lost soul, in a swampy vacuum...
Also thank you for the heads-up, about the evolution of the project.
Multi-panel is working (still on the Repo develop/ branch)
The 64x64 panel appears to have RED / BLUE swapped. so the driver now has a configuration option to do this swap.
Latest Efforts
I've dropped the multi-panel configuration effort for now. Status at drop: While I have good probing into what's happening (1st panel in the chain is NOT forwarding the RGB12 signals to the remaining panels), I've not yet found a solution...
I'm working on adding the ⅛ scan support. This is also challenging in that, so far, the bitstreams I'm trying are not working but I'm continuing to experiment. If I don't find some solution soon this will likely turn into signal tracing on the panel with a meter, essentially reverse-engineering the schematic to figure out what the pixel stream needs to be.
Meanwhile, For your entertainment (twin 64x64 panels working as a single display and some fun animation):
I've posted v0.2.0 of the LED Matrix driver (See Releases page) and released it to the P2 Obex.
Driver rebuilt to work with a maximum display width of 1024 pixels.
Driver now works with the new 64x64 panels using ICN 2037 Chips
Driver now works with a display of 128x64 using twin 64x64 panels in series.
Driver now supports 1/8 scan panels (P4-1921-8S-V2.0) using the MBI 5124 driver chips
Known Issues
Multi-panel support for the FM6126A and MBI5124 driver chips is not yet working!
Up Next:
While I'm waiting for 64x64 panels I'll continue working on the multi-panel support for the FM6126A and MBI 5124 panels (after a short diversion to work on our P2 vscode support.)
I found some time to test with a 64x64 P2 panel, works great Stephen. Thanks for all your hard work on this driver
I also have a 32x32 P6 panel that has DP5220 driver ICs, and (i think) ABCD driving, but thats just going by the silkscreen. I've tried the various inbuilt ICs without luck, but will revisit this one later
@Tubular said:
I found some time to test with a 64x64 P2 panel, works great Stephen. Thanks for all your hard work on this driver
I also have a 32x32 P6 panel that has DP5220 driver ICs, and (i think) ABCD driving, but thats just going by the silkscreen. I've tried the various inbuilt ICs without luck, but will revisit this one later
Thank you!
Now that you've been through making it work, is there anything I should address in the instructions to make it easier to use/understand?
Also, when you want to take the time, re the 32x32 board: there are usually 2-4 ic's types on a panel (driver/SR chips, decoders, etc.) If you send each of the different designators I might be able to get enough info on the board to identify how to make it work. Also, there is usually a panel designator/part number on the back of the panel. If you could let me know what this is it could help me locate docs as well. (e.g., two of my panels are: P3-6432-2121-16S-D1.0, and P4-1921-8S-V2.0)
By the way, after a three-month wait our HUB75 panels should be in stock this week. It was quite the process to import these panels between the customs declarations, shipping fees, Chinese New Year, tariffs (!!), import fees, yada yada. We'll have 100 units to start with, less the four that are going to Stephen right away.
Hi Stephen
Here's some photos of my 32x32 P6 panel. Its sold here locally in AU by 'Altronics'. I know one of the guys there and could possibly chase further information through him if we get stuck.
regards
Lachlan
The 16S part of the panel number is a good sign that it may just be a clocking/timing issue. I'll dig into the data sheets to see if anything looks unusual. And yes, should be ABCD addressing.
FYI- I saw some artifacts while taking pic's of the 64x64 panels being driven... so I'm guessing I've more work to do on adjusting the pixel timing to rid ourselves of the artifacts.
@Tubular I haven't forgotten your need for the 32x32 panel. I'm trying to make sense of the chips... You indicate that you may be able to get more info from Altronics. If you can, let's try that.
If I've found the correct Datasheets:
SM245TS appears to be an octal bus transceiver that is likely just repeating the HUB75 input signals to the HUB75 output connector
SM74138HD appears to be a 3-8 decoder with enables - this might be driving the LEDs? with some fancy mapping of the HUB75 A,B,C,D signals to the chip enables.
Which chip part number is at the RU[1-4], GU[1-4], and BU[1-4] locations? (is this the 74138s?)
Also, after looking at the back of your panels... what chip is at U3 and U4?
Well, maybe I should ask this another way... ;-). Have you shown all the unique IC part numbered chips?
NOTE: As a result of my Matrix Light Measure project study, I learned how driving the LEDs via PWM using various patterns didn't matter significantly at the speeds that the driver is feeding the panels. This gave me the idea that I could generate the PWM values in a different fashion than the current version of the driver is.
I'm currently working on a driver update that applies this change effectively rethinking the color-depth encoding and PWM buffer generation.
If this works (finishing code now and entering testing) This change will enable:
Driver handling of 3 to 8-bit color depths, compile-time selectable by the user
Driver to be more efficient at using memory for PWM buffers (Ex: at 4-bit depth, the driver uses ¼ the memory as prior version)
Deeper color depths using slightly more memory but yielding slower effective video frame rates (direct tradeoff)
Automatic mapping of 24bit RGB pixel colors to selected bit depth
Thought you'd like to know. When I get it working I'll have something to show at one of our zoom meetings.
@"Stephen Moraco" said:
@Tubular I haven't forgotten your need for the 32x32 panel. I'm trying to make sense of the chips... You indicate that you may be able to get more info from Altronics. If you can, let's try that.
If I've found the correct Datasheets:
SM245TS appears to be an octal bus transceiver that is likely just repeating the HUB75 input signals to the HUB75 output connector
SM74138HD appears to be a 3-8 decoder with enables - this might be driving the LEDs? with some fancy mapping of the HUB75 A,B,C,D signals to the chip enables.
Which chip part number is at the RU[1-4], GU[1-4], and BU[1-4] locations? (is this the 74138s?)
Also, after looking at the back of your panels... what chip is at U3 and U4?
Well, maybe I should ask this another way... ;-). Have you shown all the unique IC part numbered chips?
Hi Stephen
Sounds like good progress
U3 and U4 are 74HC138D
The twelve RU/GU/BU ics are DP5220
There are some 4953 (Si4953) fets in the SOIC-8 packages, 8 of them Q1..8
No hurry on getting this one working, also it occurred to be I really should grab one of your boards from Parallax with my next order, because the other panels I have been driving successfully with 3v3 signals using jumper wires, but this Altronics one may really need 5v
@"Stephen Moraco" said:
I'm currently working on a driver update that applies this change effectively rethinking the color-depth encoding and PWM buffer generation.
Turn on of new code, can be fun??!!
initial turnon is going well... once I find out why my 4bit is behaving like 3bit (8-colors) and fix it and I'll have a working driver!
my final testing will then be:
(1) certify 3-8 bit color depths
(2) re-certify the clocking of the 5 known panel types
(3) take new measurements of timings for each of 5 known panel types, post new/latest timing values to repository pages for reference
After this certification/re-certification testing is accomplished and any fixes made then I'll release the new driver.
It's really fun to see this new concept working so far!
If you find some issue with this code then please report it at my github repository issues page. Otherwise, let's continue discussing in this thread! ;-)
v2.0.1 of RGB LED Matrix Driver is released. The changes are:
Support up to three HUB75 cards
(along with updated 5x7 Font, new text-scroll types, and new ICN2037_B chip support)
Convert initialization: enable support for up to three hub75 cards!
5x7 font upgraded: now have full traditional ASCII character set (with lower-case characters)
Rename demos (now all start with demo_)
Add new demos: demo_hub75_5x7font.spin2 and demo_hub75_scroll.spin2
Upgraded scrolling: now supports scroll directions: up, down, left, right
Added support for a New Panel (same chip as ICN2037 but slightly different settings, the new name is: ICN2037_B*: where colors are not swapped and scan is different*)
Repo READMEs have been updated: changed demo file names and changed how configuration is done.
See the project ChangeLog at github-repo for more details.
The changes to this driver in order to support multiple HUB75 cards (multiple instances of this driver to be compiled into your code) were in fact a shift from your panels being described as compile-time constants to now using a mix of compile-time and run-time panel specification values. Any existing matrix code you have will take a few minutes to convert when moving to this new driver. To make this conversion easier for you I've created a CHECKLIST: Convert your code from v1.x to v2.x+ which introduces you to the necessary changes and then walks you through the changes you need to make.
If you find some issue with this code then please report it at my github repository issues page. Otherwise, let's continue discussing in this thread! ;-)
Stephen, I have questions about panels in general. I take it HUB75 is the protocol? I see a lot of people using the P5 and P10 panels in Christmas displays. Do those use HUB75 or another protocol?
@ke4pjw said:
Stephen, I have questions about panels in general. I take it HUB75 is the protocol? I see a lot of people using the P5 and P10 panels in Christmas displays. Do those use HUB75 or another protocol?
The Parallax panel looks very nice!
Terry, HUB75 is an electrical spec for these panels. 16-pin IDC connector - 16 conductor ribbon cable is used for all signals driving the panels. The panels are connected in a daisy-chain fashion meaning the driving source is connected to the IN connector on the first panel. The OUT from this first panel is connected to the IN of the 2nd panel and so on.
The P5 and P10 refer to the spacing between the LEDs (pixels) of the display. P5 is 5mm center to center, while P10 is 10mm center to center... one can find p1.2 to p10 and you can find indoor-only and outdoor-rated panels.
Not all panels are the same. Not all use hub75, there are other HUB* forms as well as a serial bit stream, individually addressable, forms (arrays of LEDs like ws2812Bs)
Oh, and one more comment. When ordering these panels from a vendor Amazon, AliExpress, etc. you want to order them as groups to ensure you get the same type of driver chips for all panels in the group. Yep, this is an issue. The panels are made so quickly and inventory runs out so quickly that the manufacturers are constantly "improving" their offering by upgrading to newer driver chips. The timing is specific to each driver chip to my P2 OBject has to be told which driver chip is on a chain of panels so it knows what timing to use for signaling. Some of the earlier driver chips even needed configuration sent down the chain first before they would work correctly. The biggest problem in all of this is finding documentation for the timing needed for any specific driver chip.
I'm not trying to make this sound too bad. I've been pretty lucky getting the latest panels working as my driver seems to have most of the adjustments needed so far. When I meet a new panel driver chip for the first time I mix and match the various tuning parameters the driver supports to get the signaling correct.
Question for Stephen... Is there a requirement that the HUB75 driver runs at 335MHz CLK_FREQ? If I lower the clock frequency to 270MHz, will the HUB75 driver just run slower (i.e. display of pixels, & text scrolling slowed down) or will the LED Matrix not work at all?
I'm combining several current projects to hopefully display weather data from OpenWeatherMap on the HUB75 LED Matrix Display. A Raspberry Pi Pico W (RP2040), running Python uses OpenWeatherMap APIs to gather forecasts, which are sent via the RP2040's UART1 to the P2. When I set up the code at 335MHz CLK_FREQ, text was mangled at every baudrate that I tried. Lowering CLK_FREQ to 270MHz, allowed error-less transfer of data between the RP2040 and the P2 at 230_400.
@dgately said:
Question for Stephen... Is there a requirement that the HUB75 driver runs at 335MHz CLK_FREQ? If I lower the clock frequency to 270MHz, will the HUB75 driver just run slower (i.e. display of pixels, & text scrolling slowed down) or will the LED Matrix not work at all?
I'm combining several current projects to hopefully display weather data from OpenWeatherMap on the HUB75 LED Matrix Display. A Raspberry Pi Pico W (RP2040), running Python uses OpenWeatherMap APIs to gather forecasts, which are sent via the RP2040's UART1 to the P2. When I set up the code at 335MHz CLK_FREQ, text was mangled at every baudrate that I tried. Lowering CLK_FREQ to 270MHz, allowed error-less transfer of data between the RP2040 and the P2 at 230_400.
dgately
I've dropped the CLK FREQ down to lower values like 200MHz and below and had a single HUB 75 LED Matrix work fine.
I don't know if running multiple combined LED Matrices (modules) with lower clocks speeds would have issues.
@dgately said:
Question for Stephen... Is there a requirement that the HUB75 driver runs at 335MHz CLK_FREQ? If I lower the clock frequency to 270MHz, will the HUB75 driver just run slower (i.e. display of pixels, & text scrolling slowed down) or will the LED Matrix not work at all?
The reason I choose to run at the high clock rate is to evaluate the max frame rates I can eke out of the driver. Generally speaking, you can run at any clock rate as long as it is sufficient to get the panel display frame rate you want. You will generally want to stay above 60Hz for the overall frame rate to eliminate the flicker.
However there is one caveat: I am not using the best possible means for generating delays in the signaling so if one chooses too low a clock rate the delays will start to get too large and will affect the display logic. I don't know what these numbers are but if you see display issues when you lower the rate just report it here so we all know. As long as your display is showing correctly the timing should work for multiple panels as well as a single panel.
I'm combining several current projects to hopefully display weather data from OpenWeatherMap on the HUB75 LED Matrix Display. A Raspberry Pi Pico W (RP2040), running Python uses OpenWeatherMap APIs to gather forecasts, which are sent via the RP2040's UART1 to the P2. When I set up the code at 335MHz CLK_FREQ, text was mangled at every baudrate that I tried. Lowering CLK_FREQ to 270MHz, allowed error-less transfer of data between the RP2040 and the P2 at 230_400.
Comments
We'll also add a wider panel more suitable for text scrolling, next.
Ken Gracey
We found that the panels showing the text doubling and overlap are using a different (and lately less common) addressing scheme.
To explain I have to introduce a topic briefly. (if you are not interested in how we send data to these panels, you can skip this post, just know that we've identified the problem.)
In Detail:
When buying panels you'll see that 1/16 scan and 1/32 scan panels are more common lately and use ABCD and ABCDE addressing respectively. When looking at these panels one sees that there are 2x more rows than addresses (e.g., 1/16 scan has 32 rows, while 1/32 scan has 64 rows, etc.)
For this to work, we emit RGB1 values simultaneously with RGB2 values effectively sending 2 pixels of data in a single clock. For 1/16 scan we are sending pixels for rows 0 and 16, 1 and 17, 2 and 18, etc. at the same time. We paint the top half rows 0-15 simultaneously with the bottom half rows 16-31 (or 0-31 with 32-63.)
The ⅛ scan panels, in this specific case, 64x32 are a different animal in that we now have 32 rows and only addresses 0-7 (ABC, only, addressing.) HUB75 limits us to still sending only RGB1 and RGB2 values at the same time. So a ⅛. scan 16-row panel works in our current scheme but a ⅛ scan 32-row panel doesn't.
This will cause a different pixel ordering on the serial stream and sending 4 pixels for each address but I'm not yet finding good examples for how this stream has to look. A visual example of this painting of 4 lines at a time can be seen in this Sparkfun post (scroll down to the black/red animated images.)
I do want to address ⅛ scan panels in the driver, but after discussion with Roy, we decided that I will first clean up 64x64 single panel display timing, and get the multi-panel display working before I try to add code to handle the ⅛ scan panels.
Thanks for reading.
"Excellent" choice Ken, as the ICN2037 driver chip for the 64x64 1/32 scan panel quoted in the .pdf is already supported by this driver and is the same panel a @Twyyx had sent to me to use during awakening of this support!
In HP parlance, an "Excellent question" is one for which we already had an answer ;-)
Would you mind re-posting any links for those 64x32, 1/8 scan panels you've been talking about?
Unfortunatelly, I also didn't got a means to understand which kind of panel (led-pitch) you've been talking about: P2, P3, P4...?
Any closeup image(s), took from the backside would be highly appreciated.
Thanks in advance for any useful reference.
Henrique
- Multi-panel now works in development code (not yet released, sitting on develop/ branch in repo)
- I have a better understanding of what's needed for our ⅛ scan panels (just a bit more code... ;-)
-- To the user of a 64x32 ⅛ Scan panel it appears as 64x32 pixels (internally the driver treats it as a 128x16 panel, just fun!)
-- Oh, also they draw 8A @5v at full-on for each 64x32 panel.
Latest Issues I'm chasing
- I'm having difficulty with my most-performant panels (FM6126A-based) as these need custom init code at power-on. I can init a single panel. Multiple panels don't init correctly.
-- The related chips are FM6126A, FM6126Q (w/2 init registers), and FM6127 (w/3 init registers). The Chinese datasheets don't cover the needed initialization serial chains. Lots of RPi and Arduino users refer to a working snippet of code... which also works for me when ported for single panels but not for multiple panels. Unless I find more online references I may be down to stepping thru likely bit patterns until I hit one that works.... (mumble...mumble...)
-- FYI: (links to the various posts about this init stuff.) which are also in my code.
More news when I have more... ;-)
The ⅛ Scan i found at: Amazon - ⅛ scan (but says 1/16th, sigh)
Larger panels reportedly using FM6126A chips (but i"ve no first-hand knowledge): also at Amazon
Thanks for reposting the 1/8 scan panel link.
I use to save the meetings chat sessions very often, but sometimes, my 4G connection simply drops, closing the Zoom session, and I feel like a lost soul, in a swampy vacuum...
Also thank you for the heads-up, about the evolution of the project.
Henrique
Progress
Latest Efforts
Meanwhile, For your entertainment (twin 64x64 panels working as a single display and some fun animation):
Thanks for reading.
More news when I have more... ;-)
Progress Our first (limited) Multi-panel support
I've posted v0.2.0 of the LED Matrix driver (See Releases page) and released it to the P2 Obex.
Known Issues
Up Next:
Regards,
Stephen
I found some time to test with a 64x64 P2 panel, works great Stephen. Thanks for all your hard work on this driver
I also have a 32x32 P6 panel that has DP5220 driver ICs, and (i think) ABCD driving, but thats just going by the silkscreen. I've tried the various inbuilt ICs without luck, but will revisit this one later
Thank you!
Now that you've been through making it work, is there anything I should address in the instructions to make it easier to use/understand?
Also, when you want to take the time, re the 32x32 board: there are usually 2-4 ic's types on a panel (driver/SR chips, decoders, etc.) If you send each of the different designators I might be able to get enough info on the board to identify how to make it work. Also, there is usually a panel designator/part number on the back of the panel. If you could let me know what this is it could help me locate docs as well. (e.g., two of my panels are:
P3-6432-2121-16S-D1.0, andP4-1921-8S-V2.0)By the way, after a three-month wait our HUB75 panels should be in stock this week. It was quite the process to import these panels between the customs declarations, shipping fees, Chinese New Year, tariffs (!!), import fees, yada yada. We'll have 100 units to start with, less the four that are going to Stephen right away.
Ken Gracey
Hi Stephen
Here's some photos of my 32x32 P6 panel. Its sold here locally in AU by 'Altronics'. I know one of the guys there and could possibly chase further information through him if we get stuck.
regards
Lachlan
@Tubular great pics... these work.
The 16S part of the panel number is a good sign that it may just be a clocking/timing issue. I'll dig into the data sheets to see if anything looks unusual. And yes, should be ABCD addressing.
FYI- I saw some artifacts while taking pic's of the 64x64 panels being driven... so I'm guessing I've more work to do on adjusting the pixel timing to rid ourselves of the artifacts.
Jes letting you all know... ;-)
@Tubular I haven't forgotten your need for the 32x32 panel. I'm trying to make sense of the chips... You indicate that you may be able to get more info from Altronics. If you can, let's try that.
If I've found the correct Datasheets:
Which chip part number is at the RU[1-4], GU[1-4], and BU[1-4] locations? (is this the 74138s?)
Also, after looking at the back of your panels... what chip is at U3 and U4?
Well, maybe I should ask this another way... ;-). Have you shown all the unique IC part numbered chips?
NOTE: As a result of my Matrix Light Measure project study, I learned how driving the LEDs via PWM using various patterns didn't matter significantly at the speeds that the driver is feeding the panels. This gave me the idea that I could generate the PWM values in a different fashion than the current version of the driver is.
I'm currently working on a driver update that applies this change effectively rethinking the color-depth encoding and PWM buffer generation.
If this works (finishing code now and entering testing) This change will enable:
Thought you'd like to know. When I get it working I'll have something to show at one of our zoom meetings.
Hi Stephen
Sounds like good progress
U3 and U4 are 74HC138D
The twelve RU/GU/BU ics are DP5220
There are some 4953 (Si4953) fets in the SOIC-8 packages, 8 of them Q1..8
No hurry on getting this one working, also it occurred to be I really should grab one of your boards from Parallax with my next order, because the other panels I have been driving successfully with 3v3 signals using jumper wires, but this Altronics one may really need 5v
PROGRESS!
Turn on of new code, can be fun??!!
After this certification/re-certification testing is accomplished and any fixes made then I'll release the new driver.
It's really fun to see this new concept working so far!
Thanks! I'll pull these datasheets next.
NEWS
I've just released v1.0.0 of RGB LED Matrix Driver. The changes are:
See the project ChangeLog at github-repo for more details.
The latest driver timings and video frame rates we can achieve are at Driver configuration by chip type - S/W Ver 1.x Timings
One fun note is the fact that with this new driver our P2 P2 Cube can do:
If you find some issue with this code then please report it at my github repository issues page. Otherwise, let's continue discussing in this thread! ;-)
Enjoy!
Stephen
NEWS
v2.0.1 of RGB LED Matrix Driver is released. The changes are:
See the project ChangeLog at github-repo for more details.
The changes to this driver in order to support multiple HUB75 cards (multiple instances of this driver to be compiled into your code) were in fact a shift from your panels being described as compile-time constants to now using a mix of compile-time and run-time panel specification values. Any existing matrix code you have will take a few minutes to convert when moving to this new driver. To make this conversion easier for you I've created a CHECKLIST: Convert your code from v1.x to v2.x+ which introduces you to the necessary changes and then walks you through the changes you need to make.
If you find some issue with this code then please report it at my github repository issues page. Otherwise, let's continue discussing in this thread! ;-)
Enjoy!
Stephen
Stephen, I have questions about panels in general. I take it HUB75 is the protocol? I see a lot of people using the P5 and P10 panels in Christmas displays. Do those use HUB75 or another protocol?
The Parallax panel looks very nice!
Terry, HUB75 is an electrical spec for these panels. 16-pin IDC connector - 16 conductor ribbon cable is used for all signals driving the panels. The panels are connected in a daisy-chain fashion meaning the driving source is connected to the IN connector on the first panel. The OUT from this first panel is connected to the IN of the 2nd panel and so on.
The P5 and P10 refer to the spacing between the LEDs (pixels) of the display. P5 is 5mm center to center, while P10 is 10mm center to center... one can find p1.2 to p10 and you can find indoor-only and outdoor-rated panels.
Not all panels are the same. Not all use hub75, there are other HUB* forms as well as a serial bit stream, individually addressable, forms (arrays of LEDs like ws2812Bs)
Oh, and one more comment. When ordering these panels from a vendor Amazon, AliExpress, etc. you want to order them as groups to ensure you get the same type of driver chips for all panels in the group. Yep, this is an issue. The panels are made so quickly and inventory runs out so quickly that the manufacturers are constantly "improving" their offering by upgrading to newer driver chips. The timing is specific to each driver chip to my P2 OBject has to be told which driver chip is on a chain of panels so it knows what timing to use for signaling. Some of the earlier driver chips even needed configuration sent down the chain first before they would work correctly. The biggest problem in all of this is finding documentation for the timing needed for any specific driver chip.
I'm not trying to make this sound too bad. I've been pretty lucky getting the latest panels working as my driver seems to have most of the adjustments needed so far. When I meet a new panel driver chip for the first time I mix and match the various tuning parameters the driver supports to get the signaling correct.
See pics on this page for some of my setups: HardwareTurnon.md
See descriptions on this page for timings I've achieved with the different driver chips so far: Timings HUB75-Driver-SWver1
Does this help?
@"Stephen Moraco" that helps much! Thank you! I may make the Parallax panels my project over the holidays.
Question for Stephen... Is there a requirement that the HUB75 driver runs at 335MHz CLK_FREQ? If I lower the clock frequency to 270MHz, will the HUB75 driver just run slower (i.e. display of pixels, & text scrolling slowed down) or will the LED Matrix not work at all?
I'm combining several current projects to hopefully display weather data from OpenWeatherMap on the HUB75 LED Matrix Display. A Raspberry Pi Pico W (RP2040), running Python uses OpenWeatherMap APIs to gather forecasts, which are sent via the RP2040's UART1 to the P2. When I set up the code at 335MHz CLK_FREQ, text was mangled at every baudrate that I tried. Lowering CLK_FREQ to 270MHz, allowed error-less transfer of data between the RP2040 and the P2 at 230_400.
dgately
I've dropped the CLK FREQ down to lower values like 200MHz and below and had a single HUB 75 LED Matrix work fine.
I don't know if running multiple combined LED Matrices (modules) with lower clocks speeds would have issues.
Thanks, good to know!
The reason I choose to run at the high clock rate is to evaluate the max frame rates I can eke out of the driver. Generally speaking, you can run at any clock rate as long as it is sufficient to get the panel display frame rate you want. You will generally want to stay above 60Hz for the overall frame rate to eliminate the flicker.
However there is one caveat: I am not using the best possible means for generating delays in the signaling so if one chooses too low a clock rate the delays will start to get too large and will affect the display logic. I don't know what these numbers are but if you see display issues when you lower the rate just report it here so we all know. As long as your display is showing correctly the timing should work for multiple panels as well as a single panel.
FYI- I have a very well-behaved serial driver certified to run 8 full duplex serial ports without suffering data loss at up to 26 times 115_200. Should you need to pay more attention to the serial issue...
I look forward to your sharing your project. I've been seeing those projects and thought this would be a fun effort.