Author Topic: LED Sign Repair (Read 13536 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.

SL4P · « **Reply #25 on:** December 30, 2015, 05:17:11 am »

I think you're very close...
it sounds like a bitmap, and to prove or eliminate is not much more work!

cponcsak · « **Reply #26 on:** December 30, 2015, 05:51:20 am »

I had already cleaned everything up but your enthusiasm gave me a second wind. Got everything hooked back up and threw the controller into a lamp test mode. You sir, are correct. There are three words for what appear to be control codes and the rest of the data is all high.

I attempted to run through a packet and map it out by hand but there was no meaningful pattern. It's pretty late though so I could just be tired. I'll take another stab at it tomorrow. Bus pirate should help with this as well.

siggi · « **Reply #27 on:** December 30, 2015, 06:12:03 pm »

$5 says its byte per column. If you can decode 2-3 consecutive packets, I betcha it'll be obvious how the bitmap is arranged.

One thing is that there might be some framing, and even some bit stuffing, as there's no CS or the like to delimit frames. Best case the timing gives the framing.

Post your data if you get frustrated, the format might be obvious to someone else.

Sent from my iPad using Tapatalk

cponcsak · « **Reply #28 on:** December 30, 2015, 07:11:34 pm »

1byte per column would be the obvious way to encode it but their board construction was a clear indication that this wasn't going to be the case. I've attached a layout of the packet when the clock was displaying 12:26. The numbers in their are obvious but the position of them is inconsistent and there are duplicates. I had to decode this by hand using the scope so its the only one I have. I will have to put something more automated together using an arduino or wait for the bus pirate. I have separated the first three bytes off as those are likely control codes. Once I have a way to decode packets in bulk, it should just be a matter of running through a lot of them, confirming the layout and reproducing them.

SL4P · « **Reply #29 on:** December 31, 2015, 02:05:50 am »

I can see the 12:26 in your dump...
turn the image 90 degrees - voila! as in jpg2
the only oddity seems to be that the serial data is in a zigzag stream, rather than top to bottom or vice versa.

remember the flashing colon and any other indicators are in there somewhere.
The major hurdle is that you know there's no decoding in the display - just deserialise and render to the LEDs

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

Indeed. The numbers are still backwards because I was decoding it MSB first. Switch it to LSB first and the attached is what you get.

Any ideas on what the minutes being duplicated below that might be for?

SL4P · « **Reply #31 on:** December 31, 2015, 02:26:55 am »

not being familiar with your scope or the method of decoding etc.
the extra 29 may be some remnants unless you visually check the number of bytes total,

The (hours) 1 pushed up against the 2 is also puzzling - perhaps a column (byte) missed in the decoding by the scope. check the serial decoding parameters aren't looking for extra stop / parity bits etc... I think SPI mode will be closest.

cponcsak · « **Reply #32 on:** December 31, 2015, 02:34:14 am »

I went through and decoded the signal by hand, that extra data is certainly there. If those always match the minutes when I run through the packets in bulk, I'll just duplicate it and not worry about it. The extra data might be extra room for applications where this controller is hooked to a larger display. The sticker on the micro would suggest there are multiple versions of the firmware for different display sizes. As for the one being pushed up against the two like that, the sign only has a single column of leds for that number. It isn't capable of showing anything but a 1 or nothing.

SL4P · « **Reply #33 on:** December 31, 2015, 02:41:27 am »

ahh ok for the 1-2...
otherwise it looks like you're well on the way to new display/driver!

post a pic/vid when you get it done.

siggi · « **Reply #34 on:** December 31, 2015, 03:23:49 am »

Quote from: cponcsak on December 30, 2015, 07:11:34 pm

1byte per column would be the obvious way to encode it but their board construction was a clear indication that this wasn't going to be the case.

Dang it, there goes another $5. Good thing it's only CAD.

Sent from my iPad using Tapatalk

cponcsak · « **Reply #35 on:** January 06, 2016, 10:35:24 am »

Hello all, Just thought I'd do an update on this thread. I got the bus pirate in today and it seems to work well. There is a hardware limitation that only allows it to output hex when sniffing an SPI bus for some reason. I used putty to log the output to a file and wrote up a script that goes through and converts the data to binary bytes and splits them up into their 35 byte packet. Everything decoded well and as expected. The extra bytes of data at the end of the packet do just copy the minutes from before.

I hooked up an Arduino, membrane keypad and i2c LCD screen to act as the new controller and got everything working. I have it sending out a test packet for now. I'm trying to avoid having to rewire the sign so I'm waiting for an RJ45 plug to add to box. I ordered some differential line drivers but they wont be here for a while so I stole the one out of the old controller. Now for the issues(?). The Arduino is clocking the data out at a completely different speed and I'm not able to slow it down any more, only speed it up. I'm hoping this wont be a problem. The other issue is major line noise coming out of the Arduino and differential driver. I've attached a screenshot of the scope. Could this be caused by using a breadboard? I do plan on soldering together a protoboard when its done but I'm not sure if this level of noise and sloppy signal will persist.

Thoughts?

[EDIT]

Channel 1 and 2 are the normal signals, 3 and 4 are the differential ones.

SL4P · « **Reply #36 on:** January 06, 2016, 09:33:42 pm »

First two thoughts...
Termination of the differential pair (at both ends) e.g. 110 ohms to reduce overshoot and noise. Breadboard may also add to the problem if the pairs are vulnerable.
The sign may want a small delay between columns (dunno why), which you can do with bit bashing, but may be harder using hardware SOI...
Just thoughts.

cponcsak · « **Reply #37 on:** January 21, 2016, 05:38:01 am »

Hi Guys,

First off, sorry that its taken so long to update this thread. Other work has kept me really busy.

Second, here is an update.

I hooked it all up to an arduino, threw it all in a cardboard box from the dollar store

and took it down to the sign to test it. Worked right off the hop. I've ordered a good plastic enclosure with a proper keystone jack for the ethernet and a dc port that can be screwed to the enclosure wall. It includes plastic wings for screwing it to the board in the back of the controller box.

Programming it was an absolute nightmare. While I was able to use the hardware SPI interface, the way the packets were laid out made them difficult to construct. I basically had to construct a bitmap for each of the characters. I then had to parse the time from the RTC and run through using a function that takes an X and Y position in the packet and uses the bitmap for the character to read and write bits in the packet to generate the correct time. I can post the source if anyone is interested.

Once it was up and running, they complained about the sign being too dim. Turns out it was running in the dim mode for night operation. Changing the first byte in the packet from 00000010 to 00000011 switched the sign into bright mode. The surrounding ambient light at night is so bright that I just left the sign in bright mode all the time instead of fiddling with the light sensor out in the -40c wind chill.

Thanks to everyone involved for their assistance. Admittedly, it was a bit much for me to bite off for my first project back into electronics repair but it all turned out ok in the end. I will update the thread again once everything is in its proper enclosure and installed in the box at the sign.

Photos attached.

Pictures below.

SL4P · « **Reply #38 on:** January 21, 2016, 05:59:43 am »

it looks great!
well done...
maybe you can tweak the bitmap to make a nicer ' 5'

cponcsak · « **Reply #39 on:** January 21, 2016, 06:01:46 am »

Yeah, the 5 is a big issue for me. Getting rid of that pixel in the bottom right makes it look too top heavy and the only alternative is to make it all boxy like a classic LCD display. I went back and forth with the owners on it and they said to leave it and that we would revisit the bitmaps when the proper enclosure goes in. They don't see any issue with the 5 but it looks bad to me. All the other numbers look really good though and have a nice curvy feel to them.

SL4P · « **Reply #40 on:** January 21, 2016, 06:12:43 am »

Look at the 5 in the LCD display

cponcsak · « **Reply #41 on:** January 21, 2016, 06:19:37 am »

Yeah, its a very nice 5 but I don't have that resolution in the main sign. The sign is only a 4x7 per digit and its not even the full matrix, just the perimeter and in the middle. I'll see what they say. I might just reprogram it next time I'm in the area to show a different 5 and see what that looks like. I'm trying to avoid making unnecessary trips out there.

SL4P · « **Reply #42 on:** January 21, 2016, 06:44:42 am »

Yeah, I see what you mean 4x7 rather than the typical 5x7
I reckon it would look better without that bottom RH pixel!

cponcsak · « **Reply #43 on:** January 21, 2016, 06:45:37 am »

I'm inclined to agree. I'll reprogram it next time I'm in the area and see what it looks like.

SL4P · « **Reply #44 on:** January 21, 2016, 06:48:06 am »

it's great to see the actual sign in place... earlier in the thread, I do don't realise what the application was.

Worth checking all the digits to make sure they're not too fat in the corners as well.

cheers

cponcsak · « **Reply #45 on:** January 21, 2016, 06:58:14 am »

I ran through them all and they all look great except for the 5. Thanks for your input throughout the repair process, it was invaluable.

SL4P · « **Reply #46 on:** January 21, 2016, 07:01:14 am »

no problem. maybe the 5 will also benefit by moving the crossbar up one pixel?

cponcsak · « **Reply #47 on:** January 21, 2016, 07:09:49 am »

The resolution of the sign doesn't allow for that. I've attached a picture of which pixels can be lit up. I think removing that one pixel in the bottom right might solve the problem. The two is the same thing but flipped it it looks fine without that pixel so it should be ok. The sign isn't a full dot matrix display.

SL4P · « **Reply #48 on:** January 21, 2016, 07:15:10 am »

yep, got it.
you may be surprised his it looks if the crossbar is on row 3 instead of 4.

it lifts the waistline up to make the lower half appear 'rounder'
but as you say, it may be better the existing way without the bottom RH pixel.


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

Author Topic: LED Sign Repair (Read 13536 times)

Share me