Hi Folks,

There may be confusion as to how IOTAs (Islands on the Air) work in
DX4WIN, how they get updated, etc.  I would like to try to explain how
this works.  I started to write an application note for IOTA, but
never really finished it, nor did I make it visible on the web site (I
guess I'll do that).

    http://dx4win.ad1c.us/appnotes/iota.html

I'll just hit some of the high points below.


The IOTA field in your logbook works like the State and Grid fields --
it is stored with the QSO record, and does NOT change when a new
country file is released.

When logging a QSO, DX4WIN may automatically fill in the IOTA field if
it can uniquely determine the IOTA from the callsign and date, based
on information contained in the country file.  Some DXCC entities like
Barbados, 8P have a single IOTA (NA-021).  Some IOTA are determined by
prefix, for example, IG9 is AF-019 and IH9 is AF-018.  And there are
thousands of callsigns in the country file that are mapped to a
particular IOTA, for example CE7KF is IOTA SA-018.  DX4WIN will also
attempt to assign IOTA when importing QSOs.

 In DX4WIN 9.01 and later, there is a Multiple QSOs operation for
checking the IOTA fields in your log:

    QSO | Multiple QSOs operations | Check IOTAs.

This does the following four things:

1.  If the IOTA field is empty, and the IOTA can be determined from
both the callsign and date (i.e. via the country file), then an IOTA
is assigned to that QSO.

2.  If the IOTA field is not empty, is the IOTA correct based on the
callsign and date, given the information in the country file?  In
other words, if the IOTA field was blank, would DX4WIN have filled it
in with the same IOTA as you chose?  If they do not match, DX4WIN will
do the following two things:

    a.  Put the "correct" IOTA into the IOTA field in the logbook.

    b.  Add some information to the "Notes for this QSO field":
"IOTAMSG: Bad IOTA=OC130"
        In this case, OC130 was what your log had *before* running Check IOTAs.

I wrote "correct" because the country file can (and probably does)
have errors.  If you think that DX4WIN made an incorrect substitution,
and you have the QSO confirmed, please send me the information from
the QSL card (IOTA and Island Name) as well as the callsign and date,
and I'll look into it.

3.  If the IOTA Island field is empty, DX4WIN will populate that field
in the logbook if the IOTA group has only one island.  Some examples
of this are Barbados, 8P (IOTA NA021) and Luzon Island, DU4 (IOTA
OC042).

4.  If the IOTA Island field is not empty, check that it is a valid
island for the given IOTA group.  If the island if not valid, you will
get an error message like this:

    IOTAMSG: Bad Island=00006312

The number above refers to the numerical code provided by the IOTA
committee to represent the island name in the IOTA group.  It is
unusual for this to happen, but not unheard of.  I had a number of
such errors in my logbook from QSOs which had the wrong prefix/country
assigned to them at one point in time, but subsequently changed based
on new information in the country file.

There is also a Multiple QSOs Operation to remove all the IOTA error
messages from your log, once you have resolved all the problems.

So in summary:

1.  DX4WIN assigns the IOTA field automatically if it can do so.
2.  Subsequent releases of the country file will not change the IOTA
field in any QSO.
3.  There is a Multiple QSOs Operation to check the IOTA fields in your log.

Please reply to me directly or the reflector if there are any
questions about this.

73 - Jim AD1C

-- 
Jim Reisert AD1C, <jjreis...@alum.mit.edu>, https://www.ad1c.us
______________________________________________________________
DX4WIN mailing list
Home: http://mailman.qth.net/mailman/listinfo/dx4win
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:DX4WIN@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html

Reply via email to