Some comments on K2KW's insightful note on using the NAU utility:
>- All logs that are planned to be merged must have the same bands set
>up. For example, I had my
>original files set up for 80-6m (using NA Logger w/ Countries), but
>additional files were created that had the default bands set to
>160-10m. Logs with different bands won't merge. (this also appears true
>for combining any contest logs, not just NA Logger w/countries)
NA needs to be able to correct QSO frequencies to "bands" in order to be
able to provide totals. Some folks have asked why there are only nine
available bands - this is because of the screen limitations and the
available space for the score window for nine bands. In reality, this
primarily hampers FD ops and the VHF crowd. I guess from Ken's experience
we need to add DXers to that list.
>- All logs that are planned to be merged must have the same contest
>selected. NA Logger w/ Countries counts as a contest, and cannot be
>merged with any other contest. This is
>true even when the bands are the same as in the above example.
This is necessary because different contests define the data fields
differently. Showing QSOs from different contests simultaneously would be
bizzare on the NA screen.
>- Changing contests on the fly may not work in all cases. Changing the
>contest from a NA Logger w/ Countries to NA Logger w/ Grids crashed on
>me. This may be akin to N7TR's problem and actually be a memory
>management issue since the log in question had 3000 QSOs. I have not
>checked this with other contests.
I think Ken's conclusion is correct. Try the -GW switch and it should work.
>- When merging files, the new combined (merged) file needs to be given a
>new name. The new .QDF file should not use the name of an existing .QDF file.
When merging file1 into file2, you cannot write the results back to file1
because in most cases the merged file will be bigger and you'll be
overwriting QSOs in file1 that you have not merged yet. The only safe way
is to write the results to a separate file. I supposed this could be
automatically renamed to file1 if the operator desired. However, since the
result is separate anyways, it seemed ultimately safer to require it to be
uniquely name. In this way, if anything goes awry with the merge, you
still have the two original files untouched.
>- Converting a .QDF file to .RES results in a .RES file that is NOT CT9
>compatible. I think it's CT7, but not sure. (can this be updated to
>produce a CT9 file?)
>
>- There is no utility to convert a .RES file to .QDF - can this be added to
>NAU?
These two topics are related. When NAU was first written, the .RES format
was from CT7. There is no documentation on the format of the .RES files -
everything I did was by making files from CT7 and examining the
results. As the .RES format changed from CT7 to CT8, then CT8 to CT9, I
was less inclined to try to stay compatible, particularly as CT and NA
added more and more formats. Therein is the challenge - to be able to
interpret a .RES file from any contest CT supports, and to translate it
into an NA file for an equivalent contest.
>- When using NAU to delete QSOs from a .QDF file, do NOT remove QSOs if
>the file is a serial number based contest! Removing QSOs will change the
>serial numbers in the log, such that sent and logged serial numbers are no
>longer the same. There is no warning about this section of the manual
>(Appendix B, page 7)
This is not true if you have "QSO numbers by band" turned on. In this
case, the actual QSO number is stored in the QSO record. I just made a WPX
CW log with "QSO numbers by band" turned off and Ken is correct - take out
a QSO and everything gets resequenced. In looking at the code, I thought
this has been taken care of, but apparently not. We'll look into this
right away.
>- If your log happens to get corrupted, try writing a .SDF file using the
>NAU utility and editing it in Word Pad or something. Remove the
>bad/corrupted QSO lines, and then convert back to a .QDF using the NAU utility.
This is a good technique. However, I would use NotePad instead of
WordPad. Just today I got a ARRL 10M file that the ARRL had edited with
WordPad and there was a bunch of junk data added before and after the
log. The log WAS intact, so ripping off the junk with NotePad restored the
file.
Actually, the DOS editor (EDIT.EXE) is even better because it has a line
number display which is useful for lining things up. However, I recognize
everyone uses Windows now so a Windows editor is better. Anyone have a
suggestion for a good one? I need one for the ARRL 10 logchecking I do.
The only other tip I would add goes the other way. After a big
multi-multi, particularly in WPX with by-band serial numbers, I like to use
the function under F1 - File Conversions, F6 - Separate a .QDF file. I'll
take the files from each computer (one from each band) and break it down
into separate bands. Then I'll take just the files from that computer's
band (i.e., 10M from the 10M computer, 15M from the 15M computer, etc.) and
merge them together to make the final log. We've never seen a real problem
necessitating this, but its good for piece of mind.
Dave Pruett, K8CC
DATOM Engineering
datom@contesting.com
http://www.datomonline.com QRV soon!
--
Submissions: na-user@contesting.com
Administrative requests: na-user-REQUEST@contesting.com
WWW: http://datom.contesting.com/
Questions: owner-na-user@contesting.com
|