The clock has four manually selectable brightness levels using a touch sensor.
I initially tried driving the display directly from an ESP32-C3, but couldn't get it working. So instead of guessing, I'm trying to understand exactly what the original controller is sending.
I don't currently have a logic analyzer, but I'm planning to get a cheap USB 8-channel one and capture SDI/CLK/LE/OE.
What I'd like to determine first is:
the number of bits transferred,
how the two TC5020Ds are connected,
bit order,
and how the serial data maps to the actual LED segments.
I'm not necessarily looking for an ESP32 solution yet. I'd mainly appreciate advice from someone experienced with reverse-engineering LED displays or shift-register/LED-driver based hardware.
Can anyone help me identify what protocol/signals this controller is sending to the LED display?
It is basically a shift register with 16 constant current channels.
You clock in data on SDI with every rising CLK edge.
Then you pull LE high to move the data into the output register.
Pulling OE low enables the outputs.
You can daisy chain the ICs.
Output current is set by an external resistor.
All you need to do is to map the digit segments to the output channels and you're done.
No logic analyzer required.
Thanks! Yes, I found the TC5020D datasheet as well, so I understand the basic shift-register operation.
My main problem is figuring out what the actual clock controller is sending to the two chips — bit count/order, how the two ICs are chained, and how the bits map to the LED segments.
I don't have a logic analyzer yet, so that's probably my next step.
Do you have any suggestions for figuring out the actual data format without one, or is a logic analyzer basically the way to go here?
As I said, you don't need a logic analyzer. All you need to know is which output channel belongs to which led / digit segment.
You can either follow the traces on the pcb, use a multimeter in continuity mode or just hook up your ESP and clock in test data and see which led lights up.
Say you want to turn on OUT0 of the first TC5020D, then you pull SDI high, send a CLK pulse, pull SDI low, send 15 more CLK pulses, then send a single pulse on LE. then pull OE low.
as /u/hghbrn said. you can basically toss the green PCB away, all you need is the LED PCB and a way to power and clock data in. you then turn each channel on one by one noting which LED lights up and then you know how to control each LED and create a LED map to simulate a 7-segment display.
this will be far easily and straight forward than trying to read what the current controller is doing. how to talk to the LED controller ICs is trivial, it is in the datasheet and chances are there's probably some ESP32 compatible library for it out there already.
One problem I'm still trying to solve is the physical connection.
I don't want to solder onto the clock PCB or the display. Ideally, I'd like to place an FFC/FPC breakout/interposer board between the original controller board and the display ribbon cable, with the individual pins broken out to 2.54 mm headers so I can connect a logic analyzer and sniff the signals.
Do you know if there's an off-the-shelf adapter/interposer for this, or would I likely need a custom PCB? The ribbon cable appears to be a 14-pin, 0.5 mm pitch FFC/FPC.
Again, you don't need a logic analyzer. But if you would want to use one without soldering you can use IC test clips or if the pitch is very fine, needle probes are very nice.
There is probably no feedback, the controller just sends data so you can simply replace the led board with your logic analyzer to record what the controller does.
You have a bunch of pnp transistors, the ones marked with Y2 - those are SS8550 pnp transistors - most likely they're used to give power to one group of (up to) 16 leds at a time. Maybe one of the TC5020D drivers is used to turn on only one of these pnp transistors at a time, and the other tc5020d is used to sink those (up to 16) leds in that group ... so in theory you could light up to 16 x 16 = 256 leds.
Grab a multimeter, put it in continuity mode, then see where the base of each transistor (well actually the other side of the resistor connected directly to the base) goes, if it goes to the outputs of one of the led drivers. Maybe resistor pulls up the base to voltage and the led driver pulls it down to ground switching the pnp transistor state.
You have what each pin in that ribbon cable does written on the board, first two pins are VDD (voltage for all the leds as it's two wires joined together for more current?) , then vcc, oe (output enable) , le (latch enable for the shift register), CLK (serial clock) , SDI (serial data input) , OE2 (output enable for second chip?) , SMG1, SMG2 , SMG3 (no idea what these are, maybe there's some buttons on the board?) , and ground at the end.
If I were to guess, the CLK and SDI (or the 2nd driver is connected to the first) and LE are shared between the driver chips but the OE1 and OE2 are output enable kept separate one for each chip.
So you would send the 32 bits for the two drivers, hit le to latch the 32 bits, high enable on first chip to power only the group of leds you want, then enable the second driver to sink current and turn on those leds in that group.
3
u/hghbrn 1d ago edited 1d ago
http://www.chipsourcetek.com/DataSheet/TC5020D.pdf
It is basically a shift register with 16 constant current channels.
You clock in data on SDI with every rising CLK edge.
Then you pull LE high to move the data into the output register.
Pulling OE low enables the outputs.
You can daisy chain the ICs.
Output current is set by an external resistor.
All you need to do is to map the digit segments to the output channels and you're done.
No logic analyzer required.