5196106106

Exploring    the w

The HP 4951C Protocol Analyser

If you’re not too surę exactly what a Protocol Analyser is, and what you’d use one for, you’re in good company. An awful lot of engineers and technicians don’t know much about them yet, either. This article explains what they are, what they do and how you drive one — they’re easier than you’d think.

by JIM ROWE

Protocol Analysers haven’t been around for very long, and for much of their short life they’ve been used mainly in the specialised field of mainframe data Communications. As a result, not many people even knew of their exist-ence — let alone what they were used for.

It*s only been in the last couple of years, with the explosion in personal computers and data Communications, that they*ve become morę widely known and used. But even now, there aren’t all that many electronics engineers or technicians who know much about them or have used one.

Even the name itself seems to put many people off, because it gives little idea of the instrumenfs exact function. What exactly is a protocol, and why do you need to analyse it?

OK then, let’s try to explain the mys-tery. First of all, we*re talking about data Communications — computers talking to each other and exchanging data, via Communications links. Generally this activity will involve gadgets like modems, multiplexers, cables, tele-phone exchanges and so on. Increas-ingly nowadays it will also invo!ve mi-crowave and satellite links, optical fibrę cables, packet switching networks and nodes, and a multitude of other new technologies.

Also coming into the picture is software, running not only in the computers at the nominał “sending” and “receiv-ing” ends of a data link, but often in many of the gadgets in between. Because many of these are in reality specialised computers, as well.

Now if you’ve ever tried hooking up a simple data link yourself, like connect-ing a serial RS-232C terminal or a printer to a personal Computer, you’ll know that things often don’t go smooth-ly. First of all there’s the business of getting the right cables and connectors; then there’s the basie electrical connec-tions to get right; then to see if the de-vices at each end are using the same “handshaking” signals; then to make surę they*re set for the same Communications ratę (i.e., baud or bits per sec-ond); then that they’re using the same data codę (ASCII, Baudot, EBCDIC etc ); then parity and other error check-ing, and so on and so forth . . .

This rigmarole is bad enough for a simple data link, like hooking up a terminal or a printer. When things don’t work (not an uncommon occurrencel), it can often take hours to track down exactly what is going wrong, and fix it.

Now imagine how much morę diffi-cult it could get with much morę com-plicated data links, involving “intelli-gent” modems, multiplexers, packet as-semblers and disassemblers, network managers and so on. Get the idea? Without something pretty fantastic in the way of test gear, it would be a nightmare.

Enter the Protocol Analyser, a kind of cross between a scope, a logie analyser and a Computer, and designed spe-cially to analyse data communication systems.

But what about “protocol’* — where does that come in? Weil, remember all of those aspects that you have to check, one by one, when you*re trying to find out why your PC won*t print out on your new serial printer? Connectors and connections, handshaking, the data codę and format, parity, baud ratę and so on?

You probably didn’t realise it, but in checking each of these you were actu-ally checking out Communications proto-cols. That’s because “protocol” is just a fancy name for a standard, or set of conventions, goveming some aspect of data Communications.

It*s becoming common to speak of a hierarchy of data Communications protocols, arranged in order of their level of abstraction. The physical level comes first, involving things like connectors, voltage and cunent levels, things like RS-232C and RS-449 and so on. Next comes the “data link” level, involving data codes, communication rates, handshaking, parity and character error checking, etc.

Then there’s the “network” level, in-volving things like addresses for sender and receiver, assembling the data into packets, checking if packets are cor-rectly received without errors and re-sending if not, and so on.

In fact the International Standards Organisation (ISO) has defined a total of seven different levels of protocol for data Communications, known as the 7-layer Open System Interconnection (OSI) model. As shown in Fig.l, it ranges from the essential physical level (1) right up to the most abstract “appli-cation” level (7), where the communication is visualised as taking place transparenty between the software running in the computers at each end.

Needless to say, for communication to take place between any of the “high-er” levels, things have to be right at all of the lower levels (see Fig.2). So in ef-fect, for data to be communicated between a software program running in one Computer at level 7 to another program in another Computer (say across the country) at the same level, it has to be “passed down” through the various

112    . ELECTRONICS Australia. September 1987