-
LED Sign Repair
Posted by
cponcsak
on 24 Dec, 2015 20:51
-
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.
-
#1 Reply
Posted by
cponcsak
on 25 Dec, 2015 03:08
-
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.
-
#2 Reply
Posted by
siggi
on 25 Dec, 2015 17:32
-
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
-
#3 Reply
Posted by
cponcsak
on 25 Dec, 2015 18:07
-
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.
-
#4 Reply
Posted by
SL4P
on 25 Dec, 2015 18:44
-
...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
-
#5 Reply
Posted by
cponcsak
on 25 Dec, 2015 19:14
-
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.
-
#6 Reply
Posted by
siggi
on 25 Dec, 2015 21:39
-
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
-
#7 Reply
Posted by
SL4P
on 25 Dec, 2015 22:56
-
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.
-
#8 Reply
Posted by
cponcsak
on 25 Dec, 2015 23:13
-
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.
-
#9 Reply
Posted by
SL4P
on 25 Dec, 2015 23:40
-
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!
-
#10 Reply
Posted by
siggi
on 26 Dec, 2015 01:41
-
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
-
#11 Reply
Posted by
cponcsak
on 26 Dec, 2015 02:14
-
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.
-
-
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.
-
#13 Reply
Posted by
cponcsak
on 26 Dec, 2015 06:22
-
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.
-
#14 Reply
Posted by
SL4P
on 26 Dec, 2015 06:28
-
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!
-
#15 Reply
Posted by
cponcsak
on 26 Dec, 2015 06:33
-
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.
-
#16 Reply
Posted by
SL4P
on 26 Dec, 2015 06:41
-
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.
-
#17 Reply
Posted by
cponcsak
on 29 Dec, 2015 22:45
-
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.pdfChannel 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.
-
#18 Reply
Posted by
SL4P
on 29 Dec, 2015 23:00
-
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.
-
#19 Reply
Posted by
cponcsak
on 29 Dec, 2015 23:08
-
Thanks for your insight. I'll try hooking an arduino to it and shifting the data in to see if there are any patterns.
-
#20 Reply
Posted by
cponcsak
on 30 Dec, 2015 02:41
-
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.
-
#21 Reply
Posted by
siggi
on 30 Dec, 2015 02:54
-
What's the length of the packet?
Sent from my iPad using Tapatalk
-
#22 Reply
Posted by
cponcsak
on 30 Dec, 2015 02:59
-
Total packet length is 35 bytes across 9.25ms
-
#23 Reply
Posted by
SL4P
on 30 Dec, 2015 05:01
-
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.
-
#24 Reply
Posted by
cponcsak
on 30 Dec, 2015 05:10
-
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.