[Cwo] all missiles have been launched

Mon Aug 15 18:41:18 PDT 2011

Alan et al --

I've uploaded a new version of the CWOpsLogAssembler. You can download 
it from http://www.no5w.com/Documents/LogAssembler-081511.zip

The contents are the same as before with the addition of some test logs.
Setting up to use the application is the same as before.

New features include the following:

1. Validity checking has been added to the QSO lines. The checking 
reports the following errors
MISSING_DATA - some data items are missing
NOT_IN_PERIOD - date/time not in any valid CWOpen period
INVALID_FREQ - item in frequency position is not valid for CWOpen
INVALID_MODE - item in mode position is not valid for CWOpen
INVALID_DATE - item in date position is invalid, in wrong format, etc
INVALID_TIME - item in time position is not a valid time
INVALID_SCALL - item in sent call position is not a call
INVALID_SNUM - item in sent number position is not a valid sequence number
INVALID_SNAME - item in sent name position is not a valid name
INVALID_RCALL - item in received call position is not a call
INVALID_RNUM  - item in received number position is not a valid sequence 
number
INVALID_RNAME - itme in received name position is not a valid name

As implied in the above the validation process just looks at what it 
finds in each of the positions of the QSO line and determines whether 
that item is valid for that position. It does not go any deeper than that.

2. If a log has problems as determined by the validity checking a file 
specific to that log is written listing each QSO having problems and an 
indication of why each QSO entry failed. These error reports are written 
to a directory called ProblemLogs that is a subdirectory of the home 
directory of the application. The file names are <LogName>_ERRORS.txt 
where <LogName> is the name of the original log without the extension.

3. At the user's option a status indicator can be added to the end of 
each QSO line in the assembled composite log. These indicators are the 
left hand items in 1 above. In this case the errant QSO entries are 
written to the composite log to the extent possible. Items that are not 
determined due to errors are indicated with ???? marks.

4. A file listing all of the logs processed on the current run in 
alphabetical order is included. User can specify name/location of this file.

5. A file listing all of the unique calls received in validated QSOs on 
the current run in alphabetical order is included. User can specify 
name/location of the file.

I believe that addresses previous comments/requests. Let me know if you 
have questions, etc. Since no one has hollered that their application 
complained on startup about missing DLLs I assume there have been no 
problems along those lines.

73/Chuck

On 8/14/2011 1:06 PM, Chuck-NO5W wrote:
> 1. The application is intended for processing after the log deadline has
> passed and any revision logs have replaced earlier versions.
>
> 2. The application was developed on the assumption that the logs are
> valid Cabrillo. I can add some validity checking to flag logs not
> meeting that requirement.
>
> 3. Your assumption is correct. The application processes all files in
> the specified directory having the specified extension. No problem
> creating a list of all the files that were processed. This info is
> currently shown in the status window so a hard copy listing would be no
> problem. The list of all received calls, sorted alphabetically, is also
> no problem.
>
> 4. Adding a flag or comment to errant QSOs and leaving the QSO in the
> composite log is no problem. In my processing I have always only allowed
> QSOs in the composite log for importing into the database that meet the
> basic requirements.
>
> I'll make the requested changes and send you something later today or
> tomorrow. The only one that will take any time is item 2.
>
> 73/Chuck
>
> On 8/14/2011 12:06 PM, Alan Maenchen wrote:
>> Chuck,
>>
>> A couple of questions:
>>
>> 1. What happens with multiple log files from the same guy? He sends in
>> his log, then later sends it in again with some correction.
>>
>> 2. What happens with a non-Cabrillo log .. or one that is screwed up?
>> I can probably play with this and see what happens. On the assumption
>> that we will be receiving all logs via email (the web based submission
>> is not working at this time), there will be no top level format checking
>> of logs.
>>
>> 3. I presume you look up all files that have the .log extension and
>> process them. Can you create a file of calls that were processed? That
>> would be useful. Not a big deal, but useful. This needs to be done
>> somewhere along the line, as well as a file of ALL received calls from
>> all logs sorted alphabetically (we'll cull that list for busted calls
>> manually).
>>
>> 4. The separation of obviously bad QSOs is good. However, I'm not sure
>> how useful it will be. I think it might be more useful to add a flag to
>> the QSO in the log extraction file (P1, P2, P3) like this:
>>
>> QSO: 80 CW 2011-08-21 0005 K5MPO 22 AL N3JT 79 JIM ERROR: INVALID TIME
>>
>>
>> That way the log stays intact and further processing can key on that
>> flag for scoring.
>> Further processing can then add similar flags for bad NR, bad NAME, NIL,
>> etc.
>>
>> 73, Alan AD6E
>>
>>
>>
>> On Fri, Aug 12, 2011 at 7:44 PM, Chuck-NO5W <no5w at consolidated.net
>> <mailto:no5w at consolidated.net>> wrote
>>
>> Alan --
>>
>> Here's a link to a little application I wrote for front end batch
>> processing of CWOpen logs. It will process all of the logs in a given
>> directory splitting out the header info, and the QSOs into separate
>> files suitable for then importing into a database. It also writes any
>> erroneous QSOs (out of band, out of period, incomplete data) to a
>> separate file for review. Soapbox comments are also split out into a
>> single text file suitable for importing into a word processor. The
>> source logs can contain QSOs from all periods or just a single period.
>> I've included a good bit of flexibility but the defaults are for CWOpen.
>>
>> You can download the application from
>>
>> http://www.no5w.com/Documents/LogAssembler-081211.zip
>>
>> The zip file contains the following
>> 1. The application exe
>> 2. A restart (rst) file
>> 3. Three test logs
>>
>> Initially the restart file will start you out with CWOpen defaults
>> except you will need to specify various output file names, directories,
>> etc. Once you specify them the application will restart with those
>> specifications on future restarts.
>>
>> After unzipping the download file you should
>>
>> 1. Copy the exe and the rst to the directory where you want to run from
>> 2. Copy the log files to a directory
>> 3. Start up the application, set up directory and file names, etc
>> 4. Click the Process button and then review results
>>
>> The application should be portable and run without any additional DLLs
>> but if you get a complaint that it needs one let me know. I've tested it
>> a good bit on the CWOpen defaults but if you encounter any bugs let me
>> know that also.
>>
>> My understanding of how this would fit into CWOpen log processing is
>> that logs would be either downloaded from Bruce's web server and/or
>> saved from email attachments and stored in a directory on a local PC.
>> The LogAssembler would then be run against that directory to create the
>> following
>>
>> 1. Header File listing each of the entrants and ready for import into a
>> "players" table in a database.
>> 2. QSO Log File listing each of the QSOs in the CWOpen in a format
>> suitable for importing into a QSOs table in the database.
>>
>> Of course the above two files will be simple text files so other uses
>> can also be made of them.
>>
>> 73/Chuck/NO5W
>>
>>
>>
>> On 8/11/2011 8:04 PM, Alan Maenchen wrote:
>> > That's great Rob!
>> >
>> > The only remaining issues now are the Web based log submission
>> stuff and
>> > some form of log checking. I'm pessimistic about Bruce getting
>> the log
>> > submission function working. Don wants to wait until he returns
>> from a
>> > biz trip early next week before we put up a BIG note about what to do
>> > with your logs. I'm 98% sure that we'll do "Plan B" which is to have
>> > everyone email their logs to cwo at cwops.org <mailto:cwo at cwops.org>
>> <mailto:cwo at cwops.org <mailto:cwo at cwops.org>>
>> >
>> > I think I know what I'll be doing on my vacation to NC in early
>> Sept. ;-)
>> >
>> > 73, Alan AD6E
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Thu, Aug 11, 2011 at 5:14 PM, Rob <k6rb at baymoon.com
>> <mailto:k6rb at baymoon.com>
>> > <mailto:k6rb at baymoon.com <mailto:k6rb at baymoon.com>>> wrote:
>> >
>> > As of early this morning, all the publicity efforts are in play -
>> > individual invitations to anchor stations; individual
>> invitations to
>> > a large list of familiar contesters; post to reflector asking
>> > members of other clubs to post to those club reflectors.
>> > Now, we hold our collective breaths until Aug 20 at 1200Z! By the
>> > way, a disproportionate number of invitations went out to JA
>> > stations in order to increase the odds that the first session
>> > (1200Z) will be alive with JAs on 40 m and 80 m.
>> > I'm not worried about the 2000Z session because there will be
>> a big
>> > swell of NA stations going full blast.
>> > The 0400Z session could be a winner for JAs working 20 m and
>> beaming
>> > to EU. It could also be bountiful for NA stations working 40
>> m and
>> > pointing toward EU.
>> > Now, it's wait and see.
>> > Rob K6RB
>> >
>> >
>> > _______________________________________________
>> > Cwo mailing list
>> > Cwo at kkn.net <mailto:Cwo at kkn.net> <mailto:Cwo at kkn.net
>> <mailto:Cwo at kkn.net>>
>> > http://www.kkn.net/mailman/listinfo/cwo
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Cwo mailing list
>> > Cwo at kkn.net <mailto:Cwo at kkn.net>
>> > http://www.kkn.net/mailman/listinfo/cwo
>>
>> _______________________________________________
>> Cwo mailing list
>> Cwo at kkn.net <mailto:Cwo at kkn.net>
>> http://www.kkn.net/mailman/listinfo/cwo
>>
>>
>