MicroTAP vs. LogStream
NOTE: You can use MicroTAP with SeeStream since MicroTAP will run in a DOS box under Windows 95 and SeeStream can read MicroTAP log files.
General Comparison: MicroTAP and LogStream accomplish serial data collection very differently. Your intended use will determine which product is most appropriate. The predominant difference is that MicroTAP is character oriented while LogStream is packet oriented (packets are variable length groups of characters that may or may not be related to each other). LogStream differentiates two types of packets: Driver packets (groups of unrelated characters) and user-defined filter packets (groups of related characters).
MicroTAP is Character Oriented: MicroTAP never enables UART FIFO buffering, so each character generates a separate interrupt and is timestamped with a unique event time code. This yields high resolution and the finest granularity possible (i.e., single characters). These characteristics are excellent for debugging true (simultaneous) full-duplex and/or highly interactive protocols that turn the line around frequently. MicroTAP excels at debugging low-level protocols and time-related problems, and must be used when knowing the relative arrival order of nearly simultaneous characters from different sources is important.
LogStream is Packet Oriented: To accommodate the multitasking Windows environment, LogStream always buffers incoming characters (both in the UART FIFO and in the Windows driver) so it is not possible to timestamp each character with a unique time code. Nor is it possible to know the exact arrival order of characters from different sources that are buffered up within 20 or 30 milliseconds of each other. To clarify the effects of buffering, LogStream marks the buffered groups received from the serial driver as "driver packets." Additionally, LogStream allows the user to define "filter packets" to mark groups of characters based on their values. In this respect, LogStream is considerably more "content-aware" than MicroTAP, so LogStream excels in applications where content is the primary concern (i.e., the low-level protocols are robust).
Resolution and Granularity: MicroTAP runs under DOS and implements its own serial interrupts, achieving microsecond timestamp resolution. At this time, LogStream uses the Windows serial drivers to collect data which limits the character resolution to one millisecond. In actual practice, the Windows drivers achieve character resolutions in the range of 12 to 15 ms. As the baud rate increases, the serial driver buffers more characters at a time, further reducing granularity and decreasing timestamp resolution. The advantage to using the Windows drivers is stability, flexibility (LogStream runs on NT 4.0 as well as Win95) and the ability to sustain high data rates. When Microsoft merges the driver model (Windows 98 and NT 5.0) we will implement our own serial driver to improve resolution and granularity under Windows.
Buffering Surprises: The impact of buffering on communications protocols can be surprising. Here is a simplified example of what can happen. Let's assume you have your UART FIFO buffering threshold set to 8 (typical), which means that at least 8 characters must arrive in the FIFO before the UART notifies the software that characters have arrived. For discussion, assume the following data stream wherein blue represents commands from one device and red represents responses from another device:
Ch1: 01 02 07 08 13 14
Ch2: 03 04 05 06 09 10 11 12
When buffered, combined responses that are longer than their associated commands may trip the buffering threshold and be returned first by the Windows driver, as in:
Ch1: 01 02 07 08
Ch2: 03 04 05 06 09 10 11 12
The timestamps of both command and response characters will be within 12-15 milliseconds of each other, indicating that they arrived nearly simultaneously.
Home Page • Page Index