FM6126A Hardware Brightness Control

[mrcodetastic]

@vortigont - Raising an issue to track your inital investigations into the FM6126A registers.

Can you send a link to one of these panels you bought - it would be interesting to get one of these and also start randomly bit-banging the control registers to see what happens.

If the FM6126A's have hardware brightness control, then that pretty much makes the PWM based brightness redundant - or could be used in combination to massively increase color depth.

I'm also curious as to how fast these registers could be bit-banged, as I might explore the possiblity to embedding the control stuff as part of the DMA buffer itself as well.

[vortigont]

yep, I'm thinking about the same! Was unable to find any existing implementation for any of 6126 features so far. And as I see it brightness control is not too hard to implement.
More to this! If I understood poorly autotranslated Chinese specs those chips has TWO regs inside - one shift reg and one buffer reg. So it is possible to pump new data through shift register while LEDs are emitting an old one! Just imagine - it could drastically increase overall brightness and/or reduce flickering. I bought those about half a year ago, didn't had time to play with it until now. I'll dig through my purchase history and update you soon.

[mrcodetastic]

So it is possible to pump new data through shift register while LEDs are emitting an old one! Just imagine - it could drastically increase overall brightness and/or reduce flickering.

I did get excited about this bit as well, but from memory I think this is how all HUB75 boards work - in that you can latch in data to a line whilst output is enabled for the previous line. Unless of course it's possible to have OE enabled for every single row at the same time which would be a game changer (but potentially use a humongous amount of power having all LEDS lit).

Also super curious as to what secrets REG2 has in store. Only 65536-1 possible bit combinations to find out ha!

[vortigont]

nah... there are only 12 chips per 32 rows (24 total), so 12 chips drives one single row of RGB's. Well, maybe I got the whole idea wrong, their datasheet is quite confusing in translation. Looks like they suggest some kind of data-interleaving per chip (16 bit word) not sure. But at least brightness control would be nice feature :) Need to spend some free time playing with it. BTW, here is lot I've bought in June. Although it looks the same on picture seller could have changed the pannels any time. Will try to contact him and ask about if it is still FM6126A based.

[daveythacher]

I have never seen this documented. One person randomly documented bits in the control registers in another project, but never explained them. It looked a little disorganized. I tried looking through FPGA sender/receiver cards and I was never able to find the answer. Most of the datasheets omit it. They mention if you translate or find a translated one. They mention the commands for the control registers, but not the registers.

It is a shame as these would be nice to have for lower power applications. You can get a similar result with the OE or bandwidth division. These are not available on the Pi for long chains or for high quality. Many panels break down when not driving at 5 volts. The software gain control inside these drivers would allow you to correct this in software. They appear to not like signal/power instability, but that is pure conjecture.

I semi-explored this for my own project, but it looks like I will have to do something custom for myself. Which is much more expensive. Story of my project thus far.

There is a few Memory Mapped drivers which have this function and documentation exists for a few of them. However that interface is a topic in of itself. They tend to appear in high density panels. They are not overly well documented either, but enough information does exist to probably prove them out. They have a few quirks which are explainable.

[DarrylStrong]

yep, I'm thinking about the same! Was unable to find any existing implementation for any of 6126 features so far. And as I see it brightness control is not too hard to implement. More to this! If I understood poorly autotranslated Chinese specs those chips has TWO regs inside - one shift reg and one buffer reg. So it is possible to pump new data through shift register while LEDs are emitting an old one! Just imagine - it could drastically increase overall brightness and/or reduce flickering. I bought those about half a year ago, didn't had time to play with it until now. I'll dig through my purchase history and update you soon.

Most LED drivers have this setup, the Strobe copies the data from the shift register to the output latches. This means that the LED outputs can be live all the time without the need to turn off during updating.

My company makes it's own LED display PCBs using 74HC4094 shift registers driving ULN2003 high current drivers, we also use DM134 drivers from Silicon Touch. Both of these use the same architecture with a shift register and then output latches.

Back a few years (probably about 30!) we used a different architecture that required turning off the multiplexing transistors during updates, that meant that for larger signs which required more data to be sent on each scan the brightness suffered.

I looked into the memory mapped drivers a while ago but the shift seems to be towards moving the 'intelligence' to the controlling circuitry rather than the display boards themselves.

[daveythacher]

I looked into the memory mapped drivers a while ago but the shift seems to be towards moving the 'intelligence' to the controlling circuitry rather than the display boards themselves.

This only works for specific reasons. Memory mapped is much better for serial bandwidth and can reduce cost and complexity. It can make programming simpler also. However they are more expensive. There is a break even cost of the cost increase per panel versus controller cost. All against panel size, performance and quality.

There is a lot of ways to do memory mapped drivers. I have seen people use SRAM cells. I have considered using tons of tristate driver banks, which is not cheap. Memory mapped reduces the number of high speed serial signals required. Many support PWM generators which require redundant circuits for GCLK. They pass this back to main controller or logic on panel.

These GCLK signal forces certain things which are less ideal. It could be possible to make a chip were GCLK is handled independently, but this would increase cost per chip. They could make IC for panel which avoids this, however this may have still been too costly. Many of the LED panels you buy are actually designed for FPGA controllers not MCU/MPU.

The Pi for example is not very well suited for GCLK based drivers, but could be supported somewhat. It just may not make much sense over shift registers running BCM. However for some applications if external logic solves the GCLK issue it could work or be better. However this is very specific usages, which likely are specific usages no matter what.

In summary memory mapped panels are nice, however there implementation can be a pain. I remember working with HT16K33, I was up and running in no time. Software model was very flexible. BCM has never been able to give me that. Even if I clean it up with DMA to some interface hardware. Down side there however is cost, PWM, number of colors, I2C, etc. However for 7 segments and small dot matrixes these are amazing.

Edit: You can retrofit the memory map, which the FPGA controllers pretend to be most of the time. They use a sender and a receiver card. Again its a numbers game.

Edit: LED Matrix is memory mapped by definition. It is a multiplexed just like a ROM. You show a specific section really quick and deterministically. Memory cost is a hidden factor in larger panels for controllers. (Memory Mapped drivers can make this stupidly large if you compute the max chain length for sub 1 FPS.) This is one area where the Pi makes a ton of sense. However using the CPU for IO still does not. It is cheap and supports up to 3 connectors with at least 50 percent connector bandwidth. However due to processor design it is not completely stable like a controller. There are tricks like DMA which work for initiators to targets, which this is, that work. Most of these are not available on the Pi however it is possible on platforms like the Pi. It is even possible on the Pi if you reworked it internally.

[vortigont]

@daveythacher, man, how did you found it?! :) I was poking the reg values measuring current draw with an amp meter and I saw that some bits were actually decreasing power consumption, but won't able to find the exact proportion. Now it makes sense. Knowing this it could be possible to implement HW brightness fort those chips at last.

[mrcodetastic]

Fantastic work @daveythacher. I installed the software per your guidance and have had fun seeing the register values change accordingly.

I note that there seems to have been some work performed to reverse engineering this else where as well - but we have a formula to bake REG1 values into these panels now. Excellent.