[looking to tap this excellent resource of intellegence ]

I've run across this situation several times while playing around with stuff (and once at work) and never figured out how to address it. I need to reverse engineer some non-standard hardware communications protocol for some reason. The biggest problem is that the topic is so broad and I know so little that I have thus far failed to find good source of info on the web.

Generally, I'm in one of the following situtations. Something simple isn't working right and I'd be willing to consider actually looking at the bits. (rare) I'm curious about the way something works. (somewhat common) I'd like to extract some information from a data stream to use in a different way (on my computer generally.) (common)

What kind of hardware is neccessary to observe and log the actual bits flying around onto my computer? In some cases I've known the protocol to be serial, but I don't know how to get that info into my computer when two hardware devices are communicating without disturbing the data transfer. (I've used serial port loggers before, but I'm talking HW-HW stuff here.) (Other times I've dealt with things that I think used some custom communcation protocol, but its always (with the stuff I've wanted to play with) low speed and not too much data to overwhelm.)

In the case that currently interests me we have two devices that are capable of sending at least the following information to each other.

Device A: Are you availible?
Device B: No.
Device A: Are you availible?
Device B: No.
Device A: Are you availible?
Device B: Yes.
Device A: Process the input "4" (or something really basic.)

There's probably some other stuff going on there in terms of handshaking and other talking but thats all thats there "for sure".

So my goal is to be able to monitor whats going on in terms of their communication. Eventually in real time in some custom software, but for now I'd just like to figure out how they work and then later I can figure out how I might be able to interface them with some software. (By that I just mean observe them. I'll never have to send data or otherwise disturb them.) For the purposes of this excercise, I'm not allowed to modify either device.

So obviously I have a lot to learn. I've been trying but I haven't found any helpful resource on the subject. If anyone could give me some advice that could point me in the right direction it would be much appreciated.

I love this board.

Thanks in advance,

John

It sounds like you need a logic analyzer. It's definately something you want the boss to pay for

Depending on what it is, you need different tools.

If it's serial or USB (or 1394), you can get analysers that plug into your computer. I used a serial analyser at my last job (for debugging fax and telex apps, no less). We've got a USB analyser here at empeg -- they're not cheap.

If it's network traffic, then Ethereal (sniffing the glue that holds the Internet together) is your friend.

Most other things, you want a full-on logic analyser, from HP or similar. Like genixia says, ask your boss very nicely.

I've confirmed that it is serial communications, which is exciting.

Turns out building a simple serial analyzer is trivial (in hardware) and there a a few open source bits of code to get me started. On the other hand I saw some solutions that were in the thousands of dollars range, but this is mainly just for fun here.

Thanks for your help, I'll let you all know how it goes.

John

Other very useful tooling for debugging serial stuff is a DSO.

Since everything is unknown, I guess you don't even know baud rate, parity etc. A storage 'scope will allow you too measure bit times etc letting you determine baud rate etc. This is how I figured out Alpines Mbus. Then it's a matter of looking for patterns etc in the received data. Although you would be surprised how often things use plain ASCII with no CRC etc to talk.

As a note when doing this Alpine stuff, I initially discovered things looked like 8E1 (I think) at about 1500 baud. It then seemed that one byte was sent for a 2 bit sequence. Thus 4 bytes were sent for each byte transferred.

What in fact it seems to be is that a binary 1 was represented by 2.5ms on period and 1.5ms off period and a 0 was represented by a 2ms on period and 2ms off period. It just so happened to match certain characters at 1500 baud. This would require an custom serial interface making it a lot harder to interface to the empeg. So instead for the moment I am using the 1500 baud 8E1 method.

Also just had a look at that debug interface. Problem is it requires two serial ports. A hell of a lot of stuff is request/response type half duplex comms. If it is half duplex comms you can do a slight dodgy and from the pass through DB9 pins 2 and 3, diode OR them together (1N914 is fine) and connect them to pin 2 of the listen DB9. ASCII art coming up

DB9 

5 --------------+------------------ 5

3 ---+----------|------------------ 3

2 ---|-----+----|------------------ 2

     |     |    |

    ---   ---   |

    \./   \./   |

     |     |    |

     +--+--+    |

        |       |

        |       |

Listen  |       |

DB9     |       |

2-------+       |

5---------------+

If both sides transmit at the same time you will get rubbish, but they won't conflict with each other.
Also it relies on most PCs detecting 0 volts as a negative which the 232 spec does say it should do.

Thanks very much for the advice. This will be a weekend project, I believe.

John

Ok, I've done some more research on my device and found out a lot more, and I'm starting to get stuck again.

My basic question is, "how do I use my computer to eavesdrop on some RS485 communication?" but I think I should explain the whole situation here so that those in the know can better anser my question. So here goes:

By looking at how this thing is implemented and compairing that with some research I did on the internet I'm now 95% sure that I'm dealing with a 4 wire (two-twisted pair) implementation of the RS485 protocol as described here.

I'm starting to realize that this may be more complex than I originally thought. Turns out these electronics are the same ones (or at least very similar to ones) used in another, much larger and much more complex network made by the same people (a division of AT&T). In fact this network I'm trying to "eavesdrop" on is actually a sort of node on a much larger RS485 network (however it is separate).

So here is an overview of what I've figured out so far, and then I'll explain where I'm stuck.



(All the devices / boards are plugged into the third-prong ground of an elecrical socket, which might be important.)

I'm not sure exactly how this protocol (what I'm pretty sure is RS485) is implemented or how I can begin to reverse engineer it. I think it works something like this though:

The "bridge" device I've drawn above is the brain of my "sub-network". I believe it acts like the "master" and polls each "slave" device A1-A8, B1-B8, asking (in some way to be determined), "are you busy?" to each slave device at a fairly regular interval. The slave device then responds "yes" or "no".

The master also has the ability to tell a specific slave devices to "start" at which point they become busy for an arbitrary period of time.

I'm not sure how the middle tier fits into that, but I think it's more than just some simple multiplexor because there's a pretty good deal of electronics there. I think what must actually happen is:

1) the master says to the boards: "A board, ask A1 if it's busy"
2) the A board tells the A devices: "A1 are you busy?"
3) A1 responds "No" to A.
4) A tells the master "No".

And the process repeats for other devices.

So I need a computer to be able to understand when the different devices are busy. It would be possible (but ridiculous) to do my own hardware and string new wire to each device. However, if I can get this to work this will probably be implemented on about 40 identical "sub-networks" and it is pretty much a deal-breaker to string new wire to the devices themselves, especially when all the data is passing in and out of the "master" device and should be accessible from there.

So at this point I need to find some info on how to listen to the RS485 communication that's there. I think I'll need to build / buy some hardware to interface with my computer because unlike RS232, RS485 works on a difference in voltage levels in the twisted pair, not a potential difference to ground. (Just for fun I took a DC multimeter to each twisted pair. The potential difference in A/B seemed to be 9 volts from the point of view of the DC multimeter, and it couldn't read C/D (perhaps it was changing too much)).

The whole point of this is I need some computer software to know when each machine is busy by looking at the wires coming out of the "master".

Where should I look to figure this stuff out? Anybody have experience with this stuff? What should I check now?

Many thanks for your infinite wisdom,

John

'485 isn't really that much different from 232. The main differences are the ability to multidrop and good noise resistance since they use balanced transmissions.

If it's 4 wire 485 then one pair will be transmit from a master and connect to the receive of all the slaves. In turn all the slaves transmit lines will connect in parallel to the master's receive.

To run multiple slaves in a multidrop environment they need to be setup so they only turn their transmitters on when they actually send stuff. Since the master is the only device transmitting on the first pair it doesn't matter if it's setup like this or not. Actually if you want more than one master you'll need to setup transmit enable.

Soooo... assuming the master really is setup for transmit enable you can actually join the two pairs together to make the system 2 wire. The units might get confused though since they begin to see what they are transmitting.

Basically you'll need a 485-232 converter so you can plug it into your standard PC serial port. I haven't ever looked at the possibility of a simple 232-485 converter so you'll be up for some dollars.

If the 2 wire thing works, you'll only need one converter but if it doesn't and you want to snoop both lines, you'll need 2 x 232-485 converters.