The RS232 communications link from the counter is uni-directional. The counter transmits, but does not listen. The data is sent in "packets", one per counter cycle. In most modes this means about five frames per second. In high resolution mode the data is sent at about one frame per second.The serial data frame consists of 16 bytes, stored in RAM and sent sequentially. The first 12 bytes are analog data, two bytes per channel, followed by four frequency count bytes. In order that the data should be "human readable", the data is sent as two ASCII characters per byte, making a total of 32 ASCII characters per packet or "data frame". The data is transmitted in a 34 byte packet terminated with <CR><LF>. The packets are transmitted in 9600-N-8-1 format. Although no checksums are used, the host application can run a simple error check by looking for exactly 32 bytes between each <LF> and the following <CR>.
Since the data is sent in "human readable" (ASCII) form, it is possible to monitor the data using a Terminal program, such as was used to capture the above examples. This is still a good method to use if you wish to capture the raw data to a file, but the PC program offers many advantages, such as conversion to real data units, scaling, digital and bar-graph display, as well as trend graphing and data logging. In addition, the display is stable, rather than continually scrolling up the screen.
The data can be scaled in the PC, where floating point arithmetic is easy to achieve. In the sample program both scaling and offsets are allowed, and the factors are defined in a setup file. The scaling allows easy calibration on a per-channel basis. Frequency offsets are easily added.
Negative scaling factors can be used, for example allowing a reverse operating VFO (one below the IF frequency) to display actual received frequency!