Serial data comes in many flavors–async RS-232, synchronous, USB pipes, Ethernet networks, and though quite different internally, all forms of serial data share one inconvenient truth: They’re hard to see. That’s because data doesn’t flow in a simplistic stream of information; indeed almost all forms of serial data are characterized by one or more levels of protocol. a protocol is really just an agreement between two or more entities to behave in a certain manner so that everyone can read the page the same way. On the other hand, protocols for serial data links turn out to be quite intricate.

How can we see the data in a manner that tells us the truth about how well those protocols are behaving today? What sort of eyes do we need? Most of you wouldn’t be here if you didn’t know the answer to that: a protocol analyzer, of course.

Indeed, what constitutes a protocol analyzer? What does one tell you, the nitty-gritty details you need to know to be assured that you’ve a handle on the behavior of the protocols, the packets, the exchanges between stations on a serial data link? The answer, of course, varies somewhat between those flavors–an analyzer suitable for Ethernet packets carrying TCP/IP traffic is going to be quite different from one that lets you see, for instance, an industrial workhorse protocol like Modbus. Isn’t it?

Well, yes and no. The answer lies in dedication to clarity of vision, unity of user interfaces, a design that minimizes the difference that you see when using an analyzer for Ethernet and one that decodes Modbus traffic dashing about on a factory floor. We think that clarity is mandatory. You want to get the user interface down pat, once and for all, so that when your data leaves a USB port, slides through a modem on the USB wire, reaches out to a LAN in another building, the IP payload stripped out as Modbus packets that end up helping control a robot welding machine–and of course the feedback from sensors makes the reverse trip, you can see, with clarity, the data at various points along this full-duplex trip. You need to maximize clarity and uniformity of how the analyzers are used and how the data are presented to you, the variety of kinds of views into the data stream — don’t end up a hodge-podge of gadgetry with different views, different user interfaces, and different behaviors. Indeed, you need uniformity and clarity. How do you get that?

As little as 30 years ago, the protocols were there in various forms, and instrumentation to let you see the data came in the form of twenty pound boxes, all different, from companies like Tektronix, HP, National Instruments, and a gaggle of smaller, specialized sources. As one might expect, everybody who made a protocol analyzer or even a simple data monitor had their own proprietary way of doing things. One box, let’s say a DataScope, contained a CRT, a tape recorder, and some logic internally that you couldn’t change. Another box with completely different buttons and knobs, presented the data at some point in quite a different manner. Learning curves were significant. Results were often confusing.

Then some folks wrote software that ran on a PC and when laptops were introduced, a technician or engineer could monitor data on screen using software and some cables. Soon, Greenleaf Software saw the wisdom of this approach and introduced ViewComm for DOS. The assemblage constituted a smart data monitor for RS-232 asynchronous data.

From this introductory volley of products came a progression of smarter and smarter monitors; the focus became one of protocol analysis. The products became ever better at presenting suites of significant and revealing views into the data, and giving users the ability to pick and choose their choices of views while maintaining a consistent user interface. From simple views like sequences of data presented in rows on a screen, views were needed for signals such as those used to control and status a modem or attached device. Views of frames (packets) were more tricky to design; what was needed was a flexible way of showing the amount of detail the user wants to see while breaking streams of data into packets, that is recognizing in software when a packet starts and when it stops.

Once the designers of ViewComm realized that they were going to build a scripted analyzer that could handle recursive, nested protocols, they developed a language called DecoderScript, created the infrastructure for obtaining the data in its various aspects from the machine, and introduced a true killer app, a protocol analyzer that could theoretically analyze any protocol and even help to design and debug software to cause the protocol(s) to be built interactively and with less reinvention of various wheels.

The result is a family of products, some from Greenleaf Software, some from Frontline Test Equipment Inc., that give you an incredible Array of protocol analyzers–analyzers for asynchronous RS-232, RS-422 or 485, Ethernet, USB, BlueTooth–analyzers that provide true clarity, true unity of interface (with some variation, the GUIs are identical.

Today, in June, 2006, Greenleaf Software is proud to introduce the following protocol analyzers:

• Greenleaf ViewComm II for Asynchronous Serial Data.
• Greenleaf ViewComm II for Ethernet.
• Frontline FTS4Control, an analyzer for the industrial control market.
• Frontline FTS4USB, an analyzer for USB that can probe (tap into) the USB wire.

NOTE: for Bluetooth analyzers, synchronous RS-232, Zigbee, IEEE 802.15.4, and some specialty analyzers, contact Frontline Test Equipment directly at http://www.fte.com