WriteLog contest module development – Part 5: Supporting Structures

A couple of easy but important changes need to be done to this structure in SKCCWESmm.h. Leave the MAXIMUM_BANDS constant alone. We will return to the very important CONFIG_LENGTH constant defined here due to its use in other parts of the module. Defing MAX_NAMED_MULTS to match the number of mults named in the module’s INI file, SKCCWES.INI. MAXAYG defines the maximum number of as-you-go multipliers are available. For an SKCC contest, it isn’t likely an op will work all the members but it doesn’t hurt to make sure the list is big enough. AYGSTRING_WIDTH needs to be large enough to hold a member’s SKCC number, including the honorary C or T.

enum { MAXIMUM_BANDS = 42,
CONFIG_LENGTH = 14, // must match the number in SKCCWESdat.cpp
MAX_NAMED_MULTS = 292, // matches number of mults in SKCCWES.INI
MAXAYG = 6000, // exceeds current SKCC member count
AYGSTRING_WIDTH = 6, //SKCC Number of 4 digits plus C or T plus null char
};

Now set up the INI file for the contest. Edit the Init() method of the main class; I called the file SKCC_WES.INI. I created the INI file by copying the United Nations three letter codes for areas and countries into the INI file. Delete USA and CAN, and changed the lines to break them into alphabetic groupings like: “=A” and “=B” and so on. I copied the North America multipliers from namedmul.ini, taking only the two NAS sections. I renamed the sections to [SKCC_WES] and [SKCC_WES-ALIAS]. The details are in the contest wizard read-me file. I changed the MAX_NAMED_MULTS to 292 in SKCC_WESMm.h to correspond to the number of multipliers I ended up with in the INI file. This INI file needs to go into the WriteLog programs folder with the rest of the contest modules and their INI files. Download the INI file I created and have a look.

The secret to displaying fixed columns with titles in the Multiplier Display.

I saw this question when searching the WriteLog email reflector for clues about contest module development. The contest multiplier display shows the multipliers you have chosen for the contest in a dialog box. The combinations include DXCC, zones, as-you-go multipliers, and named multipliers. DXCC multipliers are set using the almost universal country DAT files that you download. Zones are defined right in the contest module code as a fixed array. As-you-go multipliers aren’t defined before the contest, and named multipliers are created in an INI file that you create. Look at the INI files for other contest modules. Multipliers are defined by their name=column title combination. The column title is tricky to display in the dialog box. The secret is in the Display() method of the main class which calls a method like this:

m_MultDispContainer->MakeDisplay(1, 0,
IID_IMultDisplayPage,
(IUnknown **)&m_NamedDisplay);

There are two mystery number parameters in the MakeDisplay() method. The first one is a flag that sets whether the display handles multiple bands. The second parameter is always 0 in generated code. This flag tells WL to create fixed sized columns with headers. Set the second parameter to 1 and your named multipliers will show up in separate columns with the title over each column. The trick is easy once you see it. Unfortunately, the SKCC multiplier list does not really lend itself to fixed columns because there are so many named multipliers (at least the way I wrote it).

While you are editing SKCCWESMm.h, go ahead and add four properties to the class to save the op’s SKCC number, Bonus, Centurion count, and Tribune count.

char m_MySKCC[6];
int m_MyBonus;
int m_MyCents;
int m_MyTribs;

Remember to initialize these in the class constructor later. We’ll be using these to calculate the score for the summary and reports.

At this point, be sure to try your module out. If you haven’t already, do Tools| Register control in Visual Studio and hit F5 to launch the debugger. Start a new contest, scroll down, and SKCC Weekend Sprint shows up in the list.

The exchange input box has the fields in it and you can log Qs at this point but the score calculation is still wrong.

There were some big rocks to climb here. Download the INI file I created for this project to save yourself some work. I’ve covered a lot of ground here and it seems the context of the examples is getting lost. So download the source code that I have so far and have a look. This is actually a working module and I used it in last weekend’s SKCC WES. It worked like a charm. Don’t know if I would trust my programming on a major contest but all of those events have pretty much been written and vetted already.

SKCC WES Contest Module as of 2006-06-15

WriteLog is Copyright © 1992-2009 by Wayne E. Wright, W5XD.

Creative Commons License
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

WriteLog Contest Module Development – Part 4: The Exchange Entry Box

This series of blog posts started in part 1 where I listed the tools you will need. At this point, you should have a module that compiles, shows up in the list of contests in WriteLog, and can run in the debugger. In this part, we’ll shape up the exchange input and define what a QSO will contain.

Look at the exchange field layout in SKCC_WESdat.cpp. The structure exfa_srtu contains a two dimensional array of fields with each row defining one field. The first element is a string with the field caption. “A?” is a place holder for the as-you-go multiplier and “?M” is a running count of the AYG multiplers in the log. Actually, if you create a contest log with this module right now, you would see where these fields are used. In part 2, I demonstrated how to set up VC++ to run WriteLog when you hit F5 to run the program in the debugger. If you followed those directions, you can create a new log while tracing the module’s code. Go ahead and create a contest with the module in progress so you can see where these fields are used.

extern const struct exfa_stru
g_SKCCWESExfLayout[] =
{
{"CALL", CALL_WID, CALL_POS, A_CALL|A_PRMPT|A_MULTI|A_NOTIFY},
{"SNT", RS_WID, SN_POS, A_NUMS|A_NOTIFY|A_RST|A_OVERSTRIKE},
{"RST", RS_WID, RS_POS, A_PRMPT|A_NUMS|A_NOTIFY|A_RST|A_OVERSTRIKE},
{"RCVD", RCVD_WID, RCVD_POS, A_DUPE|A_PRMPT| A_NOSPACE |
A_MULTI|A_REQUIRED|A_NOTIFY|A_OVERSTRIKE},
{"A?", AYG_WID, AYG_POS, A_DUPE|A_PRMPT|A_MULTI|A_REQUIRED|
A_NOTIFY}, //TODO: check name, size and flags
{"ML", MLT_WID, MLT_POS, A_NOED},
{"?M", AYGMULT_WID, AYGMULT_POS, A_NOED}, //todo: NAME OF COLUMN
0 /*must end with a zero entry*/
};

Look at the field called “RCVD.” This one was generated because we selected named multipliers in the wizard. Change RCVD to QTH but don’t change the other constants associated with the field. Those constants are used in other places for handling named multipliers. Change “?M” to “BO” so we can track the bonuses there. The “BO” and “ML” fields are not typed in the exchange but calculated and show up in the log. The “ML” and “BO” are the titles of the columns in the log. Add a field called, NAME. The A_ flags are defined in the Esfsym.h file, which has some useful comments describing their definitions. Rename “A?” to “SKCC” and set the flags as shown below, adding A_NOSPACE to remove the ambiguity of a number with or without spaces.

extern const struct exfa_stru
g_SKCCWESExfLayout[] =
{
{"CALL", CALL_WID, CALL_POS, A_CALL|A_PRMPT|A_MULTI|A_NOTIFY},
{"SNT", RS_WID, SN_POS, A_NUMS|A_NOTIFY|A_RST|A_OVERSTRIKE},
{"RST", RS_WID, RS_POS, A_PRMPT|A_NUMS|A_NOTIFY|A_RST|A_OVERSTRIKE},
// Name is required but spaces are allowed to accommodate clubs, etc.
{"NAME", NAME_WID, NAME_POS, A_PRMPT | A_REQUIRED | A_NOTIFY | A_OVERSTRIKE},
// SKCC number (or power) is required in the exchange.
// SKCC has A_NOSPACE because an SKCC with a space will be different to the computer than same number without one.
{"SKCC", AYG_WID, AYG_POS, A_DUPE | A_PRMPT | A_MULTI | A_REQUIRED | A_NOTIFY | A_NOSPACE},
{"QTH", RCVD_WID, RCVD_POS, A_DUPE | A_PRMPT| A_NOSPACE | A_MULTI|A_REQUIRED | A_NOTIFY | A_OVERSTRIKE},
{"ML", MLT_WID, MLT_POS, A_NOED},
{"BO", AYGMULT_WID, AYGMULT_POS, A_NOED},
0 // must end with a zero entry
};

Define the _WID and _POS constants to match the exchange field layout. The RCVD_WID only needs to be large enough to hold a three character multiplier (plus one for the null, remember). MLT_WID defines the width of the running multiplier column in the log, not a field width in the exchange input box. RS_WID and SN_WID are for the RST and don’t need to be changed. Change the AYG_WID constant to accomodate the SKCC number. AYGMULT_WID is like the MLT_WID constant in that it defines the width of a column in the log. We’ll use that column to show if the Q is a C or T bonus. Add a _WID constant for a new name field. I set the length of the name field to 21 because really, who is going to send you the entire, 70 character name of their club? Resist the temptation to change the name of the AYG contstants! Those constants are used several places so just leave them well alone.

#define CALL_POS -1 /*always*/
// Setting the width of the fields here. Number is width + 1.
#define RCVD_WID 4
#define MLT_WID 3
#define RS_WID 4
#define SN_WID RS_WID
#define AYG_WID 6 // sized for SKCC number
#define AYGMULT_WID 3
#define NAME_WID 21

We began editing the _POS constants back in part 2. Set the width of NAME to 21. Edit the SKCC position constant, changing the length to 6.

// The order of these POS constants doesn't matter but associating them with the
// correct field in exfa_stru DOES matter.
// These define the location of the entry in the variable part of the QSO.
#define RS_POS 0
#define SN_POS (RS_POS + RS_WID)
#define RCVD_POS (SN_POS + SN_WID)
#define MLT_POS (RCVD_POS + RCVD_WID)
#define AYG_POS (MLT_POS + MLT_WID)
#define AYGMULT_POS (AYG_POS + AYG_WID)
#define NAME_POS (AYGMULT_POS + AYGMULT_WID)

The order of the _POS constants is not important but associating them with the correct fields in exfa_stru is very important. These constants define the offset where the fields data will be stored in the variable part of the QSO.

A note on the variable part of the QSO: this block of memory is very important and gets used everywhere in the contest module. There is a potential for nasty buffer overruns with this data structure so take care in making sure the _POS and _WID constants are correct.

We are making headway now. Compile the module and create a contest using it to see how the exchange fields and the log looks. Errors compiling and creating a contest with the module? Go back through and see if you missed something. Review the readme.txt file. Path environment variable? Including the two LIB files in the project? Things should be shaping up now.

WriteLog is Copyright © 1992-2009 by Wayne E. Wright, W5XD.

Creative Commons License
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

WriteLog Contest Module Development – Part 3: The Code

In the previous part, I worked through the easiest of the TODO items and ended up with a contest module that will compile. If you are just picking up this series of articles here, may I suggest you start at Part 1 where the tools are described.

First, lets look at the terrain from a distance. WriteLog needs to do a few things: accept program configuration and set up details, accept contest configuration details, control the rig at the op’s command, show the operator status messages as a contact is typed in, show a list of worked multipliers, add a contact to the log, show the score summary as the contest progresses, read and write the log to disk, summarize the log into reports and files to submit to the contest committee, and more such as handling spots etc. The items in this list that are unique to the contest are what the contest module needs to handle.

Most of the editing occurs in only two key source files: SKCCWESdat.cpp and SKCCWESmm.cpp. A little editing needs to be done to the resource files but all of that will be done with the Dialog Editor in VC++. Only a tiny bit of code editing needs to be done anywhere else. We will make a handful of edits to constants in SKCCWESmm.h. A little work needs to be done to the INI file for the contest and to the summary sheet templates using your favorite text and RTF file editors.

SKCCWESdat.cpp defines some data elements critical to the contest module. The exchange entry and log file columns are defined here. Definitions for three structures used throughout the module are declared here. And a handful of key constants are defined in this source file.

SKCCWESdat.cpp – key constants

  • CONFIG_LENGTH
  • NUM_BANDS
  • The width and position constants (all have _WID and _POS in the name).
  • A note on the width and position constants: this was a little confusing but the same width and position constant names defined in SKCCWESdat.cpp are redefined in SKCCWESmm.cpp. This is a bold assumption on my part but I think this is to accommodate the fact that you can change the exchange layout in WriteLog. I guess you have to expect the configuration in your module might be different than the one actually used because the operator can choose to change the layout.

    SKCCWESdat.cpp – key structures

  • exfa_stru
  • band_stru
  • g_SKCCWESConfigArray[]
  • SKCCWESmm.cpp
    There is one supporting structure defined in SKCCWESmm.cpp that will need to be edited to support a custom exchange input box and a list of constants that will need a couple of additions as well. By far, method definitions make up the most important part of the contest module and those are all defined in this source file.

    The contest module is composed primarily of one large class ::SKCCWES. SKCCWESmm.h holds the class definition and SKCCWESmm.cpp defines all of the methods that the contest module will need.

    I created a table of SKCWESmm class methods with a few notes on each one but it’s too big for a blog post. Please check the table out because it will provide a shortcut to what you will need to edit for the SKCCWES contest module to work.

    We have gained altitude but the trail has plenty of switch-backs and a few rocks left to climb.

    WriteLog is Copyright © 1992-2009 by Wayne E. Wright, W5XD.

    Creative Commons License
    This work is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

    WriteLog Contest Module Development – Part 2: The Contest Wizard

    In part 1, I outlined the tools you will need to write a contest module for WriteLog. At this point, the steps needed to set up the wizard have been done. If not, review the WriteLog contest wizard read-me file to install the template, set the Path in the Windows environment, etc.

    The Contest.

    Look carefully at the rules for the contest you are developing a module for. For this walk-through, I’m using the exchange from the SKCC Weekend Sprint rules, http://www.skccgroup.com/sprint/wes/. The exchange consists of CALL, RST, NAME, SKCC NUMBER, and QTH. The QTH is a once per contest multiplier using States, Provinces, and three character codes for DX (as defined by the United Nations). It’s a simple exchange with some quirks to make it interesting. One interesting thing about SKCC Sprints is the bonus points you get for working Centurians and Tribunes, 5 and 10 points respectively, once for each SKCC number per contest. The SKCC number will end with a C or a T for one of those honored operators.

    The Wizard.
    In VC++, create a new contest project using the WriteLog Contest Wizard. Change the project’s Location to the folder named, “writelog” that was in the contest wizard zip file.

    Contest Wizard Template

    After you click OK, the WriteLog Contest Wizard displays. Select the RST in exchange option, Mults As you go, and Named Mults. Don’t use DXCC because the rules say to use the ISO three letter country designator as the QTH. The multipliers are not ‘By Band’ because you only get to use the multiplier once per contest. Add those to the named multipliers instead of using country data. We’ll be using Mults As you go to keep score of SKCC Centurion and Tribune numbers. Leave the Class name as it is. Fill in the Contest Name and 0 for the GUID. The SKCC contest doesn’t need Cabrillo support but I’m adding it because a lot of contests support this option.

    WriteLog Contest Wizard

    The Generated Code.

    After you click the Finish button a pile of code will be generated for you. Add the Dxpref32.lib and wlogsh32.lib to the project Source Files as described in the contest wizard read-me. Now, do Edit|Find in files and search for “TODO.” You should get a list of more than 30 occurrences.

    Start with the easy items in the list. Skip down past the resource files (*.rc).

  • Change the ID string in SKCCWESMm.h from “TODO” to “SKCCWES”
  • Change the MAX_NAMED_MULTS constant to 292 (the count of States, Provinces, and country codes).
  • Set MAXAYG to 400. I don’t know what the world record for QSO count is here but 400 seems plenty from looking at past results.
  • Set the AYGSTRING_WIDTH to 6 to accommodate an SKCC number (4 digits plus room for a C or T and the null for a ZSTR).
  • Run GUIDGEN and replace the one in SKCCWESMm.h. Copy “CLSID_SKCCWESMmd” and replace “<>” with it. Get rid of the old GUID place holder.
  • Change the number of bands in SKCCWESdat.cpp to the bands listed in the rules, 160 through 6m CW by setting NUM_BANDS to 7 and changing the band_stru array to the list of allowed bands and CW mode.
  • Just delete the TODO comment for the PointsForQso() method in SKCCWESmm.cpp. Each Q is worth 1 point.
  • Change the string in the Display() method from “TODO” to “SKCC Mults”.
  • Edit the switch statements in FormatTxField() and FormatRxField() changing the second occurrence of 0 to 2.

    Edit the block of _POS constants. The actual order is not important because these just define their position in an array, not their position in the log or on the screen. Delete or comment out the #error line just above the list of _POS constants.

    #define RS_POS 0 //TODO
    #define SN_POS (RS_POS + RS_WID)
    #define RCVD_POS (SN_POS + SN_WID)
    #define MLT_POS (RCVD_POS + RCVD_WID)
    #define AYG_POS (MLT_POS + MLT_WID)
    #define AYGMULT_POS (AYG_POS + AYG_WID)

    More changes will have to be made later but for now the project will compile without errors.

    Now that the project will build, go ahead and compile it and do a Tools|Register Control in VC++. Change the Executable for debug session on the Debug tab in the project settings with the path to the main WriteLog program. With that set, we can run the contest module in the debugger and step through the code as WriteLog runs.

    Project Debug Settings

    At this point in the journey we have built the framework for the contest module, made a few edits, and compiled the code without errors. Now we leave the lowlands and begin to climb.

    WriteLog is Copyright © 1992-2009 by Wayne E. Wright, W5XD.

    Creative Commons License
    This work is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

  • WriteLog Contest Module Development – Part 1: The Tools

    WriteLog is the only leading contest logging program offering an open contest module development process for anyone with programming skills that is willing to dig in. I have traveled through the process and now I’d like to present where I’ve been and offer a map of the trail.

    The Tools

      Programming skills

    I have a BS in Computer Science with some programming experience. For this task, you will need passable C++ skills and be able to work with a project that uses the techniques for writing Windows programs as it was done in the ’90s. The generated code tends to lean toward C with some C++ peppered in. Integers, C strings, and one and two dimensional arrays hold most of the data. If you don’t know what a pointer is and how to de-reference one, you are under water from the start.

    A contest module is basically one big class with OLE interfaces and local elements all thrown together. To generalize, you will be writing methods that WriteLog calls when the user does stuff. Sometimes you are responsible for saving the information and sometimes WriteLog is asking for a detail or for you to provide score information.

      Programming environment

    The contest wizard is a project template that works in VC++ 5 and 6 only. However, once the project files have been generated you can work on the contest module in VC.NET Pro. After generating the project in VC++ 6.0, I tested the generated code with VS.NET 2005 and was able to compile a working contest module. The free Express versions of Visual Studio do not work for this task because they do not compile MFC code and you cannot edit and compile resource files. In theory, you could edit the source files in your favorite text editor and compile with the free command line compiler in the Windows SDK. Getting the template code out of the wizard would have to be up to your own devices; you would have to edit the resources by hand; and you would have to write your own make file. If you have written Windows programs beyond a simple hello-world command line application using the command line compiler, then you know what kind of high hurdle it would be to compile a module this way. I have not tried it yet, but the IDDE that comes with the $50 licensed version of Digital Mars C++ might work to edit a contest module but I’m 99% sure the contest wizard will not work with DM. Visual Studio 6.0 is your best bet.

      WriteLog software

    You need a licensed copy of WriteLog. Download the contest wizard from the WriteLog web site.

    Your first task is to do the one-time setup list of actions from the WriteLog contest wizard read-me file.

    That’s the tools you need to pack in order to get to our destination–a working WriteLog contest module.

    WriteLog is Copyright © 1992-2009 by Wayne E. Wright, W5XD.

    Creative Commons License
    This work is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

    WriteLog – A New Old Logging Program

    I operated at a big-gun contest station, W7VJ, where they use WriteLog therefore, I’m re-familiarizing myself with it. Three years ago, I gave up Writelog because N1MM had finally matured to the point where, at least, it didn’t crash all the time and the price was right. WriteLog has a large share of the contest software market perhaps because it was one of the first to work in what was at the time the latest operating system from Microsoft, Windows NT. The World DX Championships comes right out and recommends WriteLog. The program is mature, stable, and feature rich. Although I find WL isn’t intuitive to configure, once set up it works just fine.

    Contest logging software is complex and there are many reasons:
    – contests require a diverse set of exchanges. There are real problems to overcome due to the vast number of contest exchanges and their permutations. ARRL Sweepstakes is a great example. You never really know what order the exchange will come in as, making data entry, you know logging, quite difficult. The log entry isn’t valid if something is missing.
    – hams demand a long list of features, some of which are aimed at a pretty narrow audience
    – the software, almost to a one, needs hardware interface code for rigs, keyers, rotors, antenna switches, as-yet uninvented must-have hardware, etc.

    Contest software is frequently hard to configure and sometimes, use:
    – there isn’t a terribly large market, therefore writing the software can hardly financially support a development team, let alone a sole developer.
    – contest scoring is complicated with bonus points and special multipliers.
    – contesters are more and more sophisticated all the time.
    – the array of hardware possibilities make it impossible to think of every configuration, let alone home brew radio interfaces and other clever devices.
    – contest software is a hardware control program which frequently works by exclusively opening hardware, specifically COM and/or LPT ports and to some extent, the sound card.

    User application software writing directly to the computer hardware is a throwback to programs written for DOS on 8 bit computers. Back in the day, the computer was expected to do one thing at a time. Those days are long over. Your cell phone doesn’t even work that way anymore. This makes writing the software difficult and therefore, makes configuring the software complicated.

    WriteLog has one thing over other leading contest programs now, though. You can develop your own contest modules. The task is not trivial, requiring expert programming skills in C++ and a working knowledge of the MS Windows API. If you can get your mind around the way programs had to be written for Windows in 1990, can understand what happens in programs that use OLE, and have WriteLog expertise, then you can write a contest module. At least it’s possible where as N1MM, Win-Test, etc. don’t invite anyone to create their own module. The Win-Test developers are particularly closed to the idea of even adding US QSO parties to their euro-centric list of supported contests. I grabbed onto the idea that I could write my own WriteLog contest module and decided to solve the puzzle. In my next few blog posts, I’ll present a WriteLog contest module development walk-through using the WriteLog Contest Wizard. It’s going to be quite a journey.

    Did you miss me? My family did.

    Ah yes. It is hard to balance the time spent with the family, work, and hobbies. Here is a quick summary of where my radio adventures have taken me in the last couple of months:

    With the help of Bruce, AD7WV, I have been trying to figure out why my MFJ Cub puts out less than 0.1 W. It’s QRP, but not that low power. In diagnosing that problem, I posted a message on the RockMite reflector about power output because my HiMite-20 was doing the same thing. I was getting less than 0.1 W out of it too. The suggestion was to take off a couple turns of one of the low pass filter inductors and boom, I got 500 mW out. Perfect for a ‘Mite. Re-wrapping the toroids on the Cub didn’t help though. I even finished my LC tester to see if they were within spec. Turned out they were on the high side so I took a wrap off of both of them to get them where they should be. Still low power out though.

    I operated the Drake rig at the W7OS museum one Saturday. Rich, KR7W, was my only contact. He was very patient with my really bad rag-chewing skills at the key. Still, I was commenting to one of the other club members that it’s a real treat-a unique ham radio experience-to operate a boat anchor rig. I would have made a terrible novice class amateur though.

    I’m in the middle of building two new kits from Hendricks QRP Kits–the RF Probe and the Tracer/Injector test equipment. I’ve built several kits I bought there and never had a problem with missing parts. This time, both kits needed a replacement. I’m OK with that though because the kits are good quality, the PC boards are exceptional, and the build instructions are very clear and easy to follow. I really enjoy the MMR-40 kit I purchased and built. It works so much better than the Cub.

    I took the MMR-40 to Portland on a business trip last month. My room was on the 14th floor with a window that opened-perfect. I hung a wire out the window in an end-fed-Zepp configuration and called CQ for an hour with no joy. Next time, I take some 8# test fishing line and get the end of the wire out away from the building using a tree branch or something.

    Keying Three Ways

    I use three methods to key my rig: an Iambic paddle, a bug, and the keyboard. I’m not really counting the J-38 strait key since it’s rarely connected. Lately I’ve been using the bug so much that I was loosing touch with the paddles. While listening for stations I haven’t worked during the K3Y operating event, I matched the speed of my bug to my keyer. By ear, it sounds like the bug sends dits at about 23 words per minute. The I started sending a little code practice with the paddles and switching to the bug to send the same code. My fist improved right away! Hearing the correct letter spacing and dash length before sending with the bug makes a real difference. There’s nothing like a bad bug fist. Really long dahhhhs and really fast dits all running together like the op never needs to take a breath. Hate to admit it but that’s me as I get spun up into a QSO. My mind races around trying to think of stuff to say and as soon as I come up with something I feel the need to spit it all out there ASAP. It really comes down to how much you practice though, doesn’t it. If I were to make two or three Qs a day, rag chewing would come easier for sure.

    Load up little pistols. This contest is for you.

    Mix together the NCCC Thursday sprint with a little World Radiosport Team Championship and a little sailing regatta handicapping and you get the Locust QSO Party. Rick, K6VVA a.k.a. The Locust, organized the first LQP to celebrate his 50th anniversary as a ham. 2009 will be the third running of the “LQP – 52st Anniversary of License Edition.” (sic)

    The date and time: January 21, 2009 at 6:00 pm PST (not Z, PST) through 6:51:59 pm (PST). With categories that include provisions for geographic location (with much relief here in the ‘suffering sevens’), NCCC membership, a NOOB category, and a green category (wind or solar power). (READ THE RULES.)

    Rick freely admits that the rules are a bit complicated and suggests printing, reading them at least twice, and making notes in the margins to make sure you understand them. There are strict rules for how much power you may output according to the type of antenna you are using. I’m in the 100 watt class because of my lower than 40 feet ground mounted vertical. If you are running stacked 3 or 4 el 40M aluminum or wire yagis, you are limited to 15 watts. (READ THE RULES.) No SO2R, SO2V, Packet spots, or Skimmer. Exchange is your name and QTH (READ THE RULES). The handicapping system is almost pure genius.

    This contest sounds like a brilliant good time. It’s on my calendar.

    Wooot! K7OG Will Certainly Make It To K5ZD's Partial Check DB

    I know K7OG will be K5ZD’s super check partial lookup database because I worked K5ZD during the ARRL RTTY Round Up. Hah! I don’t have to depend on submitting a log or hoping for some other operator to submit their log.

    The RTTY Round Up contest was pretty fun. Just casually, I worked over 100 stations with 38 domestic and 5 DX multipliers. RTTY lacks a certain amount of excitement for me. It starts to boil down to Read the Call, Type or Click the Call, Ask for a Fill or Hit the Exchange F key, and Hit Enter. At one point I was falling asleep at the computer. Having a running IM chat with Matt KR7W kept me awake – and this was in the middle of the day when I had had plenty of sleep. SSB and CW just seems more interactive where at least you have to copy and comprehend the exchange in your brain before logging the contact. No disrespect to RTTY fans intended. Once you have the computer set up, the rest is pretty automatic though. Maybe its different if you are DX or a rare section. The only ND station I heard was running a giant pile-up and frankly, showing some frustration at how rude some of the callers were. I ran CQ in the last 30 minutes of the contest because by then, the big contest stations have worked everyone and operators are willing to try to dig out some weak ones. I worked ID that way.

    My little IC-718 works great for RTTY. RTTY is one of the selectable modes and the 500K CW filter I have installed narrows the passband right down onto the signal. It helps to have my microHAM MicroKeyer feeding FSK directly to the rig too. Makes my RTTY signal very clean indeed. I like using DM780 for general CW logging but the software doesn’t cut it for RTTY. It doesn’t have an option to push data out through a serial port and will only generate soundcard RTTY. Good enough if you take the time to get all of the sound card settings right but who has time for that?