• You can select timestamps to automatically be attached to each byte of data, each signal transition or other event that occurs during a live session. If you capture the session to a buffer or disk file, the timestamps are recorded and can be viewed when you play the session back.
• In the example on this page, we set the timestamp resolution to "0.1 microseconds". This is as good as it gets. In ViewComm 3.3 the best resolution was 0.3 microseconds.
• The transfer was at 115,200 bps, or about 8.7 microseconds per bit. This makes a single character (1 start, 8 data, no parity, 1 stop bit) duration about 87 microseconds, a number we will verify visually below.

Resolution can be set as indicated at left, from 1.68 seconds down to under 1 microsecond.

As indicated at right, you can select the number of decimal places displayed with timestamps wherever they appear in a view.

In Event View we have selected the
first character of a frame (yellow).

Note the open flag (blue) to the left,
indicating the start of a frame.

Above is the timestamp as it appears in Event View's Status area. Note that it has been shown with 5 decimal digits as selected above.

In Frame View, the Summary Pane has Frame 1 selected (yellow). Notice the timestamp is identical to that for the character selected (hex ff) at above left.

Above is the Signal View with the yellow highlighted area corresponding to the frame and character we've been looking at. Notice the timestamp in the lower right corner is near to that for the above views. It represents the time of a signal transition.

Back in Event View, we've selected the next character after the one explained above.

And here is the timestamp for the selected (yellows) character. Note that the difference in time between the 'ff' and the '7d' is approximately 80 microseconds. We went back and changed the timestamp digits displayed to 6 and found the value to be 84 microseconds.

Recall at the top of this page that we predicted the duration of a character in transit to be about 87 microseconds...it seems we lied a little bit. Sorry.

                  ViewComm Async II