ADIF concepts

In a normal ADIF file, it is not possible to say which QSOs have changed since the last ADIF file. This is problematic, say, when a QSL card arrives and a QSO needs adjusting. This activity would generally need a complete re-load of the log into Club Log to remove the old QSO and then add the corrected QSO.


To make this less troublesome, Club Log supports a specific ADIF field, QSLCALL which is used to indicate a change to an existing QSO.


Using QSLCALL to update QSOs

In your ADIF record you will have something like this:

<CALL:5>VP9NO<QSO_DATE:8>20070903<TIME_ON:6>213300<BAND:3>30M<MODE:2>CW<EOR>


Let's say that the callsign VP9NO needs to change to VP8NO. To do this, send an ADIF record with QSLCALL set to VP8NO, and all other fields identical:


<CALL:5>VP9NO<QSO_DATE:8>20070903<TIME_ON:6>213300<BAND:3>30M<MODE:2>CW<QSLCALL:5>VP8NO<EOR>


This will cause Club Log to update the callsign, replacing VP9NO with VP8NO. The details of the QSO much match exactly for this procedure to work.


Using QSLCALL to delete QSOs

If you wish to delete a call from the log, set the value of QSLCALL to your own call. For example, if your callsign is GH6UW, then to delete this QSO:


<CALL:5>VP9NO<QSO_DATE:8>20070903<TIME_ON:6>213300<BAND:3>30M<MODE:2>CW<EOR>


...you can send Club Log this ADIF record:


<CALL:5>VP9NO<QSO_DATE:8>20070903<TIME_ON:6>213300<BAND:3>30M<MODE:2>CW<QSLCALL:5>GH6UW<EOR>


Again, the details of the QSO must match exactly for the procedure to succeed.


If you are using the Club Log real-time API, you will receive a confirmation message in the return from Club Log. You can only use the QSLCALL field to correct entries in your own logs.


Note: This is a not a standard ADIF mechanism and was added because it made ADIF-only workflows a little more convenient for a large expedition that wanted it. An equivalent procedure of deleting, then adding a new QSO is absolutely fine and may be considered as a more standard approach.