General questions

[pitschu]

Here is some Questions from daveythacher:

• BCM has issues with high refresh rates.
• 26MHz is not supported by fan out of most panels and LED drivers.
• FreeRTOS may not respond well from XIP.
• You include binaries in your repo.
• Hardware only works in specific configurations.
• 50Hz scan rate is too low, you will not be able to support all 24 bits with 64x64. There is a couple tricks for getting 24 bit significance but you lose the finer details. (I believe you are mixing up frame rate with refresh/scan rate.)
• Contrast limit is fixed in most panels, but multiplexing distorts this. (24 bit on 32 scan is wasteful.)
• To avoid flicker you need high refresh rate. (100 Hz is min in most cases. Anything beyond 3000 is likely overkill.)

[pitschu]

• BCM has issues with high refresh rates.: I never observed issues with BCM. What do you mean?
• 26MHz is not supported by fan out of most panels and LED drivers.: Nearly all panels I ever used have shift registers specified for 30MHz up to 35MHz. Only very few are rated 25MHz at worst conditions.
• FreeRTOS may not respond well from XIP.: FreeRTOS is not involved here for the matrix timing. In this demo, FreeRTOS only handles different tasks which fill the LED screenbuffer.
• You include binaries in your repo.: The binaries work for the given hardware
• Hardware only works in specific configurations.
• 50Hz scan rate is too low, you will not be able to support all 24 bits with 64x64. There is a couple tricks for getting 24 bit significance but you lose the finer details. (I believe you are mixing up frame rate with refresh/scan rate.): Yes, 50Hz is too slow, but with BCM coding this is only a problem when a color value of 0x01 or 0xfe is displayed. A color of 0x02 will have an optical refresh of 100Hz, color 0x03 of 150Hz and so on. The frame rate is always 50Hz. You can increase the frame rate by reducing the bit planes from 8 downto 4 in this driver.
• Contrast limit is fixed in most panels, but multiplexing distorts this. (24 bit on 32 scan is wasteful.):
• To avoid flicker you need high refresh rate. (100 Hz is min in most cases. Anything beyond 3000 is likely overkill.)

[daveythacher]

Going to break this out into individual comments.

[daveythacher]

BCM has issues with high refresh rates.

I never observed issues with BCM. What do you mean?

The fan out of the panels block certain frequencies. This creates a cut off frequency. The frequency is 2^bits * refresh * multiplex. For 24 bit color this is at least: 25.6kHz to 24.576MHz.

[daveythacher]

If your plan is say 100kHz you will have a problem in certain cases. Note your max refresh is this divided by the multiplex. This assumes you use PWM not BCM. PWM has better signal integrity, but may not matter in certain cases. This is why many drop the lower bit planes as they may not ever even appear. They can optimize the timing while keeping the significance of 24-bit color.

[daveythacher]

The worst case frequency is serial clock divided by shift length. With PWM this is further divided by 2^bits. It is not with BCM. S-PWM is a hybrid of the two. It reduces the flicker of the most significant bits. The lower bits are harder to see by most people. These bits do flicker however unless you forbid this with configuration. You do this by switching frames before this would happen which forces a PWM with high frequency.

S-PWM was developed for higher density panels used on SRAM LED drivers. It is not very useful in outside of these, but is used on some hardware PWM drivers without SRAM. The problem was multiplexing and configuration. S-PWM is an algorithm based control system. Note some versions are patented.

[daveythacher]

26MHz is not supported by fan out of most panels and LED drivers.

Nearly all panels I ever used have shift registers specified for 30MHz up to 35MHz. Only very few are rated 25MHz at worst conditions.

This only works on certain ones. Depends on voltage and panel implementation.

[daveythacher]

FreeRTOS may not respond well from XIP.

FreeRTOS is not involved here for the matrix timing. In this demo, FreeRTOS only handles different tasks which fill the LED screenbuffer.

You need to use RAM functions and implement things in linker script carefully to avoid XIP stalls.

[daveythacher]

You include binaries in your repo.

The binaries work for the given hardware

This is bad practice. Create release instead.

[pitschu]

This is a tech demo and no product. I think anybody who will find this driver useful will have an own target hardware and he has to adapt the hardware settings in this project (at least the .pio files)

[daveythacher]

Hardware only works in specific configurations.

Termination lines and stuff. You did not respond to this.

[pitschu]

The hardware I published her has been tested with 64x64 and 128x128 matrix panels with 'standard configuratrions' (means 64x32x2 resp. 128x32x4). For other panels types, you have to change the .pio files, not the hardware layout.

[wyswys95]

What need to be change if I want to use 2 64x64 panel -> 128*64, its easier to change HUB75_SIZE 4040 or 8080

[daveythacher]

@wyswys95 Please create new discussion in Q&A

[daveythacher]

50Hz scan rate is too low, you will not be able to support all 24 bits with 64x64. There is a couple tricks for getting 24 bit significance but you lose the finer details. (I believe you are mixing up frame rate with refresh/scan rate.)

Yes, 50Hz is too slow, but with BCM coding this is only a problem when a color value of 0x01 or 0xfe is displayed. A color of 0x02 will have an optical refresh of 100Hz, color 0x03 of 150Hz and so on. The frame rate is always 50Hz. You can increase the frame rate by reducing the bit planes from 8 downto 4 in this driver.

So you implement full S-PWM?

[pitschu]

It's not really a BCM with modulated clock widths. The bit stream sent to the shift register is a BCM coded data stream clocked in with the maximum clock rate. May be you mean this with S-PWM (I'm sure it's not 'software PWM').

[daveythacher]

S-PWM is scrambled PWM. Basically it is PWM which has been divided into sub periods. Values are distributed across these sub periods to ensure an average value is always there. This allows you cut the period short by terminating on VSYNC points. The result of this is you can dynamically change the number of used PWM bits and refresh frequency on the fly.

Example of distribution:
You have 8 bags, and 100 jelly beans. You will will ensure that there is an even number of jelly beans in each bag. If you do not have an even multiple of 8 you will distribute the jelly beans in a manner which averages them across the bags.

VSYNC points:
In the following example there are 8 sub periods. You will multiplex all rows using one of the bags. (Not the same bag but the bag number for the LED.) After doing this you are at a VSYNC point. Here you can switch to another set of bags starting over with the first. Or you can proceed to the next bag in the current set.

Note this algorithm uses a binary tree for distribution. The sub periods are standard PWM of a predetermined size. Pretty cleaver actually, but almost never explained well.

[daveythacher]

clever, not cleaver...

[daveythacher]

Contrast limit is fixed in most panels, but multiplexing distorts this. (24 bit on 32 scan is wasteful.)

You did not respond to this.

[pitschu]

That's true and a technical constraint in multiplexed panels. BTW: It's not 24 bit color planes, only 8 bit per led

[daveythacher]

Note the contrast also somewhat fades with distance. I generally found many panels use something like 8mA for the blue LED which is the lowest forward current of the red, green and blue LEDs. If you look at the LEDs up close you can see them light at around 2-4nA. This gives about 12 bits of color depth if looking up close. (Note full white could be painful and is not recommended.)

How much contrast you get at distance is not known to me. However I have seen some of the newer ones and they are capable of decent contrast allowing for decent color rendering in higher resolution images for a decent distance. I have no clue what the power output of these are. A little color depth can go a longs ways in the right image.

Again multiplexing is generally higher for indoors than for outdoors. Outdoors need to be brighter for sunlight. At night they can be too bright if not placed in the right location. However you can just dial them down in some cases.

[daveythacher]

According to some digging it looks like the current changes the wavelength which changes the color. The relation ship is not perfectly linear more logarithmic than linear, however the full range is linear. LEDs are known to be slightly different so this can get pointless at some point. (Need dot correction for every LED or color potentially.)

Anyhow there can be a need for a fairly high color depth to express all wavelengths. However there is a limit to how many can be expressed. Most libraries use most significant bits because of this.

Therefore you may not care about brightness or distance as much.

[daveythacher]

To avoid flicker you need high refresh rate. (100 Hz is min in most cases. Anything beyond 3000 is likely overkill.)

Note ghosting is problematic at higher refreshes in most panels. There are tricks for working around this. You did not respond to this.

[pitschu]

Most panels I'm working with have ghosting problems. The tricks you mentioned are quite easy: Switch ON/OFF the OE line at the right times. The ADDR lines must not change while OE is enabled. The OE drivers need some time to switch on/off the LEDs, so leave some time before doing anything else. Of course, the scan rate will go down even more then.

[daveythacher]

It is more involved than that. There are charges in the high and low side of the LED array.

[pitschu]

But these are given constraints by the hardware you cannot change. Increasing the 'inactive time' of the OE and LATCH times (front and back porch) avoids ghosting.

[daveythacher]

This works but only so far. The correct answer involves adding pull ups on the columns (low side, where the LED drivers are) and pull downs on the rows (high side, where the PMOS drivers are). The OE line needs to be carefully timed to configure the display for charging the low side and discharging the high side. (I would only really do this on the low side and it is usually done for you, if you read/find a proper datasheet.)

MBI5124 has the low side. (There is a configuration register which I have no clue what it does. However I know the MBI5124 performs better than panels without this feature in the low side drivers.) TI drivers have it in some of theirs. My guess is some of the custom build row drivers have something in them. Note push pull would work for row drivers if you can disable all of them globally.

Some panels have pads for pull downs but these are less efficient as there is no OE signal. Which does not affect most people. However a safe value of 10K is could be recommended here. This causes some issues with the discharge performance in some cases. More ideal setups exist as mentioned earlier.

Good luck finding panels which correctly state their performance. Most are only good up to 250Hz. However I has seen some go above 3kHz.