PDA

View Full Version : How to decode communication



Christopher4187
- 18th September 2013, 14:07
I have a device that uses wired communication and need to decode it, however, I don't know anything about the protocol. I've never done this before (attempted to decode data where I don't know the protocol) and I'm hoping someone can give me some pointers as to the most efficient method to figure it out.

Here is what I know:

1. It's for a little league football scoreboard.
2. It travels about 300 feet.
3. It's wired and there are two wires going to the scoreboard.
4. When I measured the wires with a DMM it is about 14.9 VDC.
5. The data appears to be PWM as data is constantly flowing whether a button is pushed or not.
6. The frequency appears to be approximately 1.6 kHZ and I can see the data using an oscilloscope.
7. There are a lot of 74HCxx's on the PCB.
8. I tried using hyperterminal and while I could see data nothing appeared to be valid data. The speed does appear to be around 4800 bps.
9. There is an RJ11 jack on the PCB but I don't know if this is used for the communication or not. I was taking measurements from another connector on the PCB.

That's pretty much all I know. This is an area where I have very little experience (data communication) so any pointers would be appreciated.

Jerson
- 18th September 2013, 15:55
You can start by making educated guesses by looking at the chips on the communication board. That will give clues to what is going on there. A photo of the board might help you get ideas here. It could be a current loop communication which was used to cover long distances before RS485 became the norm.

Christopher4187
- 18th September 2013, 16:13
I know the board was manufactured in 1998 by Daktronics. I don't have it with me but I will try to post a picture when I get home tonight. I'm stuck on two problems.

1. The constant data makes it hard for me to determine where the comms starts and ends.

2. The PWM (or at least that's what it appears to be) seems like it isn't steady. This could be my probe so I'll recheck it when I get home.

Maybe this will help.....maybe not. Here is a log from Hyperterminal. Most of it was automatically sent by the controller and I pushed a button five or six times during this log. I connected the output pin of the scoreboard to pin 2 of the Max232. I was using 4800 bps:


$ @ @@ $ $ @ € $ @ @ € $ $ @ @ @ $ $ @ @ @I $ $ @ @@ $ $ @ @ € $ @ @ € $ $ @ @ @ $ $ @ @ @I $ $ @ @ $ $ $ @ € @ € @ € $ ’ $ @ @ @ @ @ @ $ $ $ @ $$ @ @ @ @ @ $ $ $ € @ @ @ @ $ $ @ @H $ $ @ @ $ $ @ @ € $ $ @ @ @ $$ $ @ $ $ € @ @H $ @ @ @ $ @ $ @I $ @ € @ @ @ € € $$ € @I @ @ € $ € $ @ @ @ $ $ $ @ @ @ $ $ @ @ @I $ $ @ @@ $ $ @ @ € $ @ @ € $ $ @ @ @ $ $ @ @ @I $ $ @ @ $ $ @ @ € $ @ @ € $ $ @ @ € $ ) € $ @I ’ @ € @ $ @ $ $ @ € @ @H @ @ @H $ @ $ @ $ @ € @ @ @ € @ @ $ $ @ @ $ $ @ @ @ $ $ @ @ @$ $ $ @ @ $ $ A $ @ @ € @ $ ’ $ @ @ @ @ @ @ @ $ $ $ @@ $$ @ @ @ $ @ @ $ $ @ @ $ $ @ @ @I $ $ @ @ $ $ $$ @I @ * @ $ @ $ $ @ @I $ $ @ @ $ $ @ @ $ @ @ $ $ @ @ @ @ I @ $ $ @ $ $ @ @ @ @ @ I @ @ @ $ $ @ @ @ $ $ € $ @ @ @ @ @ @ $ $ $ $ @H @ @ $ $ @ @ @I $ $ @ @H $ $ @ $ @H $ I $ @ @ @@ @ @ $ $ @I $ $ @ @@ $ $ @ @ € $ @ @ @H $ @ $ @ $ @ € @ @ @ € € $H $ ’ @ @ $ @ @ $ $ @ @ @ $ $ @ @ @I $ $ @ @ $ $ @ @ $ @ @ $ $ @ @ @ $ $ @ @H $ $ @ @ $ $ @ @ $ I @ @ $ $ @ @ @ $ $ @ @H $ $ @ @ $ @ @ $ $ @ @ @ $ $ @ @ @I $ $ @ @H $ $ @ @ $ @ @ $ $ @ @ @ $ $ @ @ @I $ $ @ @@ $ $ @ @ $ @ @ $ $ @ @ @ $ $ @ @ @I $ $ @ @ $ $ @ @ $ @ @ $ $ @ @ @ $ $ @ @ @I $ $ @ @ $ $ @ @ $ @ @ $ $ @ @ @ $ $ @ @H $ $ @ @ $ $ @ @ $ $ @ @ @ $ $ @ @ @ $ $ @ @H $ $ @ @ $ @ @ $ $ @ @ @ $ $ @ @ @I $ $ @ @H $ $ @ @ $ @ @ $ $ @ @ @ $ $ @ @ @I $ $ @ @@ $ @ @ $ @ @ $ $ @ @ @ $ $ @ @ @I $ $ @ @ $ $ @ @ $ @ @ $ $ @ @ @ $ $

Christopher4187
- 18th September 2013, 16:39
I can't get the code box to be any larger. It's missing the spaces but here is the data:


$ @ @@ $ $ @  € $  @ @ € $ $ @ @ @ $ $ @ @ @I $ $ @ @@ $ $ @ @ € $  @ @ € $ $ @ @ @ $ $ @ @ @I $ $ @ @ $ $ $ @ € @ € @ € $ ’ $ @ @ @ @ @ @ $ $ $  @ $$ @ @ @ @ @ $ $ $ € @ @ @ @ $ $ @ @H $ $ @ @ $ $ @ @ € $ $ @ @ @ $$ $ @ $ $ € @ @H $ @ @ @ $ @ $ @I $ @ € @ @ @ € € $$ € @I @   @ € $ € $ @ @  @ $ $ $ @ @ @ $ $ @ @ @I $ $ @ @@ $ $ @ @ € $  @ @ € $ $ @ @ @ $ $ @ @ @I $ $ @ @ $ $ @ @ € $ @ @ € $ $ @ @ € $ ) € $ @I ’ @ € @ $ @ $ $ @ € @ @H  @ @ @H $ @ $ @ $ @ € @ @ @ € @ @ $ $ @ @ $ $ @ @ @ $ $ @ @ @$ $ $ @ @ $ $ A $ @  @ € @ $ ’ $ @ @ @ @ @ @  @ $ $ $  @@ $$ @ @ @ $  @ @ $ $ @ @ $ $ @ @ @I $ $ @ @ $ $ $$ @I @ * @ $ @ $ $ @ @I $ $ @ @ $ $ @ @ $ @ @ $ $ @ @ @  @ I @ $ $ @ $ $ @ @ @ @ @ I @ @ @ $ $ @ @ @ $ $ € $ @ @ @ @ @ @ $ $ $ $ @H  @ @ $ $ @ @ @I $ $ @ @H $ $ @ $ @H $ I $ @ @ @@ @ @ $ $ @I $ $ @ @@ $ $ @ @ € $  @ @ @H $ @ $ @ $ @ € @ @ @ € € $H $ ’ @ @ $ @ @ $ $ @ @ @ $ $ @ @ @I $ $ @ @ $ $ @ @ $ @ @ $ $ @ @ @ $ $ @ @H $ $ @ @ $ $ @ @ $ I @ @ $ $ @ @ @ $ $ @ @H $ $ @ @ $ @ @ $ $ @ @ @ $ $ @ @ @I $ $ @ @H $ $ @ @ $ @ @ $ $ @ @ @ $ $ @ @ @I $ $ @ @@ $ $ @ @ $  @ @ $ $ @ @ @ $ $ @ @ @I $ $ @ @ $ $ @ @ $ @ @ $ $ @ @ @ $ $ @ @ @I $ $ @ @ $ $ @ @ $ @ @ $ $ @ @ @ $ $ @ @H $ $ @ @ $ $ @ @ $ $ @ @ @ $ $ @ @ @ $ $ @ @H $ $ @ @ $ @ @ $ $ @ @ @ $ $ @ @ @I $ $ @ @H $ $ @ @ $ @ @ $ $ @ @ @ $ $ @ @ @I $ $ @ @@ $ @ @ $  @ @ $ $ @ @ @ $ $ @ @ @I $ $ @ @ $ $ @ @ $ @ @ $ $ @ @ @ $ $

Dave
- 18th September 2013, 18:11
Chris, Measure the time of the smallest pulse and that should be the the baudrate.

Dave Purola,

Christopher4187
- 18th September 2013, 19:07
I'll check it but it's either 2400 or 4800. When I figure out the exact baudrate, how can I decode the data?

amgen
- 18th September 2013, 21:39
did you try all std baud rates from say 300 thru 38000 ? If you cant get to see some type of decernable ascii chars, then you would need to have the mfg info on data.
also, it could be inverted, so you could invert the signal and try the bauds again for readable data.

jrprogrammer
- 20th September 2013, 12:30
One thing I'd look at: is the data inverted? That would make you receive garbage all the time. Put a scope on the signal an look. If that's the case, use a 4049 gate to invert the data.
JR

Christopher4187
- 20th September 2013, 15:15
I'm still kind of lost but seem to be making a little progress. I can see that the entire packet takes 20mS to transmit. It's hard to tell where one piece of data ends and the other begins. I can see the data change when I press buttons on the controller but some of the data isn't used for this application. In other words, those bits/bytes are just taking up space but must be included when the packet is transmitted.

Perhaps this will help you guys help me. I concentrated on the ones digit for the home team score. I think it takes 750uS to transmit the ones digit and I based that assumption on when the edge falls to when it rises again at the end. However, some of the data takes about 500uS. Is it safe to assume that it takes 750uS for a byte and maybe 500uS for a bit?

To duplicate the packet (I'm starting with the ones digit), I have the data from the PIC going to the input of a ULN2003A. On the output side I'm using a 10K pullup and then measuring it with the scope. One problem I'm having is that I can't quite get the timing right. I've attached two pictures that show my problem. The first picture is of the source. I'm trying to duplicate what is seen here. In the middle (-250uS from center to +500uS from center) is the number 2. 7085

Here is my attempt to make the number 2. As you can see, I had to adjust the sec/div to 100uS and the second pulse in the number two isn't the same as the source.7086

Regarding the data being inverted, what is the normal way? High to low or low to high?

I've tried adjusting my settings but nothing seems to help. The relevant settings are:



RCSTA1 = $90
TXSTA1 = $24
DEFINE HSER_BAUD 300
DEFINE HSER_CLROERR 1 ' Clear overflow automatically
BAUDCON1 = %00111000

And then I send the data like this:


MAINLOOP:
HSEROUT [dec 2]
PAUSE 100
GOTO MAINLOOP

Jerson
- 20th September 2013, 16:32
From the images, I do not think it is an UART transmission. Can you zoom out the source capture a little so that you center the '2' and we can see around it a bit more detail?

Christopher4187
- 20th September 2013, 16:49
I've attached pictures of the PCB, a picture of the #2 zoomed in and a picture of the #2 zoomed out. 708770887089

Jerson
- 20th September 2013, 18:38
Looking at the components, it might be a current loop signalling. Is it?

Are there any communications related components below the LCD ? Cant see them in the photo.

Christopher4187
- 20th September 2013, 18:45
There's nothing under the LCD. What you see is what you get. Correct me if I'm wrong but it can't be a current loop because I have nothing connected to the output except the scope probe.

Christopher4187
- 20th September 2013, 18:51
The signal output appears to be coming from a 2N3417 (collector), which also appears to be in parallel with a TIP30C (collector).

Christopher4187
- 20th September 2013, 21:31
Something else popped into my head. The time between the start of each byte is exactly 1,250uS. The time it takes to transmit the total packet is 20mS, which means there are 16 digits. Can I do all of this manually? To be more specific, can I use GOSUB's for each number and just specify exactly how long I need the pulses to be? The data is predictable and I'm not seeing anything that doesn't look strange. There are only numbers transmitted and they are 0-9. My thought is something like this:



MAINLOOP:

'GATHER NUMBERS TO BE TRANSMITTED

SELECT CASE D0
CASE 0
GOSUB ZERO
CASE 1
GOSUB ONE
END SELECT

SELECT CASE D1
CASE 0
GOSUB ZERO
CASE 1
GOSUB ONE
END SELECT


SELECT CASE D2
CASE 0
GOSUB ZERO
CASE 1
GOSUB ONE
END SELECT

......

SELECT CASE D15
CASE 0
GOSUB ZERO
CASE 1
GOSUB ONE
END SELECT

PAUSE 5

GOTO MAINLOOP

.....

ZERO:
DO3=1
PAUSEUS 550
DO3=0
PAUSEUS 75
DO3=1
PAUSEUS 50
DO3=0
PAUSEUS 575
RETURN

ONE:
DO3=1
PAUSEUS 50
DO3=0
PAUSEUS 75
DO3=1
PAUSEUS 175
DO3=0
PAUSEUS 300
DO3=1
PAUSEUS 50
DO3=0
PAUSEUS 600
RETURN

TWO:
DO3=1
PAUSEUS 250
DO3=0
PAUSEUS 75
DO3=1
PAUSEUS 150
DO3=0
PAUSEUS 75
DO3=1
PAUSEUS 250
DO3=0
PAUSEUS 450
RETURN

THREE:
DO3=1
PAUSEUS 400
DO3=0
PAUSEUS 150
DO3=1
PAUSEUS 250
DO3=0
PAUSEUS 450
RETURN

FOUR:
DO3=1
PAUSEUS 75
DO3=0
PAUSEUS 75
DO3=1
PAUSEUS 150
DO3=0
PAUSEUS 150
DO3=1
PAUSEUS 250
DO3=0
PAUSEUS 550
RETURN

FIVE:
DO3=1
PAUSEUS 150
DO3=0
PAUSEUS 75
DO3=1
PAUSEUS 150
DO3=0
PAUSEUS 75
DO3=1
PAUSEUS 325
DO3=0
PAUSEUS 475
RETURN

SIX:
DO3=1
PAUSEUS 150
DO3=0
PAUSEUS 75
DO3=1
PAUSEUS 475
DO3=0
PAUSEUS 550
RETURN

SEVEN:
DO3=1
PAUSEUS 325
DO3=0
PAUSEUS 300
DO3=1
PAUSEUS 150
DO3=0
PAUSEUS 475
RETURN

EIGHT:
DO3=1
PAUSEUS 800
DO3=0
PAUSEUS 450
RETURN

NINE:
DO3=1
PAUSEUS 325
DO3=0
PAUSEUS 150
DO3=1
PAUSEUS 325
DO3=0
PAUSEUS 450
RETURN

richard
- 20th September 2013, 23:16
it could be a stream of data for 7 segment display array, that's updated 50 times a second . ie every bit represents a segment

Christopher4187
- 21st September 2013, 02:31
It actually worked! Some of my times are off a bit so the numbers looked a little funny but overall the comms works well. What I also found interesting is that the controller sent the data every 2.5mS but it's not even necessary. I sent it once and the numbers stayed on the scoreboard.

Thanks to all who helped.

Art
- 23rd September 2013, 07:17
Sending the message constantly would reduce potential for noise interpreted as data interfering with the display too long,
but checksumming the message would better achieve that.