Reverse Engineer Inova Lightlink Wallboard

Got a hardware problem? ask for help

Reverse Engineer Inova Lightlink Wallboard

Postby merlinn31 » September 18th, 2014, 6:30 pm

I picked up an old call center board, looks to be circa 1998 based on copyright information printed on the board. (Like this: http://www.ebay.com/sch/sis.html?_nkw=I ... 0966228969). The model is CFM24.160S-IP. It has what look to be two RJ11s labeled "net in" and "net out". There's a third RJ11 only accessible by taking the sign apart. There's also an RJ45 for network connectivity. Upon powering on the board, it says lots of nice things like its IP, Gateway, Subnet, Firmware, and Serial Port settings. After configuring an IP on my laptop, I can get ping from the sign and NMAP shows TCP/UDP ports 5002 open. Sending arbitrary data to these ports looks like it fills a buffer and barfs back out to console. Nothing too helpful.

I have two EEPROM dumps that are reportedly from two EEPROMs on the board. I didn't dump them myself. Running strings on them doesn't give up any intelligible data at all. Binwalk thinks the second dump has LZMA compressed data, but after ripping the "data" out, lzma command says it's corrupted. I suspect a false positive.

I gave up on trying to break in through the front door and took it apart to look for a serial port. I found a MAX232A chip, which I think indicates that there should be a serial or TTL nearby. After checking pinouts and checking voltage during sign bootup, I don't see any fluctuations in voltage that would indicate transmission of data from the sign. Maybe I'm not looking in the right place.
I tried social engineering the company into giving me some sort of manual that might give me more info, but the sign is so old that the woman refused to give me any info without a support contract.

What do you guys think? Feel like I'm attacking this from a few different ways and not getting much success. I'd really just like to post messages to it.
merlinn31
 
Posts: 10
Joined: September 18th, 2014, 6:28 pm

Re: Reverse Engineer Inova Lightlink Wallboard

Postby st2000 » September 18th, 2014, 7:55 pm

I think one of the problems you face is that you want to use a little piece of an overall product&service. And that person on the other end of the phone is wondering what type of crazy person is she talking to. Another problem might be that for all we know Inova OEM'ed the display from someone else. I found this Avaya app note that uses a Inova system. But I don't think it gives away much.
http://www.devconnectprogram.com/fileMedia/download/7000332d-8414-427c-9d08-6edb6d8c8859
Keep digging. Pictures would help. The best would be to go back and find the (now I'm guessing) computer and software that controls this sign. If in fact that is how it works. But be prepared to suffer an onslaught of unknowns as I don't think this is just a simple "type and see it" type of software package. But rather some sort of interface to a private PBX that grabs metrics to display.

In the end, I'm betting you need to tear into the hardware all the way back to a point you understand then build back out from there. I'm hoping that there is a "driver/display" board/circuit that you can eventually talk letters or graphics to. And that you will probably pull the "controller/communication" board/circuit instead of trying to understand it.
st2000
 
Posts: 1454
Joined: February 3rd, 2011, 6:10 pm

Re: Reverse Engineer Inova Lightlink Wallboard

Postby bandersnatch » September 19th, 2014, 5:52 am

Perhaps you might consider taking a step back from the detail and consider the unit as a whole in a "black box" manner

IF the thing is "Innova Lightlink" compatible then take a look at
mxdigitalsystems.com/products/lightlink/
for an overview of how this (mind-bogglingly complicated) system works.

From: mxdigitalsystems.com/led-wallboards/
and: mxdigitalsystems.com/products/desktop-software/

it looks like you can use the "desktop-software"to directly configure the marquee display.
I would definitely try to source "Lightlink" configuration/testing tools
(possibly available in the dark & murky corners of the Internet)

Hammering the network port with random packets without some knowledge of at least the protocol used
is gonna take a while (!) ... Although MODBUS might be a good guess of the protocol used.
You could try hammering the network with correctly formed MODBUS packets..
At least the checksums will be correct and you only then beed to vary the MODBUS payload...

A sneaky person would perhaps "Evaluate" a similar product from a retail store
record/analyze the network traffic and then return the product after 1 week but
I would of course never suggest this...
bandersnatch
 
Posts: 150
Joined: September 17th, 2014, 12:06 pm

Re: Reverse Engineer Inova Lightlink Wallboard

Postby merlinn31 » September 19th, 2014, 6:47 am

Thanks for the idea, I'll try the MODBUS route for a bit and see where that gets me.

Also uploaded some pics of the controller board: http://imgur.com/a/dFVRA
merlinn31
 
Posts: 10
Joined: September 18th, 2014, 6:28 pm

Re: Reverse Engineer Inova Lightlink Wallboard

Postby bandersnatch » September 19th, 2014, 7:12 am

MODBUS is most likely but you will need to experiment with the various different checksum sizes
A good trick is simply to send a MODBUS "NAK" or "ACK" packet & see if you get any sort of response...
Keep experimenting with the same simple packet content & different checksum algorithms until you get
any sort of an answer.

However, serial control of these devices using a direct cable connection is almost always much easier.
I would definitely trace the Rx/Tx pins of the MAX232 & find the corresponding connector
Then connect an RS232 cable to this connector & send a few good old CRLFs at different baud rates, bit configs
(9600,N,8,1 is always a good place to start)

No RS232 traffic on startup is not uncommon.
With locally wired connections you often need to poke the device with the RS232 equivalent of a big stick before
it generates any trafific...
bandersnatch
 
Posts: 150
Joined: September 17th, 2014, 12:06 pm

Re: Reverse Engineer Inova Lightlink Wallboard

Postby st2000 » September 19th, 2014, 7:32 am

Nice clear pictures. Only 1 circuit board - hum - was hoping for 1 controller and 1 communications. bandersnatch has some good ideas. Just wanted to ask - was this a known-good-unit? I ask - because I get nervous when I see FPGAs (the Xinlinx chip) and an empty socket near by. True, some FPGAs have internal memory. And FPGAs can be programmed by the micro controller. So you don't have to have an external EEPROM. But then why populate the board with a socket?

Oh, you indicated the display showed text on booting up, right? Ok - maybe the FPGA is programmed.
st2000
 
Posts: 1454
Joined: February 3rd, 2011, 6:10 pm

Re: Reverse Engineer Inova Lightlink Wallboard

Postby merlinn31 » September 19th, 2014, 8:57 am

There are multiple boards, but this is the controller board that controls the logic. There are 3, 10-pin ribbon cables that run from the controller board and daisychain all of the LED driver boards together. Additionally, there is a honking power board that hooks up to the controller board.

Through continuity tests, it looks like the pinout of the 4pin header (JP15, last picture) near the MAX232A chip is [(Gnd) (0V) (-9.6V)(Gnd)], oriented with the picture.

http://creativeelectron.net/blog/wp-con ... /10/13.jpg

Pin 14 on the MAX232A is connected to the "0V" pin on the 4pin header. Pin 13 is connected to the -9.6V pin on the 4pin header. I rigged up a db9 according to the diagram in the picture above and jacked into it with the serial settings that are displayed on boot, but putty didn't like it. No status messages (which you said isn't uncommon), but also no echo to the terminal when I pressed keys. I'm interpreting this to mean that I'm not doing something right.
merlinn31
 
Posts: 10
Joined: September 18th, 2014, 6:28 pm

Re: Reverse Engineer Inova Lightlink Wallboard

Postby bandersnatch » September 19th, 2014, 9:31 am

merlinn31 wrote:There are multiple boards, but this is the controller board that controls the logic. There are 3, 10-pin ribbon cables that run from the controller board and daisychain all of the LED driver boards together. Additionally, there is a honking power board that hooks up to the controller board.

Through continuity tests, it looks like the pinout of the 4pin header (JP15, last picture) near the MAX232A chip is [(Gnd) (0V) (-9.6V)(Gnd)], oriented with the picture.

http://creativeelectron.net/blog/wp-con ... /10/13.jpg

Pin 14 on the MAX232A is connected to the "0V" pin on the 4pin header. Pin 13 is connected to the -9.6V pin on the 4pin header. I rigged up a db9 according to the diagram in the picture above and jacked into it with the serial settings that are displayed on boot, but putty didn't like it. No status messages (which you said isn't uncommon), but also no echo to the terminal when I pressed keys. I'm interpreting this to mean that I'm not doing something right.

Errmmmm... I'm not sure how experienced you are with RS232 comms & so please dont feel insulted if you already know this stuff,
but I don't fully understand your diagram.
According to :
Image
Data received via RS232 (Txed from the remote computer) must always be connected to pin 13 or pin 8
Data sent via RS232 (Rxed by the remote computer) must always be connected to pin 14 or piun 7

Which does not correspond to your diagram.

My suggestion is first build a null-modem cable
(as shown in /www.zytrax.com/tech/layer_1/cables/tech_rs232.htm#null_db9)
and check that putty echos correctly. (solves CTS/RTS CSR/DSR flow control problems)

Then disconnect the Tx-Rx bridge between pins 2 & 3 and check the various possible configurations:
- wire Tx to pin 13 of the max 232
- wire Rx to pin 14 & watch for traffic at different baud rates
- -wire Rx to pin 7 & watch for traffic at different baud rates

- wire Tx to pin 8 of the max 232
- wire Rx to pin 14 & watch for traffic at different baud rates
- -wire Rx to pin 7 & watch for traffic at different baud rates

ONE of these combinations should work...
bandersnatch
 
Posts: 150
Joined: September 17th, 2014, 12:06 pm

Re: Reverse Engineer Inova Lightlink Wallboard

Postby merlinn31 » September 19th, 2014, 10:32 am

First, thank you for your help. The first thing I'm willing to admit to anyone is that I don't know anything about anything. My very basic understanding is only what I've read about RS232, which isn't much other than it operates at higher voltages than TTL lines. The diagram I linked to is one I found through google images searching for "MAX232 to DB9 pinout". The diagram I linked to shows 13 and 14 connecting to the DB9. Coincidentally, my board has them mapped to the middle two pins on the 4-pin connector JP15 at the bottom of the last picture. I have a null modem cable and am using it.

I'm confused - Are you saying that they aren't wired to the correct pins on the db9? What do you mean by the Tx-Rx bridge between pins 2/3? Are you also saying that I should connect Tx on the DB9 to pin 13 on the max232 and check BOTH 7 and 14 separately for return traffic at different baud rates?

My continuity tester says that pin8 on the max232 is Gnd. Not sure if that changes anything or not.
merlinn31
 
Posts: 10
Joined: September 18th, 2014, 6:28 pm

Re: Reverse Engineer Inova Lightlink Wallboard

Postby bandersnatch » September 19th, 2014, 12:22 pm

merlinn31 wrote:First, thank you for your help. The first thing I'm willing to admit to anyone is that I don't know anything about anything. My very basic understanding is only what I've read about RS232, which isn't much other than it operates at higher voltages than TTL lines. The diagram I linked to is one I found through google images searching for "MAX232 to DB9 pinout". The diagram I linked to shows 13 and 14 connecting to the DB9. Coincidentally, my board has them mapped to the middle two pins on the 4-pin connector JP15 at the bottom of the last picture. I have a null modem cable and am using it.

I'm confused - Are you saying that they aren't wired to the correct pins on the db9? What do you mean by the Tx-Rx bridge between pins 2/3? Are you also saying that I should connect Tx on the DB9 to pin 13 on the max232 and check BOTH 7 and 14 separately for return traffic at different baud rates?

My continuity tester says that pin8 on the max232 is Gnd. Not sure if that changes anything or not.


Ok. Secure in the knowledge that you wont feel insulted I'll give you a bit more detail
I suggest you read up on RS232 comms in general (e.g. www.commfront.com/RS232_Protocol_Analyz ... torial.htm)

"RS232" actually only defines the voltage levels (around +/- 12V but this varies widely in reality) & HW control signals for one type of serial communications.
The MAX 232 chip simply converts between the +/- 12V RS232 signals and 5/0 V TTL signals.
It has two receivers "R1IN" pin 13 and "R2 IN" pin 8 that convert +/- 12V signals from an external computer into 5/O V TTL signals for the board
- At least ONE of these receivers must be connected to the Tx pin of your RS232 interface
- If pin 8 is tied to ground then pin 13 must be the input we need ==> connect MAX 232 pin 13 to TXData of your RS232 cable
(more about pin number later)
It has two transmitters (drivers) "T1OUT" pin 14 and "T1OUT" pin 7 that convert 5/O V TTL signals from the board into +/- 12V signals
to be sent to an external computer
- At least ONE of these transmitters must be connected to the RxData pin of your RS232 interface
- We dont know which of these is actually used so try them both one after another.

You might think that you only need to connect TxData, RxData and the Gorund pin but this is only half the story
RS232 also uses "FlowControl" (RTS/DTS) and "Status" (DTR/DSR/RI) signals
The "flow control" signals are used to dynamically stop and resume communcation to prevent buffer overflows
The "Status" signals are used to indicate the link/device status
Blah,, blah... all you really need to know is that you gotta connect these signals to each other at the RS232 connector
otherwise nothing will work.
The "null modem" cable I suggest has all the correct connections so that the RS232 port will always send & receive.
It also has RxData connected to TxData. (loopback)
If you start putty with this "null modem" cable connected then every character you send (via TxData) is fed directly
back intp RxData. This cable allows you to first check that the serial interface on your system is working and that
the putty profile you are using is correct. Use this cable with putty and everything you type should be immediately
echoed on the screen.
Once you know that putty and your RS232 interface are working, you can remove the jumper between TxData and RxData
and wire TxData, RxData and GND to the MAX232 chip instead...

You might end up seeing wierd characters, which means that one or more of your:
Baudrate, Databits, stopbits, or parity settings are not correct.

Pin numbers
==========
The male/female connector confusion means that RxData is pin 2 and TxData is pin 3 or vice-versa
depending on whether you have a male or female connector ($!"§&%$!&$§"/!)
You can use a multimeter on either pin 2 or pin 3 and type like mad in putty.
The TxData pin should show voltage swings on TxData...

Hope this helps you
bandersnatch
 
Posts: 150
Joined: September 17th, 2014, 12:06 pm

Next

Return to Help me! Hardware

Who is online

Users browsing this forum: No registered users and 1 guest