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.

We want you to be very satisfied With your new ViewComm software. We really do.

HARDWARE + SOFTWARE = VCS
It Is important that you understand the hardware and software environment which enables VCS Async to work and that we be Clear on license issues.

LICENSE - LET's GET THAT OUT OF THE WAY
Please read the license now. This page also contains vital information about VCS ProtocolWorks, how it relates to your VCS Async, Async Plus, Viewer, Or Ethernet product, And how to install it.

DRIVERS
Basically, VCS Async, Async Plus, And Viewer models replace the Microsoft Windows serial driver. This is done in order that we can obtain line And modem status along With each character in or out. Also, the driver reduces the depth of the UART FIFO buffer to 1. The reason for this is to cause a hardware interrupt for every event: Rx character, Tx character, Line status, or Modem status. this makes it possible for VCS to provide an extremely accurate (64-bit) timestamp For each event. Additionally, it ensures proper sequencing of Tx vs. Rx data (the machine can process only one at a time, not both).

HARDWARE: WHY BUYING ONE OF OUR BUNDLES MAKES GOOD SENSE
Not all serial port hardware (including some Dell computers) implement the industry standard 16550 UART interface; it Is very important that you read the list of compatible hardware And browse the TechNotes section of this site for items pertaining to your planned serial hardware.

HARDWARE: STANDARD SERIAL PORTS AND OTHER COMPATIBLE HARDWARE
Generally, your machine will have one or two serial ports built into the motherboard. Almost without exception, these are 16550 type UARTs. Performance is limited to 115.2 Kbps. Therefore if you need the HS (High Speed) version of ViewComm Async models, you will need to acquire a card that works up to 921.6 Kbps. If you did not or do not purchase a bundle from Greenleaf Software including your VCS Async or Async HS type software plus a serial card by Quatech of your choosing, you can still purchase the card from us. We remind you that over 85% of all tech support calls are the result of attempting to use hardware that is incompatible.
NOTE: The set of serial drivers for the Quatech cards is included with your software regardless--but do not install them unless you actually have one of the Quatech cards.

THINGS THAT GO BUMP IN THE NIGHT
If you have a Dell desktop Or laptop made since January, 2000, please read Now the TechNote about Dell machines. Some users have success With Dell machines, others Do Not.

• Greenleaf VCS is a comprehensive system of data monitor and protocol analyzer solutions.
• The ViewComm System includes analyzers for Ethernet, asynchronous EIA-232 (and, using converters, EIA-442 and EIA-485), and will soon include a High Speed version of Async (including hardware supporting baud rates to 921 Kb), a Bluetooth analyzer (HIC and radio interfaces), and other communications link types.
• The VCS product family members share a common GUI for ease of use.
• And it is affordable!

• VCS Frame View shows packets decoded by DecoderScript© scripts (we call them decodes).
• Write decodes in a text editor. Syntax highlighting provided.
• With a capture file open, click "Reload Decodes" to see the results of your changes.
• Capture File Builder program lets you explore your protocol.
• All VCS models ending with "Pro" include ProtocolWorks in the product.
• ProtocolWorks, purchased with or bundled with a VCS analyzer gives you the power to create, modify and debug a protocol before you write a single line of protocol implementation code!
• NOTE that when you develop a custom protocol decode script, you can only use it on VCS systems that have ProtocolWorks installed--in other words, a "Pro" version is required.

• VCS Async can passively monitor or emulate a DTE or DCE
• Check out the ViewComm Async Plus brochure to see the multitude of ways you can tap into an RS-232 communications link and SEE!
• Need to see ViewComm Ethernet brochure? Finally and completely SEE everything on the LAN!
• VCS Ethernet shows you an incredible array of information. Over 250 flavors of Ethernet.
• Capture to unlimited size file. Store timestamps. View captured data and see exactly what happened and when.
• VCS supports a long list of protocols.
• You can bring up windows that show different views into the link session.
• Curious about async test capabilities? Check out the Cable Guide PDF
• Add ProtocolWorks to Async, Async Plus, Viewer, or VCS for Ethernet to customize protocols.

Important ways in which ViewComm lets you view the link include Events, Frame, Statistics, and Signals View. There's more, but let's explore each of these just a bit.

Frame View works in conjunction with protocol decodes, which are scripts that ViewComm uses to unscramble data on the link according to a chosen protocol stack. You can choose standard stacks or create your own. With ProtocolWorks installed, you can create your own protocols and stack. A list of frames appears; selecting a particular frame shows not only the header, data and overhead in the frame, but a tree view that you can expand as desired to show inner layers of a protocol stack. If you have the TCP/IP Protocol Stack active, you can see inner protocols such as TCP, HTTP, VJP, and others. Other protocol decodes are SLIP, Async PPP, and Ethernet. You really have to see this to believe it! Download the (VCS Async Plus Pro) demo now!

Signals View (and a special Breakout Box view) show the state of control signals and indicates the number of transitions (changes of state) of each (not relevant to VCS for Ethernet).

Frames are decoded at the bit level. This means the Protocol Decode pane of Frame View can be expanded to let you see individual bitfields, flags, addresses, CRC, and other elements of a protocol header / trailer.

If you work on protocols, developing, responding to RFCs for a new flavor of some protocol or a totally new one, the VCS ProtocolWorks option lets you interactively design and test a protocol decode. You can modify existing decodes, adapt them to your use, or start from scratch. ProtocolWorks include a complete DecoderScript Language Manual with a comprehensive tutorial, and a Methods Reference. You can also create custom methods using Visual C++ 6. Methods add power to decode scripts.

All of these products share common GUI elements and operational logic, protocol decodes, and other aspects that will get you and your staff up to speed on upscale products quickly.

Want USB? FireWire? Talk to us.