First, when we refer to “48 bit color”, this actually means 16 bitplanes. There are always 3 color planes per bitplane (RGB). That’s why you have to adjust the color depth in multiples of 3.
For SmartMatrix, we use BCM (binary code modulation) in addition to PWM on the OE (Output Enable) pin. That allows us to control the brightness of each bitplane very finely. Each bitplane gets an independent OE duty cycle.
When the driver is operating near its maximum frequency, the LSB bitplanes are data bandwidth limited and they take the same amount of time to output to the panel. Then the OE signal is modulated simultaneously so the apparent brightness is doubled for each successive bitplane. We are not dropping bits - generally we are able to achieve good bit accuracy up to 16 bitplanes. By default the PWM timer clock frequency is 75 MHz on Teensy 4 so there’s plenty of resolution.
Adjusting the OE duty cycle is also how we are able to achieve panel dimming without losing accuracy.
For a 128x64 display at 18.462 MHz clock (Teensy 4) the theoretical maximum rate to clock one bitplane to the whole panel is 4507 Hz as sutaburosu correctly calculated. With extra overhead for the latch pulse, the max available rate is closer to 3600 Hz. With 36 bit color depth, there are 12 bitplanes so the max frame rate is 12 times smaller = 300 Hz. (The 340 Hz number was from older code that used less overhead and a faster clock, but was less reliable.) In this scenario, the speed is so high that all 12 bitplanes are bandwidth limited and each takes the same time to display, so all of the brightness modulation comes from the OE PWM.
Max speed does come with a drawback, however: the maximum brightness will be much lower, since the OE modulation will be keeping the screen dark the majority of the time. You can get much better brightness by either reducing the frame rate or the number of bitplanes. I find that staying below about 80% of the max frame rate gives good results.
I should also note that sometimes the driver is CPU limited instead of bandwidth limited, so the maximum achievable frame rate can be lower.
If you would like to evaluate the maximum refresh rate for your panel and color depth configuration, you can simply print the macro MAX_REFRESH_RATE which is defined in the SmartMatrix library here (assuming you’re running Teensy 4):
Right so yours works basically the exact same way as the Pi library does. I figured most of this out. I am curious if you mean 12 times slower or 2048 times slower? It is BCM after all.
You only get so much current division potential so your color depth gets limited here by LEDs and gamma. Color depth drives gamma, which with multiplex increases the current divisor. To a point where the LEDs may not function.
8 bits input gets converted to 11 bits CIE1931. Multiplex adds 1 to 5 more bits. 8mA divided by 65536 is 122nA. I can only see it barely in the uA range. Maybe some LEDs are really good. Using 16 bits for gamma on 32 scan panels would be 3.8nA. More useful in low scan panels.
PWM hardware would improve chain length but adds cost. Hence why they are used in high density panels. S-PWM is a neat refresh trick which trades frame rate for color depth. Frame rate is missing in all of this.
Edit:
You meant to say 2048 times. I looked in the code and found it. It does the same thing as the Pi library. Well hidden here too.
Ideally, the least significant bitplane time would be 1/2048 of the most significant bitplane for 12 bitplanes, but at high frame rates this is not possible. Instead, what limits the frame rate is the minimum time to output one bitplane times the number of bitplanes (12, not 2048). The 75 MHz PWM signal applied to the OE pin is able to reduce the brightness for the least significant bitplane beyond what is possible for BCM. So the actual brightness is in fact 1/2048 even if the time is 1/12 of the total.
I do agree that using 16 bitplanes is overkill - the lowest bitplanes will likely be imperceptible. I think 12 bitplanes provides equal perceptual quality.
So if you wanted to know the max color depth you can get with traditional PWM here it is:
Serial_Clock / (columns * multiplex * refresh * 2^(color_depth)) <= 1
If we consider 280Hz on 64x128 with 18.4615385MHz we get 4 bits color depth. Now this will have decent gamma accuracy (93.8 percent accuracy assuming linear). However the color depth is 6.25 percent of 8 bit input.
S-PWM on CC drivers would enable a different formula, here is one example:
Serial_Clock / (columns * multiplex * 2^(color_depth)) <= 1
If we consider 64x128 with 18.4615385MHz we get 11/12 bits color depth. Now this will have great gamma accuracy and full color depth. Refresh would be something like 2-4kHz.
FPS throws a wrinkle into this. Here is one example:
Serial_Clock / (columns * multiplex * 2^(color_depth) * fps) <= 1
So 30 FPS lowers the color depth down to 6/7 bits while the refresh stays at 2-4kHz. Color depth here is reduced quite a bit. Gamma accuracy is still somewhat decent.
As I mentioned before even with a PWM/MM LED driver you may not even be able to get certain color depths. You would want to use them in low scan panels which will drive up the cost and cause an issue for the color depth due the distance you would have to view it from.
PWM and MM drivers are more efficient serial protocols so they enable higher quality for longer chains with few chains. CC panels need to use multiple chains to support high quality. Most people can probably get by with CC panels running S-PWM. Many can get by using traditional PWM on CC panels.
Note I mostly ignored the effects of multiplexing.
BCM is better in terms of memory usage and processor usage. It has some possible signal issues possibly which standard PWM does not have. You can use BCM with S-PWM, but it is a little weird.
The timer protects scheduling and bus issues in Pi. The timer in both protects the refresh rate. However the serial bus can prevent this. There is a possible brightness collapse in both.
Both of these are designed around high FPS systems. If you notice the difference between min refresh (100Hz) and 30 FPS for video is only a factor of around 3 which means about 2 bits of color depth. Moving from 100 to 280Hz only adds about 3 bits.
S-PWM gets a few of those bits back in theory. In the case of 280Hz we are talking about 8 bits for one frame per second.
Edit: (Take with grain of salt)
Max color depth due to current is 2048/4096or 11/12 bits.
Max color depth due to 32 scan multiplexing becomes 64/128or 6/7 bits.
Overhead for CIE1931 is about 8:11 so max color depth becomes 4/5 bits of color depth.
Therefore for the max color depth for 32 scan panel is about 6.25/12.5percent of input.
The max color depth for 8 scan panel is about 21.8/36.5 percent of input.
The CIE1931 is more of a guess. However PWM/MM drivers mostly increase the chain length and cost rather than improve quality per say.
Sparkfun 32x64 panel lists grayscale at 16.7M which could mean 8 bit per color. Which if you factor in 16 scan you get 4096. Now if you assume current for R/G/B is something like 16/9/7 this looks somewhat reasonable.
Adafruit’s 16x32 lists color compatibility at 16.7M which would mean 2048, which again is reasonable. However they list their grayscale at 16 bits per color, which does not seem reasonable unless this is for gamma correction without color depth.
Some of the datasheet numbers are little bit of mystery. However if you dig they can start to add up.