S-PWM SRAM driver support

[daveythacher]

I am not sure if these are legal to support unless you can prove the reverse engineering approach used.

I took a look into the MBI5153, which has what I thought was full datasheet. However it does not work, after messing around with ColorLight receiver card and configuration software I discovered it was incomplete. The issue with using this approach to reverse engineer the LED driver is that it is forbidden by the user agreement if you read it. More than likely the full datasheets use NDA, which ColorLight has.

This means that you would need to prove that you can support them without using these to reverse engineer them. The only successful approach I have seen which may work is to use them as S-PWM drivers without SRAM. This lowers the reverse rate significantly along with the display density and brightness.

There is a means to use these panels via receiver cards with a microcontroller and gigabit switch. However I am not sure if this is legal either. I have attempted to contact them multiple times. They are very indirect in their statements. Nothing concrete, it is also unclear if they are the ones who can give this permission.

GEN 1 panels are mostly public domain. S-PWM I believe is patented by Macroblock. Texas Instraments does use this technology and as far as I know publish full documentation. However most Chinese panels are from Macroblock vendors or other Chinese vendors like ChipOne.

In order to support high refresh with GEN 1 you need to consider using custom panels and multiple HUB75 connectors in parallel. Texas Instruments has few custom parts which are more affordable than in the past. These include GEN 1 (constant current shift registers), GEN 2 (constant current shift registers with hardware PWM/S-PWM) and GEN 3 (constant current shift registers with hardware PWM and SRAM). Anti-ghosting requires some pull up logic on the low side and pull downs on the high side.

Many panel have limits on fan out as the panels are naturally limiting in this regard. Many GEN 1 panels are probably more appropriate for outdoor displays. (High pixel pitch.) Please use cation when talking with people on SmartMatrix and RPI-RGB-LED-Matrix. There are conceptual flaws with their implementations. (Bit plane dropping must respect the PWM period, for example. There are others.) However for the most part the theories are sound. RPI implementation has a slight issue in certain cases, but I will not bore you with the details.

S-PWM is a neat trick but does not apply to GEN 1 panels.

[board707]

Hi, David!
Thank for your suggestions.
But I am not sure that did understood it in full.

The issue with using this approach to reverse engineer the LED driver is that it is forbidden by the user agreement if you read it.

What is a user agreement do you talking about? Is it UA to led driver or led receiver card or something else? I just reread some of driver datasheets and did not find a ban on using drivers with third-party software.

More than likely the full datasheets use NDA, which ColorLight has.

What is NDA ?

The only successful approach I have seen which may work is to use them as S-PWM drivers without SRAM.

I don't think that this drivers can be used without SRAM. Or, in other words, I don' t think that somebody will use it without SRAM - it would be a complete nonsense. There are many other drivers for it.

[board707]

You wrote:

The RP2040 lacks the memory for parallel chains.

how did you calculate this? From my point of view using the parallel chains does not require additional memory compared to a single chain (of double length, of course). The RP2040 has more than enough memory for this.
RP2040 easily works with two chains in parallel - I tested this mode. It could even work with three, but it just doesn't have enough pins for that.

And also I have a question. You discussed a two modes for GEN 1 panels - BCM and PWM. But as far I know, direct using of PWM for brightness control is incompatible with RGB panels. What are you mean for it? As for me, the BCM and PWM methods are the same, it merely two names for one thing, isn't it?

[daveythacher]

A HU75 connector is a 6-bit bus which can be converted into a bytes per shift. Two bytes are required for two connectors. We are only 75 percent usage of the memory, which we could address however this ultimately is pointless in most cases. However this means we need at least 1-2 bytes per shift.

To compute the number shift required at the worst case we take the max serial clock (25MHz) and divide it by the lowest refresh rate (100Hz). The result of this is 250,000 samples or 250,000 bytes for a single HUB75. We would need 500,000 bytes for two connectors. This is worst case and assumes we use no color depth and convert every sample into a pixel. (Technically there are two pixels per sample.) This would generate the max resolution for GEN 1. Note we would need to use a custom panel which addresses the CLK fanout, which generally limits the serial clock below 25MHz in this worst case.

If we wanted to compute bear min memory usage in this worst case we would multiple the requirement times 0.75, which would yield. 187,500 bytes per connector. Note this assumes single buffer and more than likely we will need to double buffer which would double the previously listed totals.

Many cases the color depth forbids such extreme notions of memory requirements. Particularly when using BCM. BCM lowers the memory usage by a factor of ((2^x)-1)/x. In the worst case x is 1 which results in a no reduction. However if x is 8 then the reduction is near 32 times. Instead of having 255 samples we have 8. We burn off the time to create the color depth.

High refresh rates are were things get interesting. BCM can actually under perform. PWM is can also under perform, but is generally more capable. The reason for this is the par capacitance built into the panel. This basically acts as a low pass filter which blocks the high frequencies. PWM naturally works with high frequencies. A single pulse has higher immunity than multiple pulses. Nature resists change and PWM changes less.

When you increase the refresh rate and multiple you increase the frequency for PWM and BCM. GEN 1 naturally uses a lower frequency compared to GEN 2/3. For GEN 1 the frequency cannot exceed 25MHz divided by shift length. In GEN 2/3 it can be as high as 25MHz to 33MHz, if you manage the fanout.

It is important to remember that most LEDs only support around 12 bits of color depth. This is the most you will likely ever be able to get out of them. Most people do not really need more than 8 per color and could possibly get by with less. The LED scan rate lowers the color depth, as you trade the color depth for resolution.

For the most part the color depth is to stay the same. You use the new generations to increase the refresh rate. Thus the color depth and resolution is a function of multiplexing. For GEN 1 the resolutions is generally low. For GEN2 it is marginally better with high refresh support. For GEN 3 you have the best resolution and refresh possible. However the fanout is a serious concern for GEN 3.

Returning back to par cap and BCM. If you have a low pass filter at 100kHz, then you can have a 32 scan panel with a 3kHz refresh rate. However BCM's lower bit planes will never likely matter. The higher bit planes will be corrupted. To the point you may not wish to even bother with color depth. PWM on the other hand will be more immune as there is only one edge to be corrupted. The overall percentage of corruption on the edge will be the same however the duty cycle will be more correct.

For example with BCM, consider a 100kHz panel which is attempting to use 32-bits of color depth. The least significant bitplane will be 1/(32 * 100,000) or 3.125uS. Now the cutoff point is 10uS. Which means the total duty cycle will the the following sum:
max(3.125 - 10, 0) + max(6.25 - 10, 0) + max(12.5 - 10, 0) + max(25 - 10, 0) + max(50 - 10, 0) or 57.5, but the sum should be 96.875. Thus the real duty cycle is 59.35 percent instead of 100 percent.

Now consider the same example for PWM:
max(96.875 -10, 0) or 86.875. Making the real duty cycle 89.6 percent instead of 100 percent. That means that PWM is 50 percent better.

Now imagine if the panel had a cutoff at 2kHz. Things get really annoying quick. Measuring the cutoff is annoying and varies from panel to panel. I doubt most are this extreme. Higher scan rates require PWM and likely have worse cut offs than low scan. However there is a lot that goes into, I would imagine.

[daveythacher]

BCM generally works on lower refresh rates. If you play with the numbers you will find that the using low refresh with high color depth will create a better duty cycle. This does not change memory usage in worst case.

Dropping the number of wasted bitplanes can actually make things a little better. In the Pi project you do this with kBitPlanes at compile time. The run time is used for other things, but kind of worthless unless you are careful. You can do at least two kinds of voodoo with the runtime system but its better to just drop them at compile time.

[daveythacher]

Your question about the difference between BCM and PWM. BCM divides the duty cycle across the period. PWM does not. This division allows for a few computational and memory differences. The period does not change only the duty cycle.

Some code bases risk corrupting the duty cycle by modifying the period and the duty cycle together in BCM. This does not lead to significant corrupt in some cases. You can rescale it if you want, but this only useful in certain cases. This is that runtime system I was mentioning.

They fight to keep the refresh rate at a fixed rate. They do this by using the multiplex and refresh to create period. They then can use a timer to on the frequency. All bitplanes must be sent within that time. If some bitplanes are causing issues which in this case is likely the least significant ones they can be dropped to get back on target. The issue with some implementations is they do not know the serial clock rate therefore computation is complicated.

The issue with the run time system is computation. With compile time this is handled for you. You go from one configuration state to another potentially mid frame. It's a nightmare, but as a feature it could be useful to use. However it is likely intended for other things.

[daveythacher]

In BCM/PWM example numbers I actually use a 300Hz refresh rate...that may confuse people.

[board707]

Hey, David. Thank for your answers.
Sorry, but your reasoning regarding to memory seems to me out of touch with reality. Let's start with the fact that the size of the required memory has nothing to do with the refresh rate. As we update the picture 200 times per second or 20 times - we send the same buffer to the matrix. And from this point on, all your subsequent calculations are wrong.

The amount of memory required depends only on the number of pixels and color depth and is calculated as follows.

((Width * Height ) / 2 )  *  shifts_number

For BCM mode with 24bpp we need 8 shifts per color.
Thus, for 2 panels 64x32 and 24bit color, only 16kb buffer is required with single buffering.
This number does not depend on whether you connect two matrices in a chain or update them in parallel.

Thanks for discussion.

[daveythacher]

No say senor.

[board707]

I'm sorry I didn't mean to be rude. These are my problems with English. I just wanted to say that your calculations do not seem correct to me.
Sincerely
Dmitry