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