[NLRS] W0JT 10 GHz logger updated (again!) -- L O N G

[John P. Toscano]

Oops, I hate to say this, but thanks to a kind soul who sent me a log to 
  convert from version 2.03 to version 3.01, I found a few more bugs! 
These have been fixed, resulting in version 3.02, which was uploaded in 
xls and zip format to the NLRS server.

Problems discovered and fixed:
   1) A QSO between two stations in the same subgrid was being scored
      as zero distance points.  Since the rules say you must be at
      least 1 Km apart, it was my intention to score this with 1
      distance point instead of zero.  This was fixed.

   2) A QSO betwen two stations in the same grid was being scored
      as zero in the "best DX by band" table also.  The log I used
      for conversion had three 24GHz QSOs that were same-grid to
      same-grid, and yet the best distance on 24 GHz still came up
      as zero Km instead of 1, even after I fixed it as mentioned
      in problem #1 above in the distance point calculation.  When
      I tested this on my own log last year, I had only one 24 GHz
      QSO, and the two stations were one sub-grid apart, so the
      non-zero distance was computed correctly in the best DX by
      band table.  Anyway, this is now fixed.

Enhancements made while fixing the bugs above:
   1) On the Settings page, the year defaults to the current year,
      like the "tool tips" help says it does.  You can still change
      it if you wish.

   2) On the Settings page, there are two cells that take on a
      value of TRUE or FALSE.  These now have a drop-down list
      with just those two choices, to help insure you get it
      entered correctly.

   3) On the Settings page, the "Call Area" cell is supposed to
      contain your FCC Call District number, such as 0 or 9 or
      whatever.  This is now a drop-down list to help dissuade
      you from entering the Section Name or something else here.

Shortly after I uploaded this corrected version, a few folks
downloaded it and found some other problems, and made some other
suggestions for enhancements.  These were taken care of also, resulting 
in a version 3.03-vba, which is now uploaded to the web in place of 
versions 2.01 and 3.02.

   1) In version 2, the columns of data that frequently stay the
      same most of the time were set to automatically fill themselves
      in with data directly above them, such as calendar date, the
      other station's grid, the band indicator, and the operator's
      grid.  In version 3, this was accidentally omitted.  It has
      been put back into place.

   2) I was asked to re-order the columns in the LogData page, to
      make data entry more efficient.  This means keeping the
      columns that change most often (time of QSO, other operator's
      callsign, etc.) close together, and the columns that change
      less often further away, where you need to use the tab key, a
      cursor key, or the mouse to get to them.  The spreadsheet
      LogData page was originally modeled after the ARRL submission
      form.  Although the SubmissionPage still keeps as close as
      possible to the ARRL format, the LogData page no longer does.
      The columns to the right of the date are arranged more or less
      in order of decreasing frequency of change: Time (changes for
      almost every QSO), other operator's callsign (changes every
      QSO except for working the same operator on 2 or more bands
      in a row), the Band/On/Off/End-of-Log indicator (only changes
      a few times in most logs except for rovers with a lot of off
      times between stops), and the operator's grid (barely changes at
      all for a "fixed" station, and changes only at moves for a
      rover station).  You now don't have to move around as much in
      the page to enter your data.

Based on some other comments I got from folks who tried to convert their 
version 2 logs to version 3, or enter log data into version 3.01 anew, 
here are some tips to help make it more successful.

1) If you are cutting and pasting from version 2 to version 3, you
    should realize that it is NOT a simple cut-and-paste process.  In
    version 2, there are some HIDDEN columns in between data columns
    where you enter data on the LogData page.  Even though the column
    heading names seem to be in the exact same order (at least up to
    version 3.02, but because of the hidden columns, you have to cut
    and paste in 3 discrete blocks to make it work.  And if that was
    not bad enough, the re-arrangement of the columns in version 3.03
    is so extensive that cut-and-paste, while still possible, is even
    harder to do.  For this reason, I again extend the offer to convert
    logs from one version to the other on request.

2) When you enter a date in column A of the LogData page, *DO NOT* try
    to enter it in the format that the rest of the column displays.  If
    you do, Excel treats your date as text, and that causes all of the
    remaining time & date calculations to fail.  So, if you worked the
    first day of the first weekend this year, you should type into cell
    A4 just the simple entry:
       8/19/2006
    If you do, then Microsoft Excel will understand it to be a date, and
    will format the display to look like:
       Saturday 08/19/2006

3) If you happen to recall using version 1 of this file, you might also
    get tripped up in column B, the Time column.  Version 1 required you
    to enter the time as 07:30 (for example), while all of the versions
    from 2 onward have simplified this to 0730 (for the same example).
    Actually, as it turns out, I really programmed the spreadsheet to
    accept EITHER format (with or without the colon), but you should
    probably stick to one format or the other to maintain sanity.

If you seem to be having problems with date or time entry, try entering 
what seem to be reasonable values (with the limitations mentioned 
above), and then look in column V of the same row.  If it says #VALUE! 
or if it is completely blank, then you have a problem with the date 
(column A) or the time (column B).

4) It is necessary to follow the prescribed overall structure of the
    worksheet.  The first row must be the *ON* record (row 4 is already
    filled in for you, so this is hard to get wrong), followed by one or
    more data records (valid date, valid time, valid callsign, valid
    grid for other station, valid band, valid grid for your station),
    followed by an *OFF* record.  These 3 types of records can repeat
    multiple times as needed.  Rovers, for example, will have an *OFF*
    record followed by an *ON* record every time they move to a new
    grid, whereas fixed stations might have a maximum of 4 blocks of
    *ON*/data/*OFF*, one for each of the 4 days of the contest, or even
    fewer if they don't play for all 4 days.  Finally, after the last
    *OFF* record, there must be an *EOL* record to mark the End of Log.
    If you forget the *EOL* record, the SubmissionPage and LogSheet page
    will have zeroes or errors instead of valid data in multiple places.
    Since we have reached the end of the first weekend, you might want to
    TEMPORARILY insert an *EOL* record after the *OFF* record that
    follows your last (so far) QSO.  When the second weekend comes
    around, just change the *EOL* to a new *ON* period and continue to
    fill in the log.

5) If there is no distance showing up in column H of the LogData page,
    even after you enter valid grids for yourself and the person you
    contacted, the most likely cause is that the KK6MK VBA code is not
    being allowed to work in your system.  A quick test showed me that
    even if the date, time, callsign, and band fields are not entered
    at all or have invalid data, if there is a valid grid specified for
    both yourself and the other operator you contacted, the distance
    should appear in column H as a non-zero value.  Go to the Excel
    menu Tools | Options | Security and confirm that it is set to the
    value MEDIUM.  To confirm that the KK6MK VBA library is present,
    Press Alt+F11 to bring up a new window, from which you can click
    on View | Object Browser to bring up a small Object Browser window.
    In the drop-down list at the top-left of the new window, select the
    VBA Project object type.  Click on the <globals> class, and you
    should see six functions listed there:  ATan2, Bearing, Distance,
    LatLon2MH, MH2Lat, and MH2Lon.  If not, then this is the problem with
    the distance calculations.  If this still doesn't locate the problem,
    try going to an empty cell in column G (by default, most of this
    column is NOT protected from data entry, and type in:
      =Distance(47,-93,48,-93)
    When you press Enter, the formula should calculate to a value of
    111.1805338 or something close.  If instead you get #VALUE! it means
    that the VBA code is being disabled.

    If none of this fixes the problem, please consider sending me a copy
    of the file you're having trouble with, and I will be happy to see if
    I can figure it out and fix it for you.

Well, that should be enough of my drivel for now.  Happy microwaving!

73 de W0JT