IOTA – SOME FINAL DOS AND DON’TS

The call-sign should be the one used during the operation –the time for deciding whether to use /P, /number, prefix/ or /suffix is  before the operation takes place, not after the operation and before QSLing!

If you need to print further batches of cards, don’t change the call-sign to fit card design. And, remember, always print the island name.

If  you  include  the  IOTA  reference  number  (please  do), make sure that it is correct!

If your licensing authorities allow you a choice, avoid using a call-sign that is more usually associated with a different DXCC entity or IOTA group within your country.

In the case of island names, use the one that is commonly shown on maps – don’t translate it from the local language into English, without also highlighting the original name. Don’t include anything on the card that could raise doubts that the operation might not have been land-based.

Don’t assume that everyone knows the exact location of

your island – if it is really small, add the geographical co-ordinates and / or additional information pinpointing it in relation to a larger island in its group or to an identifiable landmark on the coast.

If you include the island name on the computer label, it is best to validate it with a rubber-stamped verification mark and your initials across the corner.

Don’t handwrite the island name on a card. With our system of decentralised checking we have no easy means of ensuring uniform treatment of cards if individual Checkpoints are required to take a view on the authenticity of every handwritten endorsement, those genuine, suspicious and in between. Sorry, we have to reject them all, no exceptions.

If you use a multi-box card with island names (and IOTA numbers) printed alongside, use a method of marking the relevant island that does not allow card-tampering.

Try to send your cards as soon as possible after the QSO. The IOTA Committee receives a lot of complaints about poor QSLing performance. These often include requests that we remove all credit for a particular operation – yes, the rules allow   us   to   do   this   in   exceptional   circumstances.   We encourage slow or erratic QSLers to pay particular attention to this important aspect of IOTA. This said, there are many DXpeditions which perform well on QSLing and we know that the IOTA community appreciates their efforts.

Submit cards that are clear and unambiguous – this means selecting  ones  that  have  a  printed  call-sign  and  island name.

If you have a choice, submit QSL cards from more recent operations rather than old ones. Expect that some ‘unique’ cards could cause problems over acceptance.

Don’t expect your Checkpoint to advise on ‘doubtful’ cards on  the  off-chance  that  they may  be  valid  for  an  IOTA. Check the cards carefully against the islands listing in the Directory and, if necessary, the co-ordinates box given for the group.

Don’t  ask  your  Checkpoint  to  break  IOTA  rules  clearly stated in the Directory. If there is a problem with the card, sort it out with the operator or QSL manager. Normally they will want their cards to count for IOTA but it is their choice if they don’t.

And, importantly, do not bypass your Checkpoint by sending your query direct to the IOTA Manager or IOTA Centre.

Remember, QSL cards need to have the island name printed on them. Handwritten endorsements are not sufficient.

Please reply to QSL requests. A lot of your contacts will be island-chasers  wishing  to  increase  their  IOTA  scores  and your QSL could be the one they particularly need.

A few words to explain our approach to ‘data-cleansing’ – removing the very small proportion of incorrect credits that inevitably accumulate in the database. IOTA Centre enters on this central database the call-sign of each credit given to a partic- ipant. In this way we have not only a permanent historical record of past activity but also, equally importantly, information on the scale of the operation, demonstrated by the volume and geo- graphical spread of participants’ credits, and often a means of identifying the operators involved.

What  should  we  do  when  we  hear  or  strongly  suspect,  on balance of credible evidence, that an earlier operation did not take place from a qualifying island, or took place from a different IOTA group than the one given on the card? We are sometimes in a difficult position that we cannot put into the public domain the full extent of our knowledge or doubts on the basis of available information. In such cases we feel under no obligation to give credit just because a card has been submitted. Furthermore, we cannot accept the viewpoint that IOTA should be run on the basis that a credit once given cannot be withdrawn. This would make a nonsense of programme integrity and place too heavy a burden of responsibility on Checkpoints. Worse still, it would make for inconsistency of treatment leading to valid complaints of unfairness.

Decentralised checking offers great benefits. But it does require the establishment of procedures for monitoring data-input centrally.

First introduced a few years ago, data-cleansing is now an established feature of management control. The procedure adopted is to delete credits that are definitely wrong but also ones  that are strongly suspected of being incorrect. Many of these relate to unique credits, i.e. a credit which only one participant has on his / her record from an operation which IOTA Centre knows nothing about. Experience has shown that these are usually errors of some sort. Faced with the deletion of a credit, the participant should recheck his card and resubmit or replace it as appropriate. A card from a different, possibly more significant, operation may provide a solution. If we have made a mistake, we will be happy to correct it. However, please do not assume that such cases are always or mainly the Checkpoint’s fault.  Data-cleansing  is  an  IOTA  Centre  function,  its  purpose being to keep the database as free as possible of errors. If we are doing our job properly, errors will be identified on a regular basis and participants must accept this as a consequence of effective programme management.

In the past it has not always been possible to keep participants informed, but we will try to do so. Participants should understand the scale of the exercise facing the Committee and keep in perspective the likely small effect of this action on their scores. If participants ensure their database record includes a current e- mail address, the process will be simpler for everyone.

IOTA Centre’s maintenance of an effective procedure for check- ing data is one of the most important tasks now facing the Committee. Your cooperation and understanding of our reasons and method of doing this are appreciated.