Author Topic: LED Sign Repair (Read 13534 times)

cponcsak · « **on:** December 24, 2015, 08:51:11 pm »

Hello all. Long time lurker, first time poster here. First, let me say that this forum has been a huge source of information for me and I want to thank everyone for the effort that they put in here. With that said, I'm hoping someone can help me.

My task is a fix a controller circuit for an LED clock. The controller is working but will randomly change the time ahead or back by different amounts so I need to come up with a new one. At the moment, I only have the controller in my possession and I have no clue what is on the other side of the wire. The communication between the controller and the sign itself goes across an RJ45 plug where it is only using 4 wires from the ethernet cable. I need to identify the protocol that the controller is using to communicate with the sign above.

The data is being run through a DS26LS31CN quad high speed differential line driver, which TI lists under RS-422 transceivers so I'm going to assume that's what the protocol is although I'm not familiar with it. (Data Sheet: http://www.ti.com/lit/ds/symlink/ds26ls31c.pdf )

Once I identify the protocol, it should just be a matter of seeing what the controller is sending out and reproducing it with a new one. The large 9 pin plug on the board is for attaching an external GPS and temperature sensor.

I've attached pictures of the controller (and some irrelevant ones so you can marvel at their engineering) as well as the captures of the patterns for the clock and each of the other wires. I wish I could have had them all up on the screen but at the moment, I'm using a 2 channel scope. Please let me know if I am way off base with this line of thinking or they are using some completely proprietary method.

cponcsak · « **Reply #1 on:** December 25, 2015, 03:08:50 am »

Whoops, I had made a mistake when measuring it. Out of the four wires, there are two pairs of signals coming out of the differential driver. I've attached updated shots to this post. This should be much clearer than the last shots.

siggi · « **Reply #2 on:** December 25, 2015, 05:32:19 pm »

Looks like synchronous serial to me. One line is clock, the other is the serial output. There's a clustering of 8 clocks, is there a longer period between repeats (like 1s maybe)? Try and decode like SPI, compare a couple of blocks to decode the format.

NB: It's not super helpful to show captures at two different time bases.

Sent from my iPad using Tapatalk

cponcsak · « **Reply #3 on:** December 25, 2015, 06:07:10 pm »

I've attached a shot of the two signals side by side. It sends out pulses of data at 1 second intervals.

I will attempt to decode it using your method. Thank you.

SL4P · « **Reply #4 on:** December 25, 2015, 06:44:30 pm »

Quote from: cponcsak on December 24, 2015, 08:51:11 pm

...The controller is working but will randomly change the time ahead or back by different amounts ...

I suppose you've checked the NVRAM / clock battery in the large black package?
If everything else seems to be working - except the time is jumping around randomly, that would be the first place I'd be looking.
Then of course - as you have stated, to identify the parts of the circuit (in the controller), and (in the display) modules.
If the small 7-segment displays on the controller are used to 'set the time'... do they jump around as well? or only the main remote display? etc etc that may help isolate the issue as being before or after the comms link

cponcsak · « **Reply #5 on:** December 25, 2015, 07:14:20 pm »

The controller went back to the manufacturer a few weeks ago and they couldn't get it to reproduce the problem, and claimed they replaced the "chip". Like-wise, I've had it for a few days and it hasn't drifted in time. Even in the sign, it was keeping time for days up to weeks. Every time it would drift, they would need to go out and reset it so I assume the display on the controller was out as well. They never mentioned anything about the time simply stopping so I don't think its a communication problem but I will check with them. Christmas makes getting any information difficult for a few days. I tried contacting the service tech at the manufacturer that personally worked on the controller but he was little help. He didn't know how the boards communicated, what the pin-outs were or remember what they did with it when it was in. He offered to look for design docs on the unit but I have a feeling I'm not getting those either.

Honestly, its an old, over-engineered piece of garbage. The RTC package they use is obsolete and complete overkill for what it needs. I'd just as soon gut the entire sign and stick an arduino in there with an RTC. The size and height of the sign make it difficult to do anything with the panels themselves and the fact that its winter greatly complicates things. I'm just doing this as a favor to get back into electronics as I haven't done anything like this for years and even then it was mostly tinkering. If I'm not able to come up with something to interface with the existing hardware up there (whatever it might be), it may just have to wait until spring for a complete gut job. I think they are keen on keeping the display as-is for nostalgic purposes but that doesn't mean we can't retrofit the back end.

siggi · « **Reply #6 on:** December 25, 2015, 09:39:22 pm »

Quote from: cponcsak on December 25, 2015, 06:07:10 pm

I've attached a shot of the two signals side by side. It sends out pulses of data at 1 second intervals.

I will attempt to decode it using your method. Thank you.

Cool. The length of each pulse train will be your second big hint. This'll be a binary time stamp, an ASCII sequence or a bitmap, I'd say.

Sent from my Nexus 5 using Tapatalk

SL4P · « **Reply #7 on:** December 25, 2015, 10:56:42 pm »

Quote from: siggi on December 25, 2015, 09:39:22 pm

Quote from: cponcsak on December 25, 2015, 06:07:10 pm
I've attached a shot of the two signals side by side. It sends out pulses of data at 1 second intervals.

I will attempt to decode it using your method. Thank you.
Cool. The length of each pulse train will be your second big hint. This'll be a binary time stamp, an ASCII sequence or a bitmap, I'd say.

Yep, I'd almost guarantee it's a bitmap, with simple shift registers in the display panel.
Unless one controller can drive multiple different display formats simultaneously... That would need more smarts in the display.

cponcsak · « **Reply #8 on:** December 25, 2015, 11:13:35 pm »

This will have to be put on hold for a few days. I've traded the Siglent scope in for a Rigol DS1054Z which wont be here until Tuesday/Wednesday. Everyone seems to like that one so it's probably worth the upgrade.

I've attached a picture from google maps of the sign in question. Its double sided so there is the same panels on the other side. I'm not sure why the google car captured the display like that, it does work fine in person.

I'm a software developer by trade so I really appreciate you guys helping me through the hardware aspect of this.

SL4P · « **Reply #9 on:** December 25, 2015, 11:40:37 pm »

The reason for that image, is because the LED columns are being (scanned) multiplexed faster than the eye can discern.
This will help you understand (the bitmap if that's the case) when it comes to decoding the display data (if that's what the data is).

EDIT: spelling too fast!

siggi · « **Reply #10 on:** December 26, 2015, 01:41:14 am »

You may want to grab something like the bus pirate to decode the bit stream. The Rigol will only decode what's on screen (I understand).

So the sign looks like it might be 7-segment, or possibly an 8x16 bitmap. Worst case it randomly assigns bits to LEDs. Given the engineering on the controller board, the last unfortunately seems like a possibility...

Sent from my Nexus 5 using Tapatalk

cponcsak · « **Reply #11 on:** December 26, 2015, 02:14:37 am »

That is a really neat device. There doesn't seem to be a lot online about it other than being able to buy it. Do you know if the upgrade from v3.6 (~$30) to v4(~60) is worth the extra $$$? If you are already getting to that price point, would it be better to just get a basic logic analyzer? The software for those seems to be able to decode most protocols as well and I think being able to actually see the signal patterns along side its decoded data might be more useful as a learning tool.

[EDIT] I put an order in for v3.6, from what I could tell the v4 is still very much experimental and would have very little for added benefits for me. Found a Canadian supplier so hopefully it doesn't take long to get here.

obiwanjacobi · « **Reply #12 on:** December 26, 2015, 05:43:54 am »

That big connector on the back is (also) for powering the LED display?

If so, load down the supply and see if the supply voltage drops. (thou shall measure voltages)
After that, MCU clock stability, MCU reset line, backup battery and external bus integrity.

cponcsak · « **Reply #13 on:** December 26, 2015, 06:22:43 am »

The display is controlled by a separate controller [EDIT: driver, not controller] and powered independently. The large 9 pin plug is for connecting sensors for auto-dimming, temperature and GPS. I have attached the pin-out and complete manual for those that are curious. The manual contains almost no technical information but does include steps for performing lamp checks and things like that which should be helpful in debugging the output.

SL4P · « **Reply #14 on:** December 26, 2015, 06:28:47 am »

I'm kinda more confused now than I was at the beginning!
I wish I was there standing next to you - i would be a lot easier to identify, assess and poke around!

cponcsak · « **Reply #15 on:** December 26, 2015, 06:33:15 am »

I hear you there. I wish it wasn't -30 outside and the displays weren't mounted 20 feet in the air. The manual references a model AD101 or AD64 Lamp driver which the controller is connected to. I misused the word controller in my last post. This is the only controller and the other unit is the lamp driver. I don't know what that unit contains or how "smart" it is which is why I'm stuck trying to decipher the protocol. It must be sending more than just a bitmap though because it would also need control codes to control the brightness. We will have to see when the new scope or bus pirate arrives.

SL4P · « **Reply #16 on:** December 26, 2015, 06:41:22 am »

Yep - I'd guess there is a set of n-bits shift register for the rows, and another for the columns with a latch of some sort. The data is clocked in to the LEDs for a single column, then the horizontal bit stepped to the appropriate column - and the latches clocked to the outputs for nn millisecs for display.
The process is repeated for each column, and then started again to re-scan the whole display repeatedly.

Many LED signs do it the other way around - shift all the column bits across for one row, then latch the display for that row, and step on to the next row etc.
The advantage is a higher duty cycle for each LED (e.g. scanning 1/8 rows vs 1/64 columns).

There may be other tricks at play .i.e. the three sets of columns as lit in the photo... but a starting point.

cponcsak · « **Reply #17 on:** December 29, 2015, 10:45:24 pm »

New scope arrived today and now that I have more than two channels, this is what I've found. Its actually modulating the clock along with the data. The micro is an AT89S52, data sheet below.

http://www.atmel.com/images/doc1919.pdf

Channel 1 is what is coming out of the TXD pin on the micro, channel two and three are what ends up going out of the controller after the signal being cleaned up and pushed through the differential driver. I'm still waiting for the Bus Pirate and hopefully that will still come in this week.

SL4P · « **Reply #18 on:** December 29, 2015, 11:00:01 pm »

Ch1 (TxD) looks dodgy - The micro doesn't put out half-levels! I'd be looking for something that is shorted, or a faulty component that is pulling the 'slow' signal onto that pin.

Ch 2 & 3 are what I'd expect to see. Differential drive of a synchronous or SPI signal.
It look,s like a clock (the fast signal), and data (the slower purple trace).
As there doesn't seem to be any start or stop bits, I'd rule out a UART at first glance.

With 8 clock pulses per word (visible in the complete screen shot), that probably equates to 8-bit data being pumped to differential receivers and shift register over in the display unit.

cponcsak · « **Reply #19 on:** December 29, 2015, 11:08:59 pm »

Thanks for your insight. I'll try hooking an arduino to it and shifting the data in to see if there are any patterns.

cponcsak · « **Reply #20 on:** December 30, 2015, 02:41:46 am »

I decoded the serial data and can't find any pattern that makes sense. I tried running the 8 bit words LSB and MSB first but nothing logical came out. I'm going to see about getting the driver unit to hopefully provide context for the data. Worse case scenario, I completely replace the driver unit as well. I'll keep the thread posted with my progress and thank you for your help.

siggi · « **Reply #21 on:** December 30, 2015, 02:54:10 am »

What's the length of the packet?

Sent from my iPad using Tapatalk

cponcsak · « **Reply #22 on:** December 30, 2015, 02:59:15 am »

Total packet length is 35 bytes across 9.25ms

SL4P · « **Reply #23 on:** December 30, 2015, 05:01:03 am »

How many LED columns in the display?
if it's a 5x7 character matrix... 35 columns (without spacing) could be 7 characters wide...( 35/5 =7)

or if there is a character decoder in the display there could be (up to) 35 characters minus any control characters.

cponcsak · « **Reply #24 on:** December 30, 2015, 05:10:01 am »

The sign is 20x7. but only certain pixels are populated. It could still be a bit map but I don't think spending any more time on it without the LED driver module in my possession is worth while. I'll do a tear-down and take pics when I get it.


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: LED Sign Repair (Read 13534 times)

Share me