2
\$\begingroup\$

I'm trying out logic analyser with digital clock I have laying around. The clock uses 7 segment display (4 digits) and consists of two parts: display with unknown chip inside and main board with two chips with no markings. There are 4 wires between the two parts, 5V, GND and two unknown.

I was wondering if it would be possible to decode the signal sent through those wires and see if I can plug it into an arduino to control that display. But I have no idea where to begin identifying the protocol, assuming it is something standard like i2c or UART. From the picture below it doesn't seem like neither of two lines (D1, D2) could used for clocking so it probably isn't i2c. Also D1 doesn't seem to be used by the main board as it is low when display isn't plugged in, so I'm assuming that these are RX (D1) and TX (D2) lines, however UART decoder doesn't seem to show anything particularly useful. Does my guess seem correct or does it not look like it could be UART at all? If that's UART, how do I figure out appropriate baud rate to decode this?

I also wonder if it would be possible to just guess what chip is used to control clock display, it doesn't seem to be MAX72xx which I believe would have 5 wires and I couldn't find many other chips on the internet

enter image description here

[Update] adding more pictures with SPI decoder as was suggested in the comments

single group of bits, what looks like 17 bits of data enter image description here

zoomed out, unsure why some groups were joined together by the decoder, they don't seem to be closer in time and look very similar to me in general enter image description here

further zoomed out view enter image description here

\$\endgroup\$
1
  • 1
    \$\begingroup\$ D2 definitely looks like clock. Most likely SPI \$\endgroup\$
    – Eugene Sh.
    Feb 13 at 16:50

1 Answer 1

1
\$\begingroup\$

There are a number of display driver chips which require only clock and data lines. For example, the GN1640 by GN Semiconductor, also made by Titan Semiconductor as the TM1640.

Your traces look like typical SPI-like serial output in 8-bit chunks with some delay between chunks, but there is probably some other quirk of timing or data flow that establishes framing.

\$\endgroup\$
11
  • \$\begingroup\$ sorry if the question is too stupid, but isn't clocking line supposed to emit equally spaced signals non stop? \$\endgroup\$
    – Leo
    Feb 13 at 23:57
  • \$\begingroup\$ @Leo Not a stupid question. If you look at the Titan datasheet you can see that they're not equally spaced. They also can (and usually do) pause between bytes and between groups of bytes because of the way the hardware works on the MCU. You would only send commands and data when there is a change in the display- that's one advantage of a display driver chip- the MCU does not have to continuously send segment patterns every ms or so. There's no minimum clock frequency in SPI or similar protocols. \$\endgroup\$ Feb 14 at 1:39
  • \$\begingroup\$ Note also the way that Titan does the framing- the data line goes low while the clock is high, which should not otherwise occur during the sequence (you should change the data only while the clock is low). The non-framing part probably corresponds to one of the four SPI modes that are generally supported, then some bit diddling for the framing. \$\endgroup\$ Feb 14 at 1:39
  • \$\begingroup\$ @Leo, actually one benefit of using a communications clock is the communication timing can be altered to suit the master device (transmitter) and target device (receiver), as Spehro says. The comms clock doesn't have to be tied to the clock from, say, a free-running oscillator module. From the master's pov, it's just another output that it can drive and toggle when it needs to. It's nearly always when the comms clock edges occur, and the sequence they occur in, that signals something. Recommend a read-up on synchronous serial comms and on SPI, loads of free detailed info on the internet. \$\endgroup\$
    – TonyM
    Feb 14 at 8:55
  • 1
    \$\begingroup\$ @Leo, I think you've got to get away from seeing a communications clock as being from an oscillator and then you'll see it better. A comms clock indicates the timing of the associated bus signals, in this case (most likely) a data line. In many/most protocols, it's just another signal from a control circuit that can go high and low as the bus master wants so long as it meets the spec' mins. Forget seeing it as a square wave from an oscillator, it'll give you a much clearer perspective on what it is and does. \$\endgroup\$
    – TonyM
    Feb 17 at 21:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.