Author Topic: LED Sign Repair (Read 13841 times)

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 13841 times)

Share me