Banner not found

Technical Information

This section provides an overview of the technical aspects of CQ/X including the following :

System Requirements

CQ/X was developed for the Windows OS and has been used primarily on WinXP(both the 32-bit and 64-bit versions). It has also been tested on Win2K. It has not been tested on Win98 or on Vista. User K5END has recently (January 2011) reported success using the program with Windows 7 with the only problem encountered being finding drivers for some of his USB-RS232 adapters. The machine I use for mobile operations is a Dell Latitude D400 running XP. The machine has 1GB of RAM and runs at 1.7Ghz. Detailed description of requirements for use of the software under various operating scenarios can be found in the What You Need document.

Program Development

CQ/X was developed for the Windows OS in C++ using Borland's C++ Builder 5.0. The main executable as well as all dynamic link libraries were developed using this environment. CQ/X  is a multi-threaded application with separate threads running the interfaces to the GPS, the radio, and the keyer with listener threads in the main user interface listening for updates from the GPS, the radio, and the WinKey devices.  

Program Structure

CQ/X is structured around a main user interface and  a number of dynamic link libraries that give the contest and the various devices their personalities. These include the following:

  • CQXClient.exe - the main user interface module
  • SioElecraft.DLL - implements the K3 Remote Kit
  • SioNMEA.DLL - implements the interface to a general-purpose GPS using the NMEA protocol
  • SioWinKey.DLL - implements the interface to the WinKey
  • SioMLKey.DLL - implements the interface to the MiLog keyer
  • SioIcom.DLL - implements the interface to Icom radios
  • SioKenwood.DLL - implements the interface to Kenwood radios
  • SioYaesu.DLL - implements the interface to Yaesu radios
  • TQP.DLL - implements the processing of all state and regional QSO parties including the automatic county detection logic and other calculations that use GPS data. Also implements some user interface elements related to planning and post-contest processing for QSO parties.
  • ARRLSS.DLL - implements the processing for the ARRL Sweepstakes
  • NAQP.DLL - implements the processing specific to the North American QSO Party
  • NA_Sprint.DLL - implements the processing specific to the North American Sprints and the NCCC Sprint
  • IARUHF.DLL - implements the processing specific to the IARU HF contest
  • RAC.DLL - implements the processing specific to the RAC Winter contest
  • LogData.DLL - implements dupe checking functions for all contests
  • SumData.DLL - implements the preparation of summary sheets where required Top

Data Files

For any given contest CQ/X is driven by a number of different data files that are contained in separate directories for each contest. These files include the following where the <*> will be a different name for each contest:

  • <*>.def - this is the definition file for each contest that contains the type of duping and mult counting to be performed, how the score is computed including any bonus situations, the location of the multiplier files and any modifications that need to be made to the multipliers (e.g. DC counts as MD, AK and KH6 are considered DX, all DX counts as a single mult or no mult, etc)
  • <*>.mlt - this is the file that defines the mults for the contest. It is in the format of the cty.dat files but, in the case of the state and regional QSO parties, it contains an extra line of data for each county that defines the list of counties that are adjacent to the given county. The adjacent county list is used to improve the performance of the county detection logic as described below and to simplify the user's selection of a sequence of counties by only presenting a list of counties adjacent to the most recently selected county.. 
  • <*>_Polygon directory - each of the state and regional QSO parties contains a Polygon directory that contains a separate pair of files for each county in the state or region. One of the files of the pair contains an ordered list of (latitude,longitude) points that define the boundary of the county in spherical coordinates. The other file of the pair contains similar information but the ordered list is in rectangular flat earth coordinates with the origin of the coordinate system at the geometric center of the polygon. This second file also contains the radius and center point of the smallest circumscribing circle with center positioned at the geometric center of each of the polygons. The polygon file containing latitude and longitude data has been extracted from data provided by the US Geological Survey and made available on the internet. The second file of the pair is built from the first file during assembly by the author of the data required to support a given state or regional QSO party. 
  • <*Map>.bmp - this is the county outline map(s) of the state(s) in the state or regional QSO party. These maps are freely available from the US Census bureau and have been downloaded from the internet. Top

County Detection Algorithm

As indicated above, each of the counties in the state or region is modeled as a polygon using data that has been extracted from USGS shape file data downloaded from the internet. This data extraction was performed using a commercial product (GlobalMapper ver 7.0) and then put into final form for CQ/X using a set of utilities (QPTools) developed by the author for automating many of the tasks required to build the data needed to support the QSO parties.

Some of the polygons used to model the county boundaries are quite simple and include less than 10 points while others that are defined by rivers or coastlines may contain 500-1000+ points. For example the total number of polygon vertices  required to define the 254 counties in Texas is approximately 33000. Once the trip is underway the job of the county detection logic is to determine, at whatever period specified by the user (as low as every 4 seconds), which unique member of the set of polygons contains the current latitude and longitude point provided by the GPS. The process consists of the following steps:
  • Step 1: On starting to receive GPS data scan through all of the circles that circumscribe the counties and eliminate from further consideration any counties whose circumscribing circles do not contain the current point. This is a relatively easy task since it only requires calculating the distance from the current point to the center of each circumscribing circle and eliminating any counties for which this distance is greater than the radius of that county's circle.
  • Step 2:From the short (usually less than 6) list of remaining counties examine each in detail by performing a wrapping number analysis. This means traverse the boundary of the polygon while counting the number of times you wrap around the current point. If a county contains multiple polygons in its model -- this happens most often in counties that are along the seacoast -- examine each of the polygons to determine if any of them contain the current point. Once a county in the list is found that contains a polygon that wraps an odd number of times you've found the county containing the current point.
  • Step 3: Once the process has begun and has moved into the updating phase reduce the amount of work in steps 1 and 2 by keeping a pool consisting only of those counties that are adjacent to the current county and perform the step 1 screen only on those counties. When the county changes update the pool by removing some members and adding others.
That's the highlights of the technical aspects of the project. Suffice it to say that it has been a non-trivial exercise to carry out the implementation of the above ideas and to ensure that all of the parts play well together. Readers interested in additional details about any of the technical aspects should feel free to contact the author for further discussion by sending an email to the address given on the Support page. Top

Copyright: C.W. Sanders, NO5W
Last Updated:27-April-2020