Support for SM-PWM (SM16169SH)

[psyirius]

Hey guys!

I'm new to these led wall stuff. But i've been tinkering stuff for ages.
Been on the software (Reversing) land for years and just started tinkering into a digital hardware and FPGA's.

I know very little in this domain. So, please bear with me.

I used this lib to do a clock project using an custom esp32-s3 based pcb with level shifters similar to HD-WF2.
Been used to do this with some old QiangLi modules which used to have Conventional type drivers.

Starting this year I've been getting modules with SM-PWM type drivers which this lib doesn't support.
I'm not even sure if an esp32 is capable of driving this kind of drivers.

Here is my issue in the esp32 PWM repo mrcodetastic/ESP32-PWM-MatrixPanel-DMA#2

Having those modules lying around for a month like a bunch of bricks.

Finally got a Huidu receiving card (HD-R712) and a sender box (HD-VP210A).
After some struggles I finally configured it correctly to work with the receiving card and sender box.

Now I'm waiting for the logic analyzer (cheap $5 Saleae 8CH clone, not a big-hat to afford the real Saleae) to arrive to intercept the signals and bring this SM-PWM to light. Not Sure if these cheap 24MHz logic analyzers will be able to capture the data. But, On my way to try. Hoping it arrives soon.

PS: IDK anything about PWM or the inter IC protocols.
But, I'm trying my best to uncover this mystery protocol.
So that I can make those bricks back on the loop.

Hey @mrcodetastic @board707 or anyone interested
If you guys need any details regarding the signal sequences that the FPGA outputs to the modules.
I also have plans to trace and reverse other type driver protocols.

Already tries to reverse their FPGA firmwares. Not much luck.

Give your inputs.
Every input is appreciated :)

[board707]

I'm trying my best to uncover this mystery protocol.

The problem is that this isn't a single protocol, but an entire class. Unlike сonventional type panels, almost every SM-PWM type driver has its own unique format. Numerous attempts have been made to read and decode it; you can find impulse diagrams for some drivers in the thread.
For some drivers, the protocol had not only been decoded, but libraries have already been written for them. But until there is not a general solution, decoding individual drivers does little.

[mrcodetastic]

Supporting SPWM panels with this library is like trying to replace an Apple with an Orange. Totally different behind the scenes, except for the fact they're ultimately outputting a grid of pixels to the human eye.

I have a separate git repository where I wrote example code to drive one specific model of PWM panels I was given as a donation. Whilst I thought I could re-use this library and just 'hack it', that turned out to be totally wrong, and I ended up writing something completely from scratch given these PWM panels work completely differently.

https://github.com/mrcodetastic/ESP32-PWM-MatrixPanel-DMA

[psyirius]

I might get different types of led modules from time to time.
If I succeed in this, I'll try my best to keep a doc of how each of the drivers expects data if time allows.

[mrcodetastic]

Again. I suggest seeing if my code, if you hook it up to one of these panels, produces any output, even if a garbled mess.

If so, then it's a matter of figuring out the configuration register settings - and as these are the first things to be sent 'over the write' to the panels on power-up, it will reduce the effort required to reverse engineer, substantially.

I wrote an example for a MBI5153 PWM chip

[mrcodetastic]

Worth reading this document on how the MBI5153 PWM chip works as no doubt this SM16169SH works similarish.

https://github.com/mrcodetastic/ESP32-PWM-MatrixPanel-DMA/blob/main/MBI5153/docs/1809172050_MBI-MBI5153GP-A_C183654%20(3%20files%20merged).pdf

Specifically the config register pages etc. How data is clocked into these chips.

[board707]

Whilst I thought I could re-use this library and just 'hack it', that turned out to be totally wrong, and I ended up writing something completely from scratch given these PWM panels work completely differently.

Very interesting.
I didn't know you wrote a complete different code for it. I think I have to study this repo.

Reading the Readme, I think it should be especially noted, that the main difference between PWM and old-style drivers is the fact that former has on-board memory enough to store a complete panel pixels with 14-16 color depth. This eliminate the needs to refresh the data in panel buffer every scan as it required in old-style drivers.
Excuse my bad English.

[psyirius]

Whilst I thought I could re-use this library and just 'hack it', that turned out to be totally wrong, and I ended up writing something completely from scratch given these PWM panels work completely differently.

Very interesting.
I didn't know you wrote a complete different code for it. I think I have to study this repo.

Reading the Readme, I think it should be especially noted, that the main difference between PWM and old-style drivers is the fact that former has on-board memory enough to store a complete panel pixels with 14-16 color depth. This eliminate the needs to refresh the data in panel buffer every scan as it required in old-style drivers.
Excuse my bad English.

Hey! @board707

Are you willing to take a look at the signal traces?

Previously i was able to drive the modules in a low refresh rate replaying the captured trace using esp32 (direct gpio - not dms - thus the low refresh rate).

Suddenly, after a day when I'm trying it again nothing works.
Not sure what i messed up.

I can help with test mode traces captured from a controller that is configured to work with this module.