DXLog.net - User contributions [en]

Menu Commands

2026-04-18T15:09:21Z

Sm7iun: /* Live score */

==QSY==

'''Next lower band'''

Shortcut: <code>[Alt][F1]</code>

Changes the band of the active radio to the band below, in terms of frequency. 
When pressing the key on the lowest band allowed for the active contest, the highest band will be selected. 
If the radio is on a band which is not allowed for the active contest, an allowed band will be selected when pressing the key.

'''Next higher band'''

Shortcut: <code>[Alt][F2]</code>

Changes the band of the active radio to the band above, in terms of frequency. 
When pressing the key on the highest band allowed for the active contest, the lowest band will be selected. 
If the radio is on a band which is not allowed for the active contest, an allowed band will be selected when pressing the key.

'''Jump to band using text command'''

Band and frequency changes can be made by typing the frequency in kHz or band in meters in the callsign entry field. 

* Typing 20 into the log callsign entry field and pressing <code>[Enter]</code> will change the active radio to the 20m band.
* Typing 14020.5 into the log callsign entry field and pressing <code>[Enter]</code> will change the active radio to 14020.5 kHz exactly.

==Change period==

For contests that are split into several time-defined periods, this option is used to manually switch between periods. 
Periods can be changed on active QSO and also on previously logged QSO.

Note: this option will only be shown if the current contest has configured periods. 

'''Period before'''

Shortcut: <code>[Ctrl][F10]</code>

This will change the period on the active or edited QSO to the previous period. 
* If the contest is split into four time defined periods and the period set in the QSO is #3, pressing <code>[Ctrl][F10]</code> will change this QSO to period #2.
* If time period is #1, this will change the time period number to last one. eg if 4 periods pressing <code>[Ctrl][F10]</code> will change this QSO to period #4.

'''Period after'''

Shortcut: <code>[Ctrl][F11]</code>

This will change the period on the active or edited QSO to the next period. 
* If the contest is split into four time defined periods and the period set in the QSO is #3, pressing <code>[Ctrl][F11]</code> will change this QSO to period #4.
* If the time period is #4, this will change the time period number to first one. eg if 4 periods pressing <code>[Ctrl][F11]</code> will change this QSO to period #1.

==Change mode==

'''Mode before'''

Shortcut: <code>[Ctrl][F1]</code>

Selects the previous mode in the list of allowed modes for the currently active contest.

'''Mode after'''

Shortcut: <code>[Ctrl][F2]</code>

Selects the next mode in the list of allowed modes for the currently active contest.

==Keyboard mode==

Shortcut: <code>[Alt][K]</code>

[[image:keyboard_mode.png]] 

Activates the CW/RTTY keyboard transmission window.

* Everything typed in the CW/RTTY keyboard window will be transmitted instantly as CW or RTTY depending on active mode.
* No real-time editing is available, i.e. the Backspace key does nothing.
* F-keys will send their messages but not perform actions such as logging.
* '''Important:''' There are limitations in the interpretation and transmission of certain macros.
* To stop transmission instantly, press <code>[Esc]</code>.
* To close the entry window, click Close, press <code>[Enter]</code>, or <code>[Alt][K]</code>

Use this option for a quick chat.

==CW speed==

Shortcut: <code>[Alt][V]</code>

[[image:cw_speed.png]]

This option allows the operator to quickly change the CW keying speed to a desired WPM speed.

'''Moved to the <code>Options|CW & Digital</code> submenu in release 2.5.46.'''

==Carrier==

Shortcut: <code>[Ctrl][T]</code>

[[image:tune.png]]

Keys the radio for tuning the radio and/or the power amplifier.

Requires the radio to be in CW mode and DXLog to have CW keying configured.

To stop, click the Stop button or press <code>[Enter]</code>, <code>[Esc]</code>, or <code>[Ctrl][T]</code>.

==Set pass frequency==

Shortcut: <code>[Ctrl][Alt][P]</code>

[[image:passfreqcurrent1.png]] 

[[image:passfreqcurrent2.png]] 

Set a pass frequency for the station for any band.

The entry box is pre-filled with the current frequency of the active radio. 
If set, the clickable box to its left will show the current pass frequency. 
This means setting the current band's pass frequency to the current frequency can by 
done very rapidly by just pressing <code>[Ctrl][Alt][P]</code> and <code>[Enter]</code>.

If the entered frequency is not on the currently used band, it will update the pass frequency for the other band. 

A station's active pass frequency is displayed in the Status window's ''Pass'' column.

It will also be shown as the leftmost clickable frequency button in the <code>[Alt][D]</code> panel when passing a station onto this band. 
Pass frequencies are remembered per band which means that once set, you do not have to re-set it at each band change.

0 or an empty entry will unset the pass frequency for the current band. This can e.g. be useful when switching from S&P to Run.

Pass frequencies are persistent but cleared when creating a new log.

[[image:passfreqstatus.png]] 

==Take a sked==

Shortcut: <code>[Alt][E]</code>

Files a sked for current or later use. Skeds are displayed and acted on from the Skeds window.

The Take a sked window has the same shortcut keys and mouse functionality as the [[Menu_Commands#Pass_a_station|Pass station window]].

You will also find more information in the [[Menu_Windows#Skeds|Skeds window section]].

[[image:takesked.png]]

[[image:skedpass.png]]

==Pass a station==

Shortcut: <code>[Alt][D]</code>

Feature for passing multipliers to other radio in SO2R or to another operator in a multi-operator setting.

In addition to the frequency of VFO A on up to two radios per station, DXLog also supports a 
''pass frequency'' (''QSY frequency'' in the panel) for each band and station. 
Please see the [[Menu_Commands#Set_pass_frequency|Set pass frequency section]] for more information about this.

In SO2R mode, opening the pass station dialog will automatically select the other radio's VFO A for passing.

[[image:passstation2.png|none|frame]]

Multiplier passing is typically used when running a frequency. 
The red text below the entry field will automatically make you aware of candidates for multiplier passing.

[[image:Multneeded.png]]

The ''Pass station'' panel is intended to be opened '''directly after''' having received the 
other station's exchange correctly. 
The ''Pass station'' procedure thereby replaces the "normal" conclusion of the QSO with 
<code>[+]</code> or <code>[Enter]</code> (if ESM is used). 

'''Basic operation'''
: After having received the other station's exchange correctly, press <code>[Alt][D]</code> to open the ''Pass station'' window.
: Select band and/or the networked station you want to pass the station onto.
: The ''Mode'' drop down menu offers the option to only show networked stations operating a certain mode.
: The frequency and band from the previous passing is automatically selected when opening the window.
: Pressing <code>[Alt][D]</code> will close the window but save the entered frequency, band, and comments entry box.
: Pressing <code>[Alt][S]</code> will save a Sked without sending any exchange. (E.g. useful in SSB.)
: Pressing <code>Escape</code> will close the window and not save any modifications done.
: On CW, pressing <code>[Alt][C]</code> will send the content of the comments text box.
: Click on one of the three radio frequency buttons to set the frequency for the pass, or manually enter a frequency.
: Add a comment if required. 
: When clicking a radio frequency button, the first message button is selected to allow transmission using <code>[Enter]</code>.
: Request a QSY by sending the first message using either <code>[F1]</code> or <code>[Enter]</code> (if the F1 button is highlighted).

:* '''Message 1''' asks for QSY. The other station agrees or declines.
:: If he declines, press <code>[Esc]</code> and log the QSO. If he agrees, send the next message.
:* '''Message 2''' sends frequency for QSY rounded to whole kHz. When confirmed, send the next message.
:* '''Message 3''' sends TU and logs.

: Pressing <code>[F3]</code> or clicking ''Save'' will alert the networked station receiving the pass by
: opening the ''Skeds'' window (if not already open) and add the details of the station being passed.
: Please note that clicking ''Save'' will only create a message and '''not''' log the QSO whereas <code>[F3]</code> will.

: The three QSY messages can be edited and saved. The macros <tt>$PASSBAND</tt> and <tt>$PASSFREQ</tt> are only
: available for the messages in this panel. Only message 3 accepts other macros, such as <tt>$MYCALL</tt>.
: Frequency correction for digital mode is not supported.

'''Using the QSY wizard'''
: A more streamlined method to pass a multiplier is to click the wanted band in the ''QSY wizard'' window.
: The ''QSY wizard'' highlights the other bands where the currently worked station is needed as a multiplier.
: With ''HamCAP'' installed, it also proposes the best time of day for a QSO. The suggested time is however only
: a recommendation and a direct QSY is always the default action when clicking the window.

: [[image:Qsywizard-needed.png]]

: When opening the ''Pass station'' window by clicking on a band in the ''QSY wizard'' (providing a station is available
: in the network, serving that band) the band is automatically selected and the frequency entry field is pre-populated
: with the available station's pass frequency or, if no such frequency is set, the frequency of the station's radio 1.

: The ''F1'' button is automatically focused allowing direct transmission of the first QSY message by pressing either <code>[Enter]</code> or <code>[F1]</code>.
: Sending this message moves focus to the ''F2'' button.
: If the station accepts the QSY proposal, pressing <code>[Enter]</code> (or <code>[F2]</code>, of course) will send the second QSY message.
: If the station declines the QSY proposal, pressing <code>[Esc]</code> and <code>[+]</code> (or <code>[Enter]</code> if ESM is enabled)
: will close the panel and conclude the QSO.
: Once the QSY is confirmed, pressing <code>[Enter]</code> a third time (or <code>[F3]</code>) will send the third QSY
: message (which typically includes <tt>$CR</tt> to log the QSO), alert the station receiving the pass, and close the window.

'''Skeds window'''

Passed stations and scheduled QSO are listed in the Skeds window. 
You will find more information in the [[Menu_Windows#Skeds|Skeds window section]].

[[image:skedpass.png]]

==Receive QTC==

Shortcut: <code>[Alt][L]</code> which will open and close the window.

'''Important:''' This function is only available if the current contest if configured for QTC exchange and 
the station is eligible to receive QTC.

[[image:receiveqtc.PNG|none|frame]]

Enter the received QTC data into this window using the following keys:

<code>[Tab]</code> moves the cursor between Time, Call and Serial fields and additionally to the QTC 
number field. <code>[Tab]</code> also moves to the next entry line when the serial entry is completed.

<code>[Space]</code> will move only within the Time, Call, and Serial fields on the current entry line.

Clicking the mouse pointer in a field will also move the cursor to this field.

When operating CW, pressing <code>[Enter]</code> will automatically transmit an "R" and move to the next column. 
However, you typically only use <code>[Enter]</code> after having received the time for a QTC line.

If the option <code>Options|CW/Digi|Copy hours in received QTCs</code> is checked, using <code>[Enter]</code> to complete 
a line will automatically pre-fill the two hour digits in the time entry box on the next line, with the cursor positioned for 
entering the two minute digits.

F-keys have different meaning in the QTC receive window and their function is listed in the right-hand side of the 
QTC receive window as clickable buttons. These keys allow handling of different situations during the reception of QTC.

Pressing <code>[+]</code>, <code>[Shift][+]</code>, or <code>[Keypad Plus]</code> will send a message to terminate 
the QTC exchange, save the QTC data and close the window.

<code>[Alt][S]</code> will save and close the window without sending anything.

A selection of operational function keys are available while the QTC receive window is open:

* <code>[Alt][F9/F10]</code> will adjust CW speed

* <code>[Alt][V]</code> will set the CW speed in WPM

* <code>[Alt][K]</code> allows keyboard CW transmission

* <code>[Esc]</code> will interrupt any ongoing transmission

* Audio control keys <code>[Ctrl][Alt][A/T/S/L]</code> works normally

'''Important:''' Redefined versions of the keys above are only available if the option <code>Options|CW/Digi|Remap keys in QTC receive</code> is checked.

'''Request repetition of individual QTC in CW'''

It is possible to ask for repetition of a specific QTC row by placing the cursor in the line and pressing 
<code>[Ctrl][F8]</code>, this will send the row number with the AGN message.

'''Editing QTCs'''

It is possible to edit already entered QTC's at a later time. Go to the QSO where the received QTCs were logged 
or enter the callsign in the log callsign entry field and press <code>[Alt][L]</code>. The QTC receive window will 
open with all the data as it was entered, make the relevant corrections and close the window with <code>[Alt][S]</code> 
or by clicking '''Save'''. Correcting QTC content will not change any other logged information for this callsign.

'''QTC receive window temporary memory'''

If the QTC receive window is closed, the state of the window is saved in a temporary buffer. 
Opening the window with the same callsign will restore the state. 
The temporary buffer is cleared when a new callsign is used and the QTC receive window is opened.

==Send QTC==

Shortcut: <code>[Ctrl][L]</code> which will also close the window.

'''Important:''' This function is only available if the current contest is configured to use QTC exchange and the 
station is eligible to send QTC.

After selecting the menu option or pressing the shortcut key, a first pop-up appears for determining 
the number of QTC to send:

[[image:qtcountselection.PNG|none|frame]]

You can select the desired number of QTC by clicking your selection or pressing <code>[Enter]</code> 
(for the maximum number of QTC) or the number keys <code>[1]</code> through <code>[9]</code> for any lesser number.

The next window lists the QTC for sending as well as related functions.

[[image:sendqtc.PNG|none|frame]]

The lines are color coded. A tan line has been sent. A yellow line is the line that will be sent when <code>[Enter]</code> or 
<code>[Insert]</code> is pressed. A green line is part of the remainder of the selected QTC set.

Pressing <code>[+]</code>, <code>[Shift][+]</code>, or <code>[Keypad Plus]</code> 
will terminate the QTC exchange, save the QTC data and close the window.

<code>[Alt][S]</code> will save and close the window.

Just as in the QTC receive window, a limited set of operational keys are available in the QTC send window:

* <code>[Alt][F9/F10]</code> increases and decreases the CW speed as normal

* <code>[Esc]</code> will interrupt any current transmission

* <code>[Alt][V]</code> will set the CW speed in WPM

* <code>[Alt][K]</code> allows keyboard CW transmission

==Turn Antenna to Logged Call (Short Path)==

Shortcut: <code>[Ctrl][F12]</code>

Will turn the antenna based on entered information if a rotator controller is connected to the network or PC and 
is correctly correctly set up in <code>Options|Rotator Configuration</code>.

: If the callsign field of the entry line contains a number, this will be used as the azimuth.
: Else, if the entry line contains an already calculated azimuth, this will be used.
: Else, if the entry line contains a callsign, its DXCC entity will be used to estimate the azimuth.
: Else, if the log is not empty, the azimuth of the most recent QSO will be used to estimate the direction.
: Else, if the log is not empty and the most recent QSO lack an azimuth, its DXCC entity will be used to estimate the azimuth.
: Else, the key does nothing.

Note that many contests support calculation of distance and azimuth by entering a six position grid in the callsign field and pressing enter.

==Turn Antenna to Logged Call (Long Path)==

Shortcut: <code>[Alt][F12]</code>

Equivalent to <code>[Ctrl][F12]</code> but turns the antenna in the opposite direction.

==Stop antenna==

Shortcut: <code>[Ctrl][Shift][F12]</code>

Stops antenna rotator.

==DX cluster==

Regardless if the connection is made directly by DXLog (using the commands below) or via the 
separate [[DXLog.net.DXC|DXLog.net.DXC]] cluster node client, it is subject to [[DXLog.net.DXC#Link_supervision|link supervision]]. 
The purpose of this is to secure continuous DX cluster access also with unreliable internet connections.

'''Connect default'''

This menu item connects to your favorite telnet DXCluster as set in the DXC connection list 
To set the "default" connection goto: <code>Options->DX Cluster->Edit connection list</code> 
This will display the list of available DX cluster nodes. Select a node from the list that you want to be the 
default (or add a new one) and press <code>Default</code> and <code>OK</code>

'''Connect other'''

You can select a different node from the "default" one by selecting one from the Connect Other list.

[[image:dxcluster_list.png]]

'''Disconnect'''

Send the Disconnect command the the connected cluster node. 
When DXLog.net.DXC is used, the command is sent to all nodes with "Cluster cmd" checked.

'''Talk'''

Shortcut: <code>[Alt][T]</code>

Sends a text command to the active cluster node. Enter text or use one of the predefined message buttons. 
Right-clicking a button opens a panel allow each to be configured.

[[image:talk.png|none|frame]]

==Spot==

Shortcut: <code>[Alt][F3]</code>

[[image:spot.png]]

This option is available when a DX cluster is connected or the network is enabled. 

After the menu item is selected (or shortcut keys are pressed), the spot window will open with the predefined text to be sent to the DX cluster as a spot.

The callsign is taken from log callsign entry field, if not blank or if it is blank from the last logged QSO.

==Self spot==

Shortcut: <code>[Ctrl][S]</code>

Text command: <tt>SPOTME</tt>

Creates a DX cluster spots of own station. Only available when a DX cluster is connected or the network is enabled.

Spots on the frequency of the focused radio in SO2R. Spots on the frequency of the main VFO in SO2V.

Always spots unlike automatic self spotting with <tt>$SPOTME</tt> or <code>Tools|Data entry|F1 message self spots when permitted</code> 
which are subject to a timer.

==CW/Digi messages==

'''Msg F1..F7, INS, PLUS, Ctrl-Alt-F1...F12'''

Shortcuts: <code>[F1]</code> through <code>[F7]</code>, <code>[Insert]</code>, <code>[+]</code> or <code>[Keypad +]</code>, and <code>[Ctrl][Alt][F1]</code> through <code>[Ctrl][Alt][F12]</code>.

These menu items (and their corresponding shortcut keys) will send the preset standard and alternative 
preset messages in CW and digital modes.

The initial content of all standard messages are part of the contest definition and are loaded on first use. 
A message can be edited using the shortcut: <code>[Shift][F#]</code>. If in SO2R Advanced, this also allows 
editing the scenario content for that key.

[[image:f1_edit.png]]

[[image:f1so2r_edit.png]]

For example, by pressing <code>[Shift][F1]</code> the content of memory F1 will be displayed and the 
operator can edit the message and save it for use. 

The contents of all the memories are saved together within the DXLog contest log file, so, when 
the contest file is re-opened, all memories will be active with last edited state. 

Additional messages are available from the extra message window that can be opened using shortcut <code>[Alt][C]</code> 
or menu <code>Options|CW/Digi|Modify additional messages</code>

[[image:other_messages2.png|none|frame]]

To send these messages you can open the window and click the button on the right according to the message you want to send. 
A special feature is that with this panel open, pressing an unshifted function key (<code>[F#]</code>) will send alternative 
message number # and then close the panel.

To make the alternative messages more accessible, other keys can be redefined to these shortcuts, e.g. <code>[F8]</code>, 
<code>[F9]</code>, etc. For more details, see the [[Menu_Tools#Redefine_keyboard_keys|redefining keyboard keys section]].

==Operator login==

Text commands: <tt>LOGIN</tt>/<tt>LOGOUT</tt> or <tt>OPON</tt>/<tt>OPOFF</tt>

Shortcut: <code>[Ctrl][O]</code>

[[image:op_login.png]] 

Logs in the callsign entered as the active operator. The active operator is saved with each logged QSO.

The text box offers a dropdown menu that includes all operators previously logged in and/or listed 
in the contest configuration panel which can be quickly navigated using the arrow keys.

Using the login function also allows the use of personalized voice keyer messages.

==Station type==

Text commands: <tt>RUN</tt>, <tt>MULT</tt>, <tt>RUN1</tt>, and <tt>RUN2</tt>.

Sets the type of operation for the station.

[[image:stationtype.png]]

In multi-operator scenarios it is important to assign the correct type to each station. 
The station type affects things like band change rules and in some cases also the Cabrillo log export.

The possible station types are:

* Run - Main/Run Station
* Mult - Multiplier station in Multi/1 entry
* Run 1 - Radio 1 in a Multi/2 entry
* Run 2 - Radio 2 in a Multi/2 entry
* Support - Support station, does not log

There is no text command for Support type. It can only be set from the menu.

==Remote commands==

Text command: <tt>REMOTE</tt>

Selecting this command will open the Remote command form:

[[image:remote_command_form.png]]

Select the stations to be sent a command and type the command in the box provided. 
If the command is to be applied to the commanding station, check the "Apply this command also locally" box.

The example in the illustration above is clearing the logs of all networked stations by sending the command 
<tt>CLEARLOGNOW</tt> to all stations and checking "Apply this command also locally".

==Set double QSO time difference==

Allows you to modify the required time between two QSO for it not to be a duplicate QSO. 
'''Important:''' This menu option is only available for contests having a dupe rule based on time difference.

==Live score==
This menu enables your contest score to be uploaded to the internet live score server server selected in real-time. 

First, select your band category:

[[File:live_score_select_category2.png]]

Next, select the upload service. When in doubt, "Score distributor" will post on all scoreboards and is always the safe choice.

'''Important:''' The "Real Time Contest" selection will post score on all scoreboards plus [https://hamscore.com/scoreboard hamscore.com] for supported contests. 
This is an secure and authenticated reporting and thus requires registering a free account at [https://contestonlinescore.com Contest Online Scoreboard].

[[image:Livescore_setup_post_address2.png]]

To post per band QSO and multiplier details as well as your total score, check the ''Post band and multiplier breakdown''. 
To post only your total score, uncheck this option.

To post the score via UDP, check ''Post score via UDP broadcast''. Note that there is a ''None'' option for not posting online.

Select your posting period. There is little reason to select anything but the shortest. For some reporting methods the period is fixed.

Clicking OK saves the settings.

The normal thing is to periodically post your score. To do this, check ''Auto-post'':

[[image:Live_score_auto_posting.png]]

This option is persistent so if you restart DXLog, posting will automatically continue. 
However, if a log is opened more than 24 hours after the last QSO in the log, auto posting is disabled automatically.

If you prefer to send the score manually any time you wish you can click on ''Post now!'' at any time. 
'''Important''': In the case of Real Time Contest, the ''Post now!'' option will clear and re-upload the entire log.

The format of the datagrams follows the specifications [https://contestonlinescore.com/blog/online-scoring-xml-specification/ here] and [https://contest.run/#/help/develop here].

==Antenna selection==

[[image:antselection.png]]

Note: To allow different RX/TX antenna, you need to enable this option in 
menu <code>Options|Interface specific options|Allow different TX/RX antenna.</code>

If this option is unchecked, receive and transmit antenna will be changed together.

'''Change RX'''

Shortcut: <code>[Alt][F11]</code>

This option allows you to change RX antenna whenever it is pressed. 
Currently selected RX antenna is visible in Radio/Ant status window.

'''Change TX'''

Shortcut: <code>[Shift][Alt][F11]</code>

This option allows you to change TX antenna whenever it is pressed. 
Currently selected TX antenna is visible in Radio/Ant status window. 

==Set read only password==

Sets or disables the password required to unlock read only mode. C.f. below.

==Read only mode==

Opens a password dialog popup and blocks all interaction with DXLog. 
If no password is set, pressing just <code>Enter</code> will unlock.

Use cases include temporarily leaving the radio during a contest with 
children or pets in the shack and WRTC referees.

Menu Options

2026-04-14T16:06:00Z

Sm7iun: /* Log */

==Load contest at startup==

* '''Enabled'''

: If checked last opened log will be opened automatically when DXLog is started. 

* '''Disabled'''

: If checked, DXLog is started but no log is opened. 

==Automatic backup==

When clicked, this will open the log automatic backup settings window. Here parameters for log automatic backup can be set according to the user's preference. 

[[image:auto_backup.png]]

==Language==

Chooses the user interface language.

==Keyboard selector==

This option allows the assignment of a different keyboard to each entry line which is 
highly recommended for advanced SO2R but also useful for advanced users in SO2V.

'''Important:''' Dual keyboard in SO2V only works for dual receiver radios and 
<code>Options|Interface specific options|Dual receiver radio (Use split in SO2V)</code> checked.

To use this feature you (obviously) must have more than one keyboard connected to the PC.

Select <code>Options|Keyboard selector</code>. A window opens showing the current keyboard assignment.

[[image:Keyboard_select_default.png]]

Now click on Define. A popup will appear asking you to identify the Radio 1 keyboard.

This keyboard will be assigned to the Radio 1 (upper) log entry line. Press any key on keyboard 1. 
Now press any key on the keyboard to be assigned to the Radio 2 (lower) entry line. If successful, 
the panel will show some cryptic identifiers for the keyboards.

If you really do have separate keyboards ensure that the identifiers are different. 
It is possible to use one keyboard and assign it to both positions, which will show as the same 
identifier for both Radio 1 and Radio 2. The panel should look something like this: 

[[image:Keyboard_select_success.png]]

Now click OK to save your assignments and close the window.

If you find that something doesn't work or need to reset to the default Any Keyboard configuration, open 
the Keyboard selector panel and select the Reset button. Click OK and any previous keyboard assignments will be removed.

==CW & Digital==

===Modify standard messages===
Text command: <code>MESSAGES</code> or <code>MSGS</code>

This option is used to edit the contents of all standard F-key, INS and PLUS messages 
for RUN and Search & Pounce mode.

[[image:standard_messages_cw2.png|none|frame]]

Any edited content is saved for the currently selected contest and '''will be used for any new log for the same contest'''.

The Defaults button will reset all messages back to their default values. This can be particularly convenient 
when switching "role" from a previous contest, such as member/non-nember, IOTA station/non-IOTA station, etc.

The Save and Load buttons allows saving and retrieving all messages to and from a text file.

If you want to reset '''all messages for all contests''' to their default values, click <code>File|Open configuration directory</code>. 
Close DXLog. Delete the file called <tt>DefMsgs.sdb</tt> and start DXLog again.

[[image:standard_messages_options2.png|none|frame]]

The Options tab allows the setting of additional message options:

''$QSOB4 macro''
: This text will be sent if $QSOB4 macro is triggered due to a duplicate QSO.
: '''Important: The use of QSOB4 mechanics in contests is a heritage from paper log days and not a recommended practice.'''

''Use only Run messages''
: DXLog will use only RUN messages, even if you switch mode to Search & Pounce.

''Use sprint exchange logic for the Insert key''
: This setting is available only for contests configured to allow sprint exchange logic and supports
: an old style of operating a sprint contest, keeping DXLog in Run mode constantly.:
: With this option checked, and in Run mode, the Insert key will send the '''RUN''' Insert message if the callsign
: field and the exchange field are empty. If they are not, the '''S&P''' Insert message will be sent.
: Note that you may need to modify the standard messages to suit your operating preferences when using this option.
: For a more modern way of operating a sprint contest, see [[]].

===Modify additional messages===

Shortcut key: <code>[Alt][C]</code>

Text command: <code>AMESSAGES</code> or <code>AMSGS</code>

Define or edit additional CW/Digital mode messages which can be invoked in a macro using commands 
<code>$MSG1..12</code> or by pushing keys <code>[Ctrl][Alt][F1..12]</code>

[[image:Othercwdigi3.PNG]

While the window is open, pressing <code>[F1]</code> through <code>[F12]</code> will send message 1 through 12 and then close window.

The Save and Load buttons allows saving and retrieving all messages to and from a text file.

Content of additional messages are saved in the DXLog config file and is thus '''common for all contests'''.

===CW keying===
'''Computer sidetone''' 
Text command: <code>SOUND</code> and <code>NOSOUND</code>

Unchecked by default. When checked, a CW side tone will be produced in the PC's default audio device. 
Only available for COM-port keying. If a smart keyer (e.g., WinKey) is used, the sidetone function is disabled.

'''Individual radio speed''' 
Text command: <code>SYNCCW</CODE> and <code>NOSYNCCW</code>

If checked, allows the CW speed to be independently set on Radio 1 and Radio 2.

The text command <code>SYNCSPEED</CODE> equalizes the speed of both radios (in SO2R) or VFO in (SO2V).

'''Reduced word spacing''' 
Text command: <code>CTSPACE</code> and <code>NOCTSPACE</code>

When checked, word spacing in CW will be 6 dits rather than the normal 7 dits.

'''Set speed''' Allows you to enter the exact CW keying speed of the focused radio in WPM. Shortcut key: <code>[Alt][V]</code>

'''Decrease speed''' Decreases the CW keying speed of the focused radio with 2WPM. Shortcut key: <code>[Alt][F9]</code>

'''Decrease other radio's speed''' Decreases the CW keying speed of the unfocused radio with 2WPM. Shortcut key: <code>[Shift][Alt][F9]</code>

'''Increase speed''' Increases the CW keying speed of the focused radio with 2WPM. Shortcut key: <code>[Alt][F10]</code>

'''Increase other radio's speed''' Increases the CW keying speed of the unfocused radio with 2WPM. Shortcut key: <code>[Shift][Alt][F10]</code>

===CW macro number sending===

Controls how numbers are sent on CW.

Number sending abbreviations applies to message macros <tt>$CQZONE</tt>, <tt>$ITUZONE</tt>, <tt>$EXCHANGE</tt>, <tt>$RST</tt>, <tt>$SERIAL</tt>, 
<tt>$NEXTSERIAL</tt>, <tt>$PREVSERIAL</tt>, <tt>$POWER</tt>, <tt>$PREV_RCVD</tt>, and <tt>$PREV_RECINFO</tt> and QTC macros <tt>$TIME</tt>, <tt>$NR</tt>, and <tt>$QTC</tt>.

The abbreviations are not applied to macros sending a frequency, time, or grid, such as <tt>$FREQR1</tt>, <tt>$TIME</tt>, or <tt>$GRID</tt>.

<tt>$RST</tt> is a special case with the minimum abbreviation being 5NN.

The available options are:

'''Use 'O' as abbreviated zero''' When checked, all number '''0''' are replaced with the letter '''O'''. '''Important:''' This is an outdated practice and only a source of confusion in contests.

'''Unabbreviated [01590]''' When checked, all numbers are sent without any abbreviation. ($RST sends 5NN.) Text command: <code>NOABBREV</code>

'''Lead abbreviated [T1590]''' When checked, all leading zeroes are sent as the letter '''T'''. Text command: <code>SEMIABBREV</code>

'''Abbreviated [T159NT]''' When checked, all numbers '''0''' and '''9''' are replaced with the letters '''T''' and '''N'''. Text command: <code>FULLABBREV</code>

'''Pro abbreviated [TAENT]''' When checked, all numbers '''0, 1, 5''' and '''9''' are replaced with letters '''T, A, E''' and '''N''' Text command: <code>PROABBREV</code>

'''Custom abbreviation''' When checked the Custom Abbreviation table will be used to substitute characters

'''Set custom abbreviations''' Enables editing of substitutions character by character When clicked, a panel will open to allow assignment of character substitutions.

[[image:custom cw digi abbreviation table form.png]]

* <code>Add</code> Adds a new substitution. First enter the character to be replaced. Then enter the character to be used in its place. 
* <code>Delete</code> Removes the currently selected substitution. 
* <code>OK</code> Saves changes and closes the form 
* <code>Cancel</code> Discards changes and closes the form

Characters/digits not included in the substitution table are sent in their original form.

===Send leading zeros in serial numbers===

Text command: <code>LZ</code> and <code>NOLZ</code>

When checked, macros sending numbers will always send three digits. 

Shorter or longer zero padding can be achieved by adding number within parenthesis 
to the serial number macro e.g., $SERIAL(2).

===Send frequencies rounded to kHz===
If checked, the frequency sent by the $FREQS, $FREQP, and $FREQnn macros will be rounded to the nearest kHz. 
If not checked, the frequency is rounded to the nearest 100 Hz. An 'R' is sent as decimal separator.

===Disable worked-before macros===

Text command: <code>WORKDUPE</code> or <code>WORKDUPEON</code> and <code>NOWORKDUPE</code> or <code>WORKDUPEOFF</code> 

When checked, the <code>$QSOB4</code> and <code>$QSOB4WIPE</code> macros will do nothing, regardless 
if the current callsign is a dupe or not.

Checked by default. It is a bad and outdated practice to not work dupes in a contest.

===Remap keys in keyboard mode===

When checked, keyboard remapping will be active also when sending CW/RTTY text in keyboard mode.

===Remap keys in QTC receive===

When checked, keyboard remapping will be active also in the QTC receive window. 
This option is only available if the contest entry involves receiving QTC.

===Auto sending===

Text command: <code>CWAUTO</code> or <code>AUTOCW</code> and <code>NOCWAUTO</code> or <code>NOAUTOCW</code>

[[image:autocw.png|none|frame]]

When enabled and the mode is CW and you are in Run, DXLog will start sending the Insert message after having 
typed a selected number of characters of the callsign, removing the need to press <code>[Insert]</code> to respond to a call.

The rule for start of transmission of the RUN INSERT message is:

Typed characters contain both a letter and a number AND has reached the threshold number OR typed characters include a slash and 
the number of characters following the slash has reached the threshold number

This means that with the threshold set to 2 transmission will start when pressing

: 7 in SM7IUN
: 2 in SM/E21EIC
: the first 7 in E77DX

and with the threshold set to 3, transmission will start when pressing

: 7 in SM7IUN
: 1 in SM/E21EIC
: the second 7 in E77DX

'''Important:''' When using a number server, a serial number reservation will automatically occur at the start of the RUN INSERT message.

Tip: When you open the dialog to configure auto sending, <code>[Space]</code> will enable/disable and 
<code>[Enter]</code> will press the OK button and close the window.

===Smart correction for $CORRECT===

When checked, DXLog will send only the part of the callsign that was corrected. 
Example: if you correct W6ABB to W6ABC, only ABC will be sent by the <code>$CORRECT</code> macro.

===Copy hour in received QTCs===

When checked, the two hour digits from the previous line will be automatically 
copied to a new line in the receive QTC window.

===QTC window font size===

Sets the font size of the QTC window used in contests with QTC such as Worked All Europe Contest.

==Configure interfaces==

Text command: <code>SETUP</code>

[[File:Portconfig.png|none|frame]]

DXLog currently supports interfaces for up to 8 COM ports and one LPT port. 
To use any of the ports to connect to the hardware and perform a function, 
you must enable the port by checking "Enabled" box.

===Serial ports===

DXLog can communicate with up to eight devices; peripherals or radios. 

For each device, you can select to use a COM port or a "pipe". 
COM ports can be in the range of COM1 to COM40.

There are two types of "pipe" connections; OTRSP and WINKEY. 
These are direct connections and do not rely on a COM port for communication. 
You can only have one of each of these.

You can not select the same COM port for more than one interface. 

Apart from communications interface (COM or pipe) the device type needs to be selected (Winkey, Radio, etc.). 
Additional settings for the device are available by clicking on the setup button on the far right.

'''The "-" port type'''

The "-" device type is a COM port where only the hardware handshake signals are used, 
such as keying or PTT.

It uses a fixed speed of 9600bps, which may cause problems in some cases, such as when 
using a port combiner.

'''Important:''' If you are using a COM-port footswitch together with an external DVK, such as that 
built into microHAM devices, you may need to select the Escape option to reliably stop DVK 
playback when pressing the footswitch.

To make sure a port used for only keying or control is opened at the right speed do the following:

Open the interface configuration panel.

* Select the wanted port and check the enable box.
* Select it as Radio 1 and click Setup.
* Select a random radio model and set the correct speed.
* Set the wanted keying (e.g. CW = DTR, PTT = RTS, Footswitch, Active with Radio 1, etc.)
* Click ''OK''
* Change from "Radio 1" to "-". Do not click Setup.
* Click ''OK''

'''The Winkey port type'''

The default setting is 1200-8-N1 with RTS always on to support the original, serial port Winkey. 
If you have a more modern keyer, you may chose a higher speed. 
'''Important:''' A Winkey always keys both radios and disables COM-port and LPT-port keying.

'''The microHAM port type'''

This device type will support any microHAM keyer with a COM port control interface. 
Serial speed and handshaking signals are ignored when connecting to a microHAM USB 
device router virtual COM port. For more information, refer to the [[Radios_and_Peripherals#microHAM|Microham section]].

'''The OTRSP port type'''

Software PTT (commands X1/X0) is available only with "pipe" connection, otherwise disabled.

Options include to not assert PTT when using DVK and to verify transmitter change before transmissions starts.

The reason for the option to verify transmitter change before transmission starts is to avoid a possible race 
condition that can occur when using a Winkey keyer and an OTRSP device. There is a risk that the keyer receives 
its command first and starts keying risking that the OTRSP device changes transmitter while transmitting. 
Checking the option will make DXLog send an OTRSP query to make sure the transmitter change has occured before keying starts. 
Since such a response is optional in the OTRSP specification, this function must also be optional.

'''The Radio port type'''

See below.

===Digital Voice Keyer===

The Digital Voice Keyer (DVK) section allows PC audio cards or adapters to be used to record and 
play back SSB DVK messages.

For selected radios, it is also possible to use the voice keyer built into the radio. 
The radio's built-in voice keyer is enabled in the [[Menu_Options#Radio_configuration|radio settings]]. 
With a few exceptions, recording is not supported. See the [[Radios|supported radios]] section for more information. 

If you have a microHAM keyer controller, its built-in voice keyer may also be used. 
The microHAM voice keyer is enabled in the [[Menu_Options#microHAM_device_configuration|microHAM settings]]. 

'''Important:''' DXLog's own DVK has priority and must therefore be disabled to allow use of other DVK. 
It is thus important to not enable more than one of these three voice keyer options.

'''Important:''' If you are using DXLog's own DVK with split (transmitting on another frequency) you may 
need to disable radio polling during transmit for stable operation.

To use DXLog's voice keyer:
* Check the enable DVK box in the interface configuration panel.
* Select the relevant DVK playback devices (audio from these must be physically connected the the radio's audio input).
* Select the relevant DVK record device (Usually a microphone connected to the PC's microphone or line input).
* Select muting as required.

In SO2R the audio playback will be channeled to the currently focused radio's playback device. 
If you are using a SO2R controller with internal audio switching, select the controller's audio device 
for both radios. In SO1R and SO2V, audio is always routed to radio 1's device.

The built-in DVK in DXLog will support up to nine different messages: 1, 2, 3, 4, 5, 6, 7, INS, and PLUS. 
'''Important:''' Your external voice keyer may support fewer. 

Recording the messages is done by pressing <code>[Shift]</code> and the wanted function key and ended with <code>[Esc]</code>. 
With no operator [[Menu_Commands#Operator_login|logged in]], the recordings are stored in WAV format in the directory <tt>%appdata%\DXLog.net\Ops</tt>. 
The filenames are <tt>F1.WAV</tt> through <tt>F7.WAV</tt>, <tt>INS.WAV</tt> and <tt>PLUS.WAV</tt>. 
If an operator is logged in, the recordings are located in a subdirectory with the operator's callsign, such as <tt>%appdata%\DXLog.net\Ops\SM7IUN</tt>

Although not recommended, the voice keyer can be used with ESM if DXLog's message convention is used. 
It is described in the [[Getting_started#Voice_memory_playback|getting started]] section.

'''SO1R, SO2R, and SO2V'''

Messages #1 through #7 are played back by pressing function keys <code>[F1]</code> through <code>[F7]</code>. 
Unlike in CW and digital, the same voice message is played back regardless of operating mode, Run or S&P. 
Any macros in messages #1 through #7 are thus ignored in SSB.

The INS and PLUS voice messages are not associated with any keys and can only be played back by a macro. 
<tt>$PBINS</tt> plays back message INS (#8 on external devices) and <tt>$PBPLUS</tt> plays back message PLUS (#9 on external devices).

The keys <code>[Insert]</code> and <code>[+]</code>/<code>[Keypad +]</code> ''work differently'' and do not directly play back a 
voice message when pressed but instead execute the macros in the associated standard message, based on key and operating mode.

This means that in the example below, pressing <code>[Insert]</code> in SSB S&P will play back voice message #2 and then log the QSO.

In SSB mode, all macros sending CW or Digital characters are ignored. In CW, the <tt>$PBINS</tt> and <tt>$PBPLUS</tt> macros are ignored. 
This means that you can create standard messages for the <code>[Insert]</code> and <code>[+]</code>/<code>[Keypad +]</code> keys that works both 
in CW and SSB without the use of conditionals.

An example of this type of multi-mode messages for Worked All Germany in the Mixed class is shown below.

[[image:Dvkmixedcontest.png|none|frame]]

'''Advanced SO2R'''

In Advanced SO2R, the function keys <code>[F1]</code> through <code>[F7]</code> are not directly associated with a 
voice memory but instead executes the active scenario's ''macro string'' associated with the key. 
More information on creating and using SO2R scenarios can be found in the [[Menu_Operating#Edit_SO2R_Scenarios|SO2R Scenarios]] section.

The message/playback macros <tt>$F1</tt> through <tt>$F7</tt> are mode sensitive. The <tt>$PGBINS</tt> and <tt>$PBPLUS</tt> are not. 
In SSB e.g. <tt>$F1</tt> plays back voice memory #1, in CW and Digital it sends the F1 ''standard message'' so 
there is no problem using Advanced SO2R also in a mixed mode contest.

===Radio polling===

The two ''Polling period'' text boxes determine how often DXLog requests information 
from the radio over the CAT interface.

DXLog sends three poll requests per period, i.e. with a setting of 300ms, one poll request is sent every 100ms.

For ICOM, which has a duplex CAT interface, you may experience slow or even missing response 
from the radio if the polling period is set too short since DXLog's polling will consume the entire 
capacity of the CI-V interface. With ICOM you also have a no-polling option called "Transceive" mode. 
You can find more about this feature [[Radios_and_Peripherals#ICOM|HERE]].

A list of recommended polling periods can be found below. Depending on radio model, a shorter interval 
may work and give a better user experience.

{| class="wikitable"
! CAT data rate [bps] !! Poll interval [ms]
|-
| 1200 || 1000
|-
| 2400 || 1000
|-
| 4800 || 800
|-
| 9600 || 600
|-
| 19200 || 400
|-
| 38400 || 200
|-
| 115200 || 100
|}

===PTT===

* PTT lead delay determines the time between PTT activation and start of transmission.
:This value is used both for COM-port keying and Winkey. However, microHAM keyers ignores
:this setting and requires you to set the PTT lead time in the microHAM device router.
* PTT tail delay determines the time between end of transmission and PTT deactivation
* PTT seq delay determines the time between activation of the four available PTT signals: PTT, PTT1, PTT2, and PTT3.

===Keying===

The keying settings are for all keying methods; COM-port, Printer port, or Winkey.

* Max speed sets the maximum speed in WPM.
* Min speed sets the minimum speed in WPM.
* Weight sets the weight of the keying. 50% is standard 3:1 keying. A higher number represents a heavier keying.
* Keying compensation adds to the durations of dits and dahs. Accepts both negative and positive values. Negative values have no effect on Winkey keying.
* Reduced keying stutter selects a keyer with improved immunity to disturbance from other applications running on the PC.

===Printer port configuration===

'''Important:''' Use of the printer port requires installation of a special driver, see the [[Installation#Prerequisites|Installation section]].

To use the parallel printer port (i.e. LPT port), it must be enabled by checking the "Enabled" 
box in the interface configuration panel's Printer port section.

Clicking the Setup opens its configuration panel.

Antenna selection with up to 16 different antennas is supported.

For multi-band antennas, the covered bands should be entered as a comma-separated list as in 
the example below. The operator friendly antenna name in the ''Description'' column is used in the 
''Antenna selector'' window.

'''Important:''' DXLog's band naming convention is to use wavelength up to the 10m band and 
above that, frequency. Band names are thus 160, 80, ..., 12, 10, 50, 144, ...

For more information on antenna selection, see the [[Menu_Windows#Antenna_selector_R1.2FR2|Antenna selector]] section.

The DVK related checkboxes are not implemented.

[[File:Dxl_printer_port_config.png]]

===Radio Setup===

If a COM port is configured as a radio interface, click on 'Setup' to open the Radio Setup form. 
In addition to the generic settings, several radio specific options are available. 

'''Important:''' Radio brand and model specific information can be found in the 
[[Radios_and_Peripherals|Radios and Peripherals]] section.

[[image:Radio_setup_form3.png]]

Radio configuration

* Radio
: Select your radio model. If it is not in the list, feel free to contact the development team.
: Note that many times a similar radio model can be successfully used.
: E.g. many Chinese QRP radios use the Kenwood protocol.

* Speed
: For best performance, use the highest available speed on your radio's CAT interface.
: If there is an "Auto" speed setting, do not use it. It is strongly advised to use a virtual USB CAT port, if available.
: Note that on modern ICOM radios it is necessary to "Unlink" the two CAT interfaces to achieve maximum speed.

* Bits, Parity, Stop
: Set according to the recommendations in your radio's documentation.

* ICOM CI-V address (hex)
: This is by default set to the selected ICOM radio model's factory setting.
: If you change the address in your radio's settings, this has to be set to the same value.

* Use radio's internal voice keyer
: Enables the use of the built-in digital voice keyer on supported radio models (E.g. Elecraft, later ICOM, some Yaesu).
: '''Important:''' If the Enable DVK option is checked in the Port Configuration panel,
: this setting has priority and the radio's DVK will not be used.
: '''Important:''' Due to limitations in the CAT command repertoire for some radios, DXLog may
: not be able to track the radio's transmit/receive state. You can use the
: <code>Options|Log|Show border on TX</code> menu option to determine if this is the case.
: If DXLog can not determine the radio's transmit state, this means 1) software interlock in a
: multi-radio setting will not work reliably with the radio's DVK, and 2) CQ autorepeat will not work.
: '''Important:''' Make sure the option Do not use PTT with voice keyer is checked for
: any device controlling the radio's PTT. If it is not, DXLog will assert the PTT at the start
: of DVK playback and then wait for it to be released, which obviously will never happen.

* Use reverse sideband on CW
: Uses the opposite sideband on CW. Mode is only enforced by DXLog at mode or band changes.

* Use CAT PTT command on Phone and Digital
: Uses a CAT command to switch between receive and transmit when using DXLog's internal voice
: keyer or digital modulator, instead of a COM-port or LPT signal. Only use this as a last
: resort when COM-port PTT is not available.
: Since the time to convey the command to the radio is not insignificant, you may need to increase
: the PTT lead time significantly to avoid hot-switching or lost first syllables.

* Use CAT PTT command on CW
: Uses a CAT command to switch between receive and transmit on CW, instead of a COM-port or LPT signal.
: Only use this option as a last resort when COM-port PTT is not available.
: Since the time to convey the command to the radio is not insignificant, you may need to increase
: the PTT lead time significantly to avoid hot-switching or lost leading dits.

* Use ICOM CI-V "Transceive" mode (reduced polling)
: An ICOM specific feature for which "CI-V Transceive" must be enabled on radio.
: For older ICOM radios with 19200bps or slower CI-V interfaces this option offers a much improved user experience.
: For modern ICOM radios the recommendation is to have this feature ''disabled'', an interface rate of 115200bps,
: "CI-V Transceive" enabled in the radio's set up menu, and polling rate of 100ms. USB Echo Back should be off.

* Control FlexRadio DAX on Phone
: Intended for remote operation with e.g. Maestro. Will temporarily enable DAX during voice keyer playback.

* Reinitialize port after switching from TX to RX
: Upon return to receive, reinitialize the COM port attached to that radio.
: '''Important:''' This is an emergency function and should only be used as a last
: resort when e.g., experiencing bad RF feedback at a DXpedition or a field day
: without access to ferrites.

* Do not poll radio during TX
: Stop polling radio (stop updating frequency, etc.) during transmit.
: May reduce RFI from the CAT interface.
: For e.g. Elecraft this is a recommended option.
: '''Important:''' For natural reasons, polling will only stop during transmit if DXLog is the origin of the PTT signal. The only exceptions are when using a [[microHAM_device_configuration|microHAM]] keyer with TX lock/unlock enabled or a Winkeyer with Detect paddle for interlock enabled.

The two above options may be useful in cases with RF feedback causing unwanted effects. 
They should however be considered as temporary solutions. RF feedback should be addressed at 
the source through proper grounding and ferrite chokes on cables.

* Use radio DATA mode for voice keyer playback
: Switches the radio to data mode during voice keyer playback.
: Intended for for radios that can only use an external modulation input in data modes.
: '''Important:''' Not supported on all radios.

* Always use radio DATA mode for any DIGI mode
: If your radio has a DATA mode for RTTY/PSK/AFSK, checking this option will force the DATA
: mode whenever a DIGI mode is selected.
: '''Important:''' Not supported on all radios.

* Use transverter offsets
: Opens up a configuration panel allowing setting per-band transverter offsets in kHz.

:[[image:Transverteroffsets.png|none|frame]]

* Spectrum

: Allows you to select a supported transceiver model or an external SDR for spectrum display.
: Currently Elecraft K4, SDRPlay, AirSpy and ExtIO type SDR receivers are supported.
: Clicking the ''Setup'' button will allow configuring it for RF or IF reception, etc.

Keying & Control

On many radios the CAT interface's unused hardware handshake signals can be used for keying and control.

In the drop-down menus you can chose to use between them being permanently on or off, CW keying or one 
of four possible PTT signals. The other options (Active radio etc.) are intended for controlling 
external radio controllers or keyers.

'''Important:''' Most Yaesu models have RTS hardware handshaking enabled from factory. Either set RTS 
to "Always on" or disable this function in the radio's settings (better).

'''Important:''' All CW keying via COM-port is disabled if a Winkey is active. PTT is however still active and 
should be disabled with Winkey 2.3 (or later) that has a high performance PTT built in.

The ''DSR/Footswitch'' input (pin 6 in an RS-232C connector) is an input with multiple, alternative uses. 
''PTT'' means that the pin will assert DXLog's PTT. ''R1/R2 toggle'' means that a press on the footswitch will 
switch focus to the other radio. ''R1 on/R2 off'' means that pressing the footswitch will focus radio 1. 
''R1 off/R2 on'' means that pressing the footswitch will focus radio 2. ''TX Rec'' means record to the preselected 
voice keyer memory. ''Escape'' makes pressing the footswitch equivalent to pressing the Escape key. 
The function of ''RX Wait'' is unclear.

* Do not use PTT with voice keyer

: '''Important:''' If you use the radio's built in voice keyer, make sure to check this box
: on the COM port controlling your radio's PTT to avoid a self-locking PTT loop and to make
: sure the transmitter's audio source is not forced to be the microphone.

: If PTT is not asserted when playing back, you may need to uncheck it but this is extremely rare.

==Configure antenna server==

This configuration is for a special antenna hardware used at a few, select contest stations.

[[image:antserv.png|none|frame]]

==Interface specific options==
===Allow different TX/RX antenna===

If checked this option allows different selection for TX and RX antenna with Operating->Antenna selection menu. 

===Use decoder frequency correction===

If checked and audio decoder is used in a digital mode contest, audio frequency in decoder will be 
added or subtracted to the frequency reported by the radio to get effective operating frequency. 
When using a digital mode for which the radio displays the effective operating frequency, such 
as FSK RTTY or FT8, this option should be disabled.

For digital modes when this is not the case, e.g., AFSK RTTY, this option should be enabled.

===Block message transmission if another radio is on the same band===

If checked the Transmitter connected to this DXLog will have it's TX disabled if another radio on the network is on the same band.

===Dual receiver radio (Use split in SO2V)===

If checked (and the technique selected is SO2V) DXLog will send set the radio in split mode when focusing VFO B.

Select this if you are using a radio with a subreceiver, such as Yaesu FTDX101D, ICOM IC-7610, or IC-7851.

===Use different bandmap background for active radio ===

If checked, the background color of radio 1 or radio 2 bandmap will be changed when the radio becomes active. 
'''Important:''' the color used in this mode needs to be selected by using the Colors menu in the bandmap right click menu. 
By default it is set to the same color as the normal background.

=== Automatically open/close digital window on mode change ===

If checked, the digital window for the active radio will be opened when a digital mode is selected. 
If a non-digital mode is selected and the digital window is open, it will be closed. Note that the 
contest configuration must allow both digital and non-digital modes in the same time period (mixed mode). 
The digital window must be configured properly in the RTTY configuration form.

=== Sync radio 1/2 frequency & mode ===

If checked, synchronizes the frequency and mode of physical radio 1 and 2. Does not synchronize VFO in SO2V. 
This option requires radio auto reporting (e.g., ICOM "Transceive") to be disabled or oscillation will occur.

===Band change keys affect both VFO===

With this option checked, <code>[Alt][F1]</code> and <code>[Alt][F2]</code> will change the band of both VFO.

===Select first available antenna on band change ===

If checked, selects the first available antenna on band change.

===Partner and S&P selection===

Controls the function of the [[Menu_Windows#Partner|Partner window]] and [[Menu_Windows#Search_and_Pounce|S&P window]].

==RTTY configuration==

Settings for RTTY decoder types and paths to decoders.

[[File:FrmRTTYConfig.png| 600px]]

Up to three decoders can be used per radio. Note that the decoder for each radio '''must be in a separate user-writable directory''' on your PC.

* '''MMVARI Multimode''' - For MMVARI select MMVARI from the radio buttons 

* '''MMTTY RTTY engine''' - For MMTTY go to http://hamsoft.ca/pages/mmtty.php - download MMTTY engine and extract into a user-writable directory 

* '''2Tone RTTY engine''' - For 2TONE go to http://www.rttycontesting.com/downloads/2tone/ - download the latest 2tone version and extract into a user-writable directory 

* '''GRITTY RTTY decoder''' - For GRITTY go to http://dxatlas.com/Gritty/Files/Gritty.zip and extract into a user-writable directory. GRITTY is run separately from DXLog. Edit its .ini file to set TCP port, RTTY tones, etc. 

* '''EXTFSK, EXTFSK64, TinyFSK''' - For these FSK plugins, go to https://www.qsl.net/j/ja7ude/extfsk/indexe.html and https://www.qsl.net/ja7ude/tinyfsk/index.html. To use any of them with MMTTY, place the .fsk file in the MMTTY directory/ies. To use them with MMVARI, place them in a user-writable directory.

Set the radio buttons for the correct RTTY decoder engine. 
Set the paths to the relevant RTTY decoder engines and MMVARI FSK plugins. 
Set tick box options as appropriate for your operation.

==microHAM device configuration==

Settings for integration with microHAM keyers and SO2R controllers 

You can find more general tips about using microHAM products with DXLog 
in the [[Radios_and_Peripherals#microHAM|Radios and Peripherals section]].

[[image:Mk2r-new9.png|none|frame]]

* '''Enable microHAM device DVK
: Enables the use of the microHAM devices's DVK instead of DXLog's built in DVK.
: Supported for microHAM DKII, MKII, MKIII, MK2R, MK2R+, and u2R.
: '''Important:''' DXLog's own DVK has priority and must thus not be enabled.

* '''Footswitch is PTT
: Enables the use of the microHAM devices's footswitch input for PTT.
: On devices with more than one footswitch/PTT input, DXLog regards them as one.
: No longer optional as of DXLog version 2.4.17 due to removal of this option in microHAM's firmware.

* '''Enable TX lock/unlock
: Enables control of the hardware transmit locking/unlocking built into the device.
: Checking this will enable the software interlock in DXLog to act on all possible means
: of transmission: Message transmission, PTT, Footswitch, and paddle.
: This function is intended for ''multi-station interlock'' but can have other uses since with
: this option checked, keyer PTT, Winkey BKIN, and footswitch status are recognized
: by DXLog and is available e.g. for scripting or transmit/receive antenna selection.
: When using a footswitch with this function it should be connected to the microHAM device.
: Using a COM-port footswitch may cause race conditions since DXLog will be exposed
: to two separate PTT signals with a unpredictable separation in time.
: '''Important''': Winkey BKIN is only recognized with microHAM Device Router 9.3.0 or later.

* '''Enable SW PTT
: Enables the use of software PTT. With this enabled, DXLog will control the devices's
: software PTT via the control interface. Can replace COM-port PTT but comes with
: latency so e.g. PTT lead time may need to be increased.
: Should only be used as last resort when hardware PTT is not possible.

* '''Dual radio device
: Selects single or dual radio microHAM device.
: Should be checked for dual radio devices such as microHAM MK2R, MK2R+, and u2R.
: Should be unchecked for single radio devices, i.e. microHAM DIGI KEYER and micro KEYER, regardless of model.

* '''Operator logon selects DVK bank
: With this option checked, logging on (using <code>[Ctrl][O]</code> or <tt>OPON</tt>) will select the DVK message
: bank for this callsign. If there is no such memory bank defined, it is created.
: With this option unchecked, all operators will use the same memory bank.
: Be aware that with this option checked and no operator logged on, the common memory bank will be used.

* '''Device without CAT interface
: With this option checked, DXLog will force the operating mode of the device.
: This is required for devices such as u2R which lacks a CAT interface and thus can not determine this by itself.
: It can also be used for more advanced devices, such as MK2R+, if its CAT interface is not used.
: Works for both single and dual radio devices.
: '''Important:''' In digital modes DXLog only sends a mode command to the device at startup. This is because radios
: need to be configured differently depending on model and digital mode; PKT, USB-D, DIG, etc.
: To force mode settings onto the microHAM device, type the relevant mode in the entry line and press <code>[Enter]</code>.

* '''RTTY is FSK
: This option is only active for microHAM devices without CAT.
: When checked, it will force the device into FSK mode in RTTY.

* '''Digital is VOICE
: This option should be checked if the device is a microHAM u2R which only supports CW, VOICE, and FSK.
: With this option checked, the default mode for digital operation is VOICE.

* '''Radio 1 RX, Radio 1 TX, Radio 2 RX, and Radio 2 TX tabs'''
: Each tab defines a rule for the two 4-bit BCD outputs on the ACC connector on the back side of the MK2R, MK2R+, or u2R.
: The two ACC outputs are typically used for antenna or PA band selection but can have other uses too.
: The location of the checked box is translated into a 4 bit binary pattern.
: '''Important:''' Band names are 160-10, 50, 70, 144, 432 etc.
: '''Important:''' This means only one box can be checked per row.
: Please refer to the latest microHAM documentation for possible changes to this rule.
: '''Important:''' The coding is not BCD. Check mark location number 1 means 0000, 2 = 0001, ... 13 = 1100, 14 = 1101, 15 = 1110, and 16 means 1111.
: The bit pattern in the Radio 1 RX and Radio 1 TX tabs control the RADIO 1 ACC port and the Radio 2 tabs control the RADIO 2 ACC port.
: The configuration allows up to 25 different band/antenna associations.
: Having multiple antennas on the same band is supported.
: For multi-band antennas you need to include a band line for each band it covers.
: The 60m band has was added in release 2.4.15 so if not visible, clicking RESET will make it appear.
: For information on antenna selection, see the [[Menu_Windows#Antenna_selector_R1.2FR2|Antenna selector]] section.

: '''Important:''' To enable the use of different RX and TX antennas, <code>Options|Interface specific options|Allow different TX/RX antenna</code>
: must be checked. The keyer's respective ACC outputs must also be configured for microHAM protocol control.
: This is done in the ACC tab in the microHAM's Device Router set up as shown below.

:[[image:Microhamrouteracc.png|none|frame]]

==OTRSP device configuration==

* '''Enable OTRSP device DVK
: Enables the use of a digital voice keyer in the OTRSP device.
: Supports recording and playback of up to nine messages, just like DXLog's built-in voice keyer.

* '''Radio 1 and Radio 2 tabs'''
: Each tab defines a selection of states for up to four four-bit Aux outputs. Unlike microHAM, any bit pattern is allowed.
: Each state (i.e. line) associates a band with an antenna usable on that band.
: The configuration allows up to 25 different band/antenna associations.
: Each group of four pins is associated with an Aux output, as listed in the upper left of the panel.
: It is possible to have several antennas for the same band.
: A multi-band antenna needs to have one band-line for each band it covers.
: The bit pattern presented to the Aux outputs is the combination (logical OR) of the currently selected antenna for each radio.
: This means that if Aux 1 is used to control the antenna for radio 1 and Aux 2 is used to control the antenna for
: radio 2, columns 5 through 8 must be unchecked for radio 1 and columns 1 through 4 must be unchecked for radio 2.
: C.f. the example configurations below.
: The 60m band has was added in release 2.4.17 so if not visible, clicking RESET will make it appear.
: '''Important:''' Band names are 160-10, 50, 70, 144, 432 etc.
: '''Important:''' The use of different antennas for transmission and reception is not supported.
: For more information on antenna selection, see the [[Menu_Windows#Antenna_selector_R1.2FR2|Antenna selector]] section.

[[image:OTRSP Setup radio 1.png|none|frame]]

[[image:OTRSP Setup radio 2.png|none|frame]]

==Winkey configuration==

Configure the WinKey properties 
Text command : <code>WKSETUP</code> or <code>WKEY</code>

[[image:winkeyconfig2.png|none|frame]]

'''Important:''' If you are using a microHAM keyer, the below settings will only have effect if 
the Allow logger control option is checked on the USB device router's <tt>CW/Winkey</tt> tab.

'''Important:''' For Winkey 2.3 or later, PTT is managed correctly by the Winkey chip and DXLog PTT should not be used. 
For earlier Winkey, COM port PTT may be required to keep PTT from dropping between transmitted words.

* Keyer mode:
** Iambic A - Curtis A iambic timing
** Iambic B - Curtis B iambic timing
** Ultimatic - Non iambic mode
** Dit
** Dah
** Bug (semi-automatic) - WinKey makes the dits and you make the dahs. Vibroplex style.
: In either Iambic mode, alternating dits and dahs are sent while both paddles are held closed.
: In Iambic mode B, which emulates the legendary Accukeyer, an extra alternate dit or dah is sent after both paddles are released.
: In Ultimatic mode, when both paddles are pressed, the keyer will send a continuous stream of whichever paddle was last pressed.

* Reverse - Reverses the dit/dah paddles (e.g. for keying with the left hand)
* Autospace - If you pause for more than one dit time between a dit or dah, Winkey will interpret this as a letter-space and will not send the next dit or dah until a full letter-space time (3 dits) has passed

* Hang time - Sets PTT hang time for paddle transmission

* Pot controls
** Nothing: Winkey speed knob/potentiometer has no action
** Paddle only: Winkey speed knob affects only paddle CW speed (Recommended)
** Paddle and DXLog : Winkey speed knob changes both DXLog and paddle CW speed

* Two wire: Makes the Winkey assume it is controlled by a 2-wire potentiometer. Rarely used.

* PTT - Enable PTT control from Winkey. Preferably disabled on WKmini. Be aware that this setting is ignored for some integrated Winkey chips, such as in microHAM devices.
* Use two Outputs - WinKey pin 5 keys a second radio. Enable with WKmini to key tip of connector.

* Sidetone - Disables or sets the sidetone frequency on keyers with speaker .

* Extra buffering - Transmits N+1 characters at the time to WinKey. May improve performance with WinKey clones that do not respond timely or with remote operation when using Winkey keying over an internet link. Any number above zero will reduce ability to edit sent text while transmitting.

* Detect paddle for interlock - Makes DXLog detect paddle transmission just as e.g, a footswitch to block other stations if interlock is used
* SO2R Mini extension - Activates protocol extensions for controlling an [https://nn1c.org/so2r/ SO2R Mini].

==MP3 configuration==

Sets the configuration for the MP3 encoder used by the [[Menu_Windows#Contest_Recorder|Contest Recorder]] window.

Player is the output device, normally your PC speaker.

Recorder is the recording device, e.g. the audio device in your SO2R controller or the built-in soundcard in your radio.

Recordings are made in stereo, so both radio 1 and radio 2 (or the main and sub receiver) can be recorded.

The sample rate and coding rate can be set at different values. For normal purposes 8000Hz sample rate and 
24kbps coding rate is sufficient and consumes the least disk space.

[[image:mp3config2.png|none|frame]]

==Rotator configuration==

DXLog supports rotator control using UDP communications to PstRotatorAz by YO3DMU and the EA4TX rotator controller.

'''Important: Do not confuse PstRotatorAz with PstRotator.'''

DXLog also offers a generic UDP broadcast based rotor communication, described [[Additional_Information#Antenna_direction|here]]. This does not 
require any configuration besides enabling it in <code>Options|Broadcast|Antenna direction</code> and selecting the 
desired port in the network configuration panel.

The configuration steps for PstRotatorAz and EA4TX are to be fond below.

You may also find [[http://dxlog.net/sw/files/utilities/DXLog%20rotator%20configuration_v2.pdf this guide by F8GHE]] useful.

[[image:PSTRotator DXLog config3.png]]

Check the "Enable Rotator communication" box at the top of the form.

Enter the required data in each column. Use the Add, Edit, and Delete buttons as required. The columns are:

* Band
: Bandname(s) for which this rotator is active. In meters down to 10, thereafter in Megahertz.
: Comma-separated list if several.
: Example: 15,12,10,50,144

* Ant #
: '''Very important:''' Set to 0 (meaning any antenna) if not using the special Antenna server functionality.
: The number of the antenna for this band turned by this rotator, beginning at 1.
: Antennas are numbered in the order shown on the <t>Radio/Ant Status Window.

* IP Address
: If you are running PstRotatorAz or EA4TX on the same machine as DXLog,
: enter 127.0.0.1. Otherwise enter the IP address of the rotator control server.

* Port
: The UDP port used to communicate with the rotator interface. Normally PstRotatorAz uses
: 12040 for the first rotator, 12042 for the second, etc. However, any port that is free can be used.
: '''Important:''' PstRotatorAz uses two ports, N and N+1, so when configuring multiple rotators, do not use subsequent port numbers.
: Write down the ports used as they are needed for PstRotatorAz or EA4TX configuration.

* Radio
: Determines which radio controls the rototator. Set to zero ("0") for any radio.

* Send freq
: Check this box if you need the radio frequency to be sent to PstRotatorAz.

Select the rotator software type from the drop down list, currently either PstRotatorAz or EA4TX

When completed, press OK.

To configure PstRotatorAz, you may need to refer to the PstRotatorAz manual. Here are the basic steps:

From the PstRotatorAz menu bar, Select <code>Setup|Trackers Setup|DXLog.net/Swisslog</code>.

[[image:Pstrotatoraz-setup.jpg]]

The Setup displayed will be:

[[image:Rotator_tracker_setup_DXLog.png]]

Enter the port number used for this rotator in the Ethernet box. Select 'Azimuth' or 'Callsign' in 
the "Tracking by" box based on preference. Click Save Settings.

Select <code>Tracker|DXLog.net</code> from the PstRotatorAz menu bar.

In the main display, select 'Tracking' from the Mode box. Depending on the view you have selected, you may need to select 
View -> Full View to see the Mode box. The following shows the location of the Mode box in PstRotatorAz:

[[image:PSTRotator_tracking_mode.png]]

If you have more than one rotator, repeat the steps on each instance of PstRotatorAz, using the appropriate UDP Port number. 
See the PstRotatorAz documentation to enable multiple instances of PstRotatorAz.

Once you have everything configured, return to DXLog. Ensure you are on the appropriate band (and the proper antenna selected). 
Enter a callsign or an azimuth value into the callsign field. Press <code>[Ctrl][F12]</code>. DXLog will show the value sent on 
the status line, and the rotator should rotate to the selected azimuth.

Enter a callsign and press <code>[Alt][F12]</code>. Rotator will turn to the long path azimuth.

This completes Rotator configuration. '''Important:''' You may have to restart both DXLog and PSTRotatorAz for correct operation.

==Configure network==
This panel allows configuration of network addresses and identity.

Text command: <code>NETCONFIG</code>

[[image: Network_parameters_form4.png|none|frame]]

* ''Station ID''
: The name/identity of the station used in DXLog networking.
: The name is used for e.g. software interlock, gab messaging, and multiplier passing.
: It is recommended to use explanatory station names such as "INBAND", "RUN1", etc.
: Station names including dash ("-") do not work with macros since dash in a macro is a separator and CW speed reduction.

* ''UDP networking for multiple stations'' (checkbox) Enables UDB based networking. DXLog can use both broadcast-based UDP networking and client-server based networking. Note that UDP is a protocol without confirmation or retransmission and thus vulnerable to packet loss. '''Important:''' Wi-Fi networking is not recommended for any contest station but if used, client-server networking should be used.
** ''UDP network parameters'' IP address and port information for UDP networking. The ''Default'' button will enter the DXLog default parameters. '''Important:''' On computers with multiple active network adapters, the broadcast IP address may have to be entered manually for correct operation.

* ''Act as network server'' (checkbox) Enables client-server based networking with this station as server. '''Important:''' Only one server is allowed on the network.
** ''Server parameters'' The IP address of the PC and the selected port.

* ''No spots via client/server'' (checkbox) Spots will only be forwarded inside the peer-to-peer network and not via client-server connections. Valuable feature when e.g., networking over WAN.

* ''Connect to network server'' (checkbox) Enables client-server based networking with this station as a client.
** ''Client parameters'' IP address and port of the server. This entry box supports both numeric addresses as well as URL via DNS lookup.

* ''Other parameters''
:* ''Network timeout (sec)'': timeout value for network connections.

:* ''Time synchronization server'' (checkbox)
:: Makes the current station the master for station time synchronization.
:: '''Only one station per network should have this option checked''' and all other
:: stations '''must run DXLog as administrator''' to allow adjustment of the computer's time.
:: To run DXLog as administrator, right-click the desktop icon and select the option.

:* ''Serial number server'' (checkbox)
:: Enables the serial number server which allows multiple stations/radios to use serial numbers in chronological
:: sequence for contests that require this, e.g. CQ WPX, in spite of interleaved QSO.
:: '''No more than one station per network may have this option checked.''' (Usually the main run station)
:: Note: All stations must have <code>Options|Networking|Use number server</code> checked to use the server.
:: (Except support stations as these stations do not log).
:: The number server must be used also for SO2R in contests that requires chronological serial numbers.
:: More information can be found in the [[Additional_Information#Using_a_number_server|section on using a number server]].

* ''Live score UDP broadcast''
: IP address and and port number for broadcast of live score information.

* ''DX cluster spots UDP broadcast''
: Up to three IP addresses and port numbers can be specified, separated by space.
: For more information, see [[Additional Information#UDP broadcast|UDP broadcast]].

* ''Radio information UDP broadcast''
: Up to three IP addresses and port numbers can be specified, separated by space.
: For more information, see [[Additional Information#UDP broadcast|UDP broadcast]].

* ''Antenna direction UDP broadcast''
: Up to three IP addresses and port numbers can be specified, separated by space.
: For more information, see [[Additional Information#UDP broadcast|UDP broadcast]].

* ''QSOs UDP broadcast''
: Up to three IP addresses and port numbers can be specified, separated by space.
: For more information, see [[Additional Information#UDP broadcast|UDP broadcast]].

* ''UDP broadcast listener''
: Up to three IP addresses and port numbers can be specified, separated by space.
: For more information, see [[Additional Information#UDP broadcast|UDP broadcast]].

==Enable network==

Text command: <code>NETON</code> or <code>NET</code> and <code>NETOFF</code> or <code>NONET</code>

Enables or disables station networking.

Important: If you intend to use the number server in a multi-station setting it is not sufficient to only enable the network. 
A network interface (UDP or client/server TCP) must also be enabled in the network configuration panel (see above).

[[image:neton.png]]

==Networking==

 

[[image:Options_networking_menu2.png]]

===Synchronize standard messages===

Force the standard (CW/Digital) messages on this station onto all other stations on the network.

===Synchronize log===

Immediately starts the synchronization of logs between networked stations instead of waiting for periodical synchronization. 
May be used to "catch up" a rebooted station more quickly.

===Block logging on this station===

When checked, QSO cannot be added to the log at this PC.

Instead, the callsign entered into the log entry callsign field will be added to the bandmap and the log entry callsign field will be cleared.

This option is usually used for Partner mode or operator training.

===Use serial number server===

This option, when selected, enables the use of a number server. The purpose of a number server 
is to allow all networked stations (or both radios in case of SO2R) to use serial numbers 
in chronological order. The most well known contest with this requirement is CQ WPX.

Only one DXLog instance in a network can be the number server, all other DXLog must have this option unchecked.

When checked, the DXLog number server will be used to determine/reserve the next serial number. 
The reservation of a serial number can either be done with via menu options <code>Tools|Data entry|Space key reserves serial number</code> 
and <code>Tools|Data entry|Insert and F2 messages reserve serial number</code> or by adding <tt>$RESERVENR</tt> 
macro to the F2 RUN and S&P messages.

Typically the space option is preferred for phone whereas the macro option is preferred for CW.

<code>Options|Networking|Use serial number server</code> must be checked on all stations on the network that require 
the use of serial numbers (i.e. all stations logging QSO)

If number reservation is successful, the user will be notified in the status bar at the bottom of the main window 
and the serial number in the QSO entry line will change color (Default red).

If a number is reserved but the QSO is not made, a number reservation can be revoked by wiping the entry line. 
(<code>[Alt][W]</code> or <code>[F11]</code>).

'''Important:''' if you are using the number server on a single computer (for SO2R) you need to enable the network 
but you do not need to enable any networking interfaces in the Network configuration panel. You only need to check 
the ''Serial number server'' box.

===Block logging if serial number reservation is unsuccessful===

When using the serial number server and this option is checked, logging will be blocked 
until a serial number is successfully retrieved from the number server.

When a number server is used and the reservation process has started, DXLog will show the active 
QSO number as 000 until a serial number has been successfully reserved or the reservation is canceled.

===Block standard messages if band/mode change rule is broken===

When operating a contest in a multi-station environment, this option will prevent the use of 
the standard F-key messages if the contest's band/mode change rule is broken. 
Keyboard CW (<code>[Alt][K]</code>) and additional (<code>[Ctrl][Alt][F#]</code>) messages are not affected. 
Blocking all messages is primitive and better control is offered by using the <tt>VIOLATION</tt> 
macro conditional in relevant messages.

===Show different active QSO line color during wait status===

When operating a contest in a Multi transceiver environment, this option will change the color of 
the active log so entry line when the band change rule is violated. 
The use of this option is recommended.

* Example: You make QSO on the multiplier radio on 40m band at 00:00Z.
: In that case, you have to stay with multiplier station on 40m until 00:10Z when you are then allowed
: to QSY to other band with the multiplier station.
: If you do it earlier, or you have multiple multiplier stations, each of them will see the QSO line in
: a different color until the 10 minutes has expired. By default the color is red, until last
: minute when it changes to yellow... and after that it reverts back to the normal background
: color of the logging screen.

In multi/single environment it is very useful for each operator to see if a QSO is allowed on 
that band or not. It's easy, you just have to look at the screen, and if the log entry line is 
red in color, you are not allowed to make a QSO. The timers are also visible in the ''Network status''
and ''Band change info'' windows.

===Block standard messages if no operator is logged on===

If checked, F-key messages are disabled if there is no logged on operator.

===Space key updates QSY Wizard===

If checked, ''HamCAP'' will be automatically invoked when <code>[Space]</code> is pressed 
and QSY information will be shown in the ''QSY wizard'' window

===Enable interlock===

Text command: <code>ILOCK</code> and <code>ILOCKON</code> enables interlock 
Text command: <code>NOILOCK</code> and <code>ILOCKOFF</code> disables interlock 

When this option is checked, software interlock is active. 
Transmission is only possible if the other networked DXLog stations allow it.

When enabled, interlock status is shown as a banner in the ''Operating info'' window.

The ''Radio Status'' window illustrates blocking status through its background color. 
Green means successful transmission, yellow means an interruptible block, and red means 
an uninterruptable block.

[[image:inbandblocking.png]]
[[image:inbandblocked.png]]
[[image:Inbandblockinginterruptable.png]]

===Configure interlock===

Text command: <code>ILOCKC</code> or <code>ILOCKCONFIG</code>

[[image:interlock_options.png|none|frame]]

"Status list" refers to the content of the ''Network status'' window.

===Interlock priority options===

Note that the below options are only available when software interlock is activated.

* '''First one wins'''
: No transmissions are interruptible. The station that first starts
: to transmit is always allowed to complete its transmission.

* '''Last one wins'''
: All transmissions are interruptible. All stations can always
: interrupt the transmission of another station. (Not recommended.)

* '''Last one wins if msg not'''
: All but a defined set of messages are interruptible.

* '''Last one wins if msg is'''
: Only a defined set of messages are interruptible.

* '''If msg/is not selection'''
: Selectable list of messages for more granular control of last one wins strategies.

Although it is considered a good practice to use symmetrical blocking strategies, i.e. having 
identical settings in each participating station, it is possible to have different settings in each station. 
If experimenting with this, keep in mind that the interlock strategy settings refer to the 
behavior of blocked station, not the blocking station.

'''Important:''' For software interlock to work on Phone, a external PTT recognized by DXLog must be used. 
The by far simplest solution is to use a footswitch connected to a microHAM device. 
See the [[Menu_Options#microHAM_device_configuration|microHAM configuration]] section for more details. 
It is also possible to connect a footswitch directly to the computer's RS-232 port, providing it has one. 
How to do this is described [[Additional_Information#Connecting_a_footswitch|HERE]].

[[image:k3_settings2.png|400px]]
 

===Announce QSO progress status in interlock===

Show QSO progress status ("CQ", "QSO", "EXCHANGE") instead of "MAN" '''on the blocked station''' when 
asserting PTT on blocking station.

The rule for determining the status is:
* If the call sign field is empty, the block request reason message is "CQ"
* If the call sign field is not empty and focused, the block request reason message is "QSO"
* If the call sign field is not empty and not focused, the block request reason message is "EXCHANGE"

Note that this setting controls the message sent by the blocking station so it needs to be set on 
all interlocked stations for proper function.

===Optimistic interlock===

Applies to software interlock. If a "blocking allowed" confirmation is not received from all 
stations requested before timeout, assume that all relevant stations are blocked and start 
transmission.

===Allow other stations to abort sending===

Checking this option allows other relevant stations (e.g., an inband station) 
to interrupt your transmission.

<code>[Shift][Esc]</code> aborts transmission on other stations.

The key works differently when software interlock is enabled and when it is not.

* With software interlock enabled, stations matching the interlock criteria will be interrupted.

* With software interlock disabled, stations on the same band for multi-multi and of
:the same type for other operations will be interruped.

Also when this option is disabled, the operator may be informed that another station is trying to abort 
the transmission. This notification can however be disabled, see [[Menu_Options#Log|here]] for more information.

==Broadcast==

For details, see the [[Additional_Information#UDP_broadcast|UDP broadcast section]]

==DX cluster==

DX cluster telnet settings and options 
[[image:Dxclustermenu4.png]] 

===Spot handling policy===

Controls how a new incoming spot (local or cluster) is handled.
Three options are available that differ in terms of what existing spots
are removed before the new spot is added. The result is sensitive to
the spot bandwidth (as set in bandmap Properties) centered on the new spot's frequency:

* '''Standard''' - Remove any existing spot with same band, mode, and call as the new spot;
: and any existing spots within the spot bandwidth of the new spot.
: Keeps a relatively uncluttered spot display, with only the most recent spot shown within the
: spot bandwidth of any frequency on the bandmap.
: Pro: Only shows the most recent spot on each frequency.
: Con: In Run you will not be warned if a station you can not hear, e.g. in your skip zone, is calling CQ on your frequency.
: Con: In a busy, global contest, the band map content can be quite volatile.

* '''Complete''' - Remove any existing spot with same band, mode, and call as the new spot;
: and any existing already-worked ("dupe") spots within the spot bandwidth of the new spot.
: Provides a more complete spot display, allowing displayed non-worked spots to be
: within the spot bandwidth of each other.
: Pro: Provides a complete picture with no risk of missing valuable spots.
: Con: None, really.

* '''None''' - All spots are kept. Can quickly result in a very cluttered
: bandmap with many duplicate spots. Recommended only for testing purposes.
: Resembles "Bandmap type: Multiplier" option prior to release 2.4.3.

===Edit connection list===

Add/remove/edit DX Cluster information.

[[image:DXC_list.png]]

To set a default DX cluster connection, select the connection from the list and click the '''Default''' button.

When editing or adding a new connection, give the connection a meaningful name and enter the address, 
either an IP address or a domain name plus the access port for the telnet connection.

[[image:DXC_def.png]]

The DX Cluster connection list can also be bulk edited by loading the file dxclist.txt in a regular text editor. 
The dxclist.txt file is stored in C:\Program Files (x86)\DXLog\Database and should be overwritten with the latest file available. 
DXLog will automatically use this latest file upon running after the file has been updated.

The dxclist.txt file is formatted as follows:

<code>Display Name=internet_address;port_no;Login_Required_(Yes/No);;</code>

E.g.:

<code>W9PA - No Skimmer=dxc.w9pa.net;23;YES;; *W9PA=dxc.w9pa.net;7373;YES;; W9PA - FT8 Only=dxc.w9pa.net;7374;YES;;</code>

A leading Asterisk "*" before the display name marks the default connection.

===Reset connection list===

Resets the connection list content to its default content. Deletes user additions and changes.

===Reconnect default cluster node at start===

Automatically re-establish connection to DX Cluster on loading or creating a new log.

===Default comment for posted spots===

A default comment when submitting spots to the cluster with <code>Alt-F3</code> or S&P auto-spotting. 
This is typically the name of the contest, such as "CQWW" or "WAE".

===Add exchange to posted spots===

Adds the first part of the contest exchange when submitting spots to the cluster, either manually or automatically. 
This option is only active for contests with where the first part of the exchange does not change, such as e.g. county or zone.

===Self spot comment===

Comment added to self spots. Defaults to the name of the current contest.

===Send spots to SmartSDR===

Sends spots via UDP broadcast for display in other software such as SmartSDR. 
Information on configuration can be found [[Menu_Options#Configure_network|HERE]].

===Don't send ineligible spots to SmartSDR===

Prevents sending spots ineligible for the contest over UDP and to SmartSDR.

===Show talk messages from cluster in GAB window===

Cluster talk messages will be shown in the GAB window.


===Don't show logged call in bandmap in Run===

The default behavior of DXLog is to create a local spot at the current frequency, applying the current 
spot processing policy for erasing adjacent dupes, etc.

Checking this option will prevent this and therefore also give the opportunity to e.g. notice if someone 
else is spotted on your Run frequency.

Note that this setting does not prevent the creation of spots in the bandmap by other, networked stations.

==HamCAP==

HamCAP and VOACAP must be installed for these options to work.

HamCAP is a HF propagation prediction tool and is useful for contest strategy and watching for 
possible openings for multipliers. It relies on VOACAP which operates silently in the background.

HamCAP can be downloaded from http://www.dxatlas.com/Download.asp 
Make sure to use the most recent SSN database. It can be downloaded from the same location.

VOACAP can be downloaded from http://www.greg-hand.com

[[image:hamcap_options.png]]

[[image:hamcapprop.png]]

HamCAP options are:

* '''In background''' - prevents HamCAP from grabbing focus, also when on top.
* '''Always on top''' - makes sure HamCAP is always visible, also in front of DXLog.
* '''Tab''' - controls which HamCAP tab is displayed when invoked from DXLog.

To enable automatic HamCAP prediction by pressing <code>[Space]</code> check <code>Options|Networking|Space key updates QSY Wizard</code>. 

With this option checked, pressing <code>[Space]</code> with a call sign in the entry field will trigger a propagation forecast.

==Data files==
This menu is used to update the SCP and Country files from the internet and set Extra 
info and exchange guessing data base options.

[[image:Options_data_files_menu.png]]

'''It is recommended to update the Country Files and SCP database before every contest'''

===Country files===

Text command: <code>CTYFILES</code> or <code>COUNTRYFILES</code> 
Opens the panel below:

[[File:Dxl_country_files.png]]

Allows you to choose which of the country files you will use for calculation of DXCC, CQ zone, 
ITU zone etc. in the currently active contest. 

It is recommended to always use CTY_WT_MOD.DAT which will provide you with the most 
accurate information.

Click on '''Download''' to update the selected country file from the internet and click OK.

After clicking OK, DXLog will ask you to reload the currently active log in order to 
refresh all calculations. This can easily be done using the text command RELOADNOW.

===Update Super Check Partial database===

Downloads the latest version of the super check partials MASTER.SCP database.

On successful download and update you will be asked to restart DXLog, which 
is easily done with the text command <tt>RELOADNOW</tt>.

:[[image:Master.png]]

===Update prefill database from log===

Updates your local prefill database with information from the currently opened log. 
Missing information will be added and prefill data that was modified when logging will be changed.

Please note that all comments in the original data base file (lines starting with # or !) are lost in this process. 
All three types of databases, ''TXT'', ''CSV'', and ''DTB'' can be updated.

'''VERY IMPORTANT:''' Does not work for "mixed population" contests where not all stations have a fixed exchange.

===Extra info plugins | HamQTH===

Enable or Disable, If enabled, a valid Username and Password must be set in the configuration panel. 
'''Important:''' If your password contains "strange" characters such as ?@#$%& or non-latin letters, the service may not recognize your login.

[[image:hamQTHconf3.png|none|frame]]

===Extra info plugins | QRZ===

Enable or Disable, If enabled, a valid Username and Password must be set in the configuration panel.

'''Important:''' If your password contains "strange" characters such as ?@#$%& or non-latin letters, the service may not recognize your login.

'''Important:''' Requires an active XML subscription with qrz.com.

For more information, see https://www.qrz.com/page/xml_data.html

[[image:QRZconf2.png|none|frame]]

===Prefill database settings===
 
[[image:Prefill database settings2.png|none|frame]]

One or more prefill database(s) may be configured using this panel. 
All information entered here will '''override''' the default database settings 
in the contest configuration. However, when a new log file is created, the default 
settings from the contest configuration file will be used.

To configure the use of a database file, click ''Browse'' and select the database file. 
The standard location for database files is <tt>%appdata%\DXLog.net\Database</tt>. 
Select the database file type using the pull down menu. 
Standard DXLog prefill database files are type ''TXT''. N1MM Logger+ database files are type ''CSV'', and 
WinTest database files are type ''DTB''. Be careful to chose the correct file type.

TXT and CSV files typically have a .TXT filename ending. DTB files typically have a .DTB filename ending.

DXLog supports up to four contest exchange elements. Their name, from left to right, are RCVD, RECINFO, 
RECINFO2, and RECINFO3.

You map an information element in a prefill data base file to an exchange element by specifying its number. 
The first information element following the callsign is number 1, the next is number 2, and so on.

* The line format in a DXLog prefill data base file is:
:<code>callsign1;callsign2;callsign3...=information1;information2;information3...</code>

* The line format in a N1MM Logger+ prefill data base file is:
:<code>callsign,information1,information2,information3,information4</code>

* The format for a standard Win-Test prefill data base file is binary and not possible to easily edit or view.

To not use data for a selected exchange element from a database file, set its number to -1. 
This can be relevant in the case of having several data base files, each contributing to individual exchange elements. 
For example, one data base file for grid locator and another for operator name or state. 
In the example above the first exchange element (name) is collected from information element 
number 1 in the CWOps data basefile, whereas the second exchange element (state) is collected 
from information element number 2 in the NAQP database.

'''Special feature for timed prefill database files''': Some contests use age (license, birth, etc.) as exchange 
which is (unfortunately) not constant over time. Such a database file must include meta command #@NNNN (e.g., #@2022) 
to tell DXLog for which year the file is valid. The #@NNNN command must be the first line in the file. 
The #@NNNN commmand only works for contests with age as the only exchange and will produce a dual digit number as prefill. 
The two special ages "00" (YL) and "99" (club) are unaffected by file age.

DTB files only have one information element per call sign and the column numbers should be left at zero.

The ''Fill format'' text box allows you to optionally specify special formatting of the looked up prefill information, 
using C# string formatting syntax. For example, to append a slash to the prefill, the fill format would be <code>{0}/</code>. 
Note that the argument {0} is of the type ''string'' which means that numerical operations, such as zero padding, will not work.

You can have multiple, overlapping databases. For instance you may have two data bases with grid locator information. 
DXLog will start looking for the call in database #1 and then continue down the list until a match is found. 
This means that as a rule, the most up-to-date database should be placed highest in the list. 
In the Check Partials window the context menu option "Show data from prefill database" will show you the content of all 
databases used.

Exchange elements not used in the current contest (most only have one) are ignored and can be safely left as zero.

==Statistics files==

Allows the creation and saving of statistics.

[[File:statistics_menu.png]]

'''DXCC''': Statistics related to DXCC.

: ''Create multiplier statistics'' - Create DXCC multiplier statistics during the contest.

: ''Save multiplier statistics in file'' - Saves the DXCC multiplier statistics in a file. The file format is SQLite (.sdb).

: ''Import expected mult list from log file'' - Import expected mults from a previous contest log (*.dxn) file.

: ''Clear expected mult list'' - Clear the expected DXCC multiplier list.

==Log==

Log display options. Controls the appearance and functionality of the log fields.

'''Important:''' This sub menu can also invoked by right-clicking the DXLog desktop or 
the log entry window when run in "floating mode".

[[image:options_log_menu_3.png]]

* '''Log and entry lines''' - Opens a panel allowing you to hide or display selected fields in the log and entry lines.
* '''Fonts''' - Set the size of the log text.
* '''Entry line fonts''' - Set the size of the entry line text. '''Important:''' Is never smaller than log.
* '''Headers''' - Controls the display of log column headers. Also offers the option to add headers to the entry line(s).
* '''Show QSOs for all bands''' - Controls the display of QSO in the log lines.
* '''Hide DX cluster multiplier warnings''' - Hides alerts of DX cluster spots being multipliers
* '''Hide alerts for being spotted on other band(s)''' - Hides alerts of being spotted on band(s) other than the currently operated.
* '''Hide network abort warnings''' - Hides alerts about transmission being aborted by another station.
* '''Always show mode in QSO line''' - Controls the display of mode in the log lines. Useful for multimode contests. Note that the contest configuration key <tt>FIELD_MODE_VISIBLE</tt> will override this setting and is used for some contests.
* '''Colors''' - Edit log background and text colors.
* '''Position''' - Controls location of log and entry field.
* '''SO2R/V view type''' - Sets the way the two entry lines in SO2R and SO2V are displayed. ''Classic'': show entry lines one above the other. ''Side by side'': show entry lines with one on the left and one on the right.
* '''Stay in field when moving up and down log''' - When editing log this option keeps the cursor in the same log field when moving up through the QSO's.
* '''Restrict up arrow movement''' - Prevents the up arrow key from moving the cursor into the logged QSO. Use Goto last QSO <code>[Ctrl][Q]</code> to edit log.
* '''Show previous and current messages''' - Show CW message as it is being sent below the entry line with the previous message above the log line.
* '''Show focus background color in SO2R/V''' - Use a different background color for entry line of the currently focused radio.
* '''Show RX (listen) status in SO2R/V''' - Change the entry line background when radio's audio is active. '''Important:''' Overrides focus color.
* '''Show border during transmit''' - Display a colored border around the entry line of the currently transmitting radio.
* '''Show RX wait border''' - Display a border around the entry line of the radio being held in wait status.
* '''Show cursor in entry line without focus''' - Shows a ghost cursor in the entry line without focus. Very useful for SO2R and SO2V.

==Frequency allocation==

In the heat of the moment it is easy to accidentally call a spotted station 
in a frequency where your license does not allow you to operate.

This function is to prevent exactly this.

When enabled, DXLog will issue a warning pop-up window when grabbing a 
spot in the bandmap or DX cluster announcement windows that would violate 
the selected license.

If desired, DXLog can also block F-key transmission when outside the selected license.

If your license is not listed, please contact the development team for adding it.

[[image:frequencyallocation.png]]

[[image:outofband.png]]

[[image:outofband2.png]]

==Windows==
There are two different ways that DXLog handles the opening of information windows.

* ''Included in the main window'': All windows are opened inside the main window.
* ''Floating'': Enable to use multiple monitors. All windows will be opened outside
: of the main window and can be moved as needed. Please note that in this mode,
: the color of the title bar of each window is not settable.

==Toolbar==

Enable or Disable DXLog toolbar 
[[image:toolbar.png]]

==Reset window positions==

This option brings all windows back to the upper left corner of the screen, useful if a window has been lost off the screen when changing resolution or in a multi screen environment.

File:Options log menu 3.png

2026-04-14T16:03:29Z

Sm7iun: Sm7iun uploaded a new version of File:Options log menu 3.png

Menu Options

2026-04-14T11:52:53Z

Sm7iun: /* Log */

==Load contest at startup==

* '''Enabled'''

: If checked last opened log will be opened automatically when DXLog is started. 

* '''Disabled'''

: If checked, DXLog is started but no log is opened. 

==Automatic backup==

When clicked, this will open the log automatic backup settings window. Here parameters for log automatic backup can be set according to the user's preference. 

[[image:auto_backup.png]]

==Language==

Chooses the user interface language.

==Keyboard selector==

This option allows the assignment of a different keyboard to each entry line which is 
highly recommended for advanced SO2R but also useful for advanced users in SO2V.

'''Important:''' Dual keyboard in SO2V only works for dual receiver radios and 
<code>Options|Interface specific options|Dual receiver radio (Use split in SO2V)</code> checked.

To use this feature you (obviously) must have more than one keyboard connected to the PC.

Select <code>Options|Keyboard selector</code>. A window opens showing the current keyboard assignment.

[[image:Keyboard_select_default.png]]

Now click on Define. A popup will appear asking you to identify the Radio 1 keyboard.

This keyboard will be assigned to the Radio 1 (upper) log entry line. Press any key on keyboard 1. 
Now press any key on the keyboard to be assigned to the Radio 2 (lower) entry line. If successful, 
the panel will show some cryptic identifiers for the keyboards.

If you really do have separate keyboards ensure that the identifiers are different. 
It is possible to use one keyboard and assign it to both positions, which will show as the same 
identifier for both Radio 1 and Radio 2. The panel should look something like this: 

[[image:Keyboard_select_success.png]]

Now click OK to save your assignments and close the window.

If you find that something doesn't work or need to reset to the default Any Keyboard configuration, open 
the Keyboard selector panel and select the Reset button. Click OK and any previous keyboard assignments will be removed.

==CW & Digital==

===Modify standard messages===
Text command: <code>MESSAGES</code> or <code>MSGS</code>

This option is used to edit the contents of all standard F-key, INS and PLUS messages 
for RUN and Search & Pounce mode.

[[image:standard_messages_cw2.png|none|frame]]

Any edited content is saved for the currently selected contest and '''will be used for any new log for the same contest'''.

The Defaults button will reset all messages back to their default values. This can be particularly convenient 
when switching "role" from a previous contest, such as member/non-nember, IOTA station/non-IOTA station, etc.

The Save and Load buttons allows saving and retrieving all messages to and from a text file.

If you want to reset '''all messages for all contests''' to their default values, click <code>File|Open configuration directory</code>. 
Close DXLog. Delete the file called <tt>DefMsgs.sdb</tt> and start DXLog again.

[[image:standard_messages_options2.png|none|frame]]

The Options tab allows the setting of additional message options:

''$QSOB4 macro''
: This text will be sent if $QSOB4 macro is triggered due to a duplicate QSO.
: '''Important: The use of QSOB4 mechanics in contests is a heritage from paper log days and not a recommended practice.'''

''Use only Run messages''
: DXLog will use only RUN messages, even if you switch mode to Search & Pounce.

''Use sprint exchange logic for the Insert key''
: This setting is available only for contests configured to allow sprint exchange logic and supports
: an old style of operating a sprint contest, keeping DXLog in Run mode constantly.:
: With this option checked, and in Run mode, the Insert key will send the '''RUN''' Insert message if the callsign
: field and the exchange field are empty. If they are not, the '''S&P''' Insert message will be sent.
: Note that you may need to modify the standard messages to suit your operating preferences when using this option.
: For a more modern way of operating a sprint contest, see [[]].

===Modify additional messages===

Shortcut key: <code>[Alt][C]</code>

Text command: <code>AMESSAGES</code> or <code>AMSGS</code>

Define or edit additional CW/Digital mode messages which can be invoked in a macro using commands 
<code>$MSG1..12</code> or by pushing keys <code>[Ctrl][Alt][F1..12]</code>

[[image:Othercwdigi3.PNG]

While the window is open, pressing <code>[F1]</code> through <code>[F12]</code> will send message 1 through 12 and then close window.

The Save and Load buttons allows saving and retrieving all messages to and from a text file.

Content of additional messages are saved in the DXLog config file and is thus '''common for all contests'''.

===CW keying===
'''Computer sidetone''' 
Text command: <code>SOUND</code> and <code>NOSOUND</code>

Unchecked by default. When checked, a CW side tone will be produced in the PC's default audio device. 
Only available for COM-port keying. If a smart keyer (e.g., WinKey) is used, the sidetone function is disabled.

'''Individual radio speed''' 
Text command: <code>SYNCCW</CODE> and <code>NOSYNCCW</code>

If checked, allows the CW speed to be independently set on Radio 1 and Radio 2.

The text command <code>SYNCSPEED</CODE> equalizes the speed of both radios (in SO2R) or VFO in (SO2V).

'''Reduced word spacing''' 
Text command: <code>CTSPACE</code> and <code>NOCTSPACE</code>

When checked, word spacing in CW will be 6 dits rather than the normal 7 dits.

'''Set speed''' Allows you to enter the exact CW keying speed of the focused radio in WPM. Shortcut key: <code>[Alt][V]</code>

'''Decrease speed''' Decreases the CW keying speed of the focused radio with 2WPM. Shortcut key: <code>[Alt][F9]</code>

'''Decrease other radio's speed''' Decreases the CW keying speed of the unfocused radio with 2WPM. Shortcut key: <code>[Shift][Alt][F9]</code>

'''Increase speed''' Increases the CW keying speed of the focused radio with 2WPM. Shortcut key: <code>[Alt][F10]</code>

'''Increase other radio's speed''' Increases the CW keying speed of the unfocused radio with 2WPM. Shortcut key: <code>[Shift][Alt][F10]</code>

===CW macro number sending===

Controls how numbers are sent on CW.

Number sending abbreviations applies to message macros <tt>$CQZONE</tt>, <tt>$ITUZONE</tt>, <tt>$EXCHANGE</tt>, <tt>$RST</tt>, <tt>$SERIAL</tt>, 
<tt>$NEXTSERIAL</tt>, <tt>$PREVSERIAL</tt>, <tt>$POWER</tt>, <tt>$PREV_RCVD</tt>, and <tt>$PREV_RECINFO</tt> and QTC macros <tt>$TIME</tt>, <tt>$NR</tt>, and <tt>$QTC</tt>.

The abbreviations are not applied to macros sending a frequency, time, or grid, such as <tt>$FREQR1</tt>, <tt>$TIME</tt>, or <tt>$GRID</tt>.

<tt>$RST</tt> is a special case with the minimum abbreviation being 5NN.

The available options are:

'''Use 'O' as abbreviated zero''' When checked, all number '''0''' are replaced with the letter '''O'''. '''Important:''' This is an outdated practice and only a source of confusion in contests.

'''Unabbreviated [01590]''' When checked, all numbers are sent without any abbreviation. ($RST sends 5NN.) Text command: <code>NOABBREV</code>

'''Lead abbreviated [T1590]''' When checked, all leading zeroes are sent as the letter '''T'''. Text command: <code>SEMIABBREV</code>

'''Abbreviated [T159NT]''' When checked, all numbers '''0''' and '''9''' are replaced with the letters '''T''' and '''N'''. Text command: <code>FULLABBREV</code>

'''Pro abbreviated [TAENT]''' When checked, all numbers '''0, 1, 5''' and '''9''' are replaced with letters '''T, A, E''' and '''N''' Text command: <code>PROABBREV</code>

'''Custom abbreviation''' When checked the Custom Abbreviation table will be used to substitute characters

'''Set custom abbreviations''' Enables editing of substitutions character by character When clicked, a panel will open to allow assignment of character substitutions.

[[image:custom cw digi abbreviation table form.png]]

* <code>Add</code> Adds a new substitution. First enter the character to be replaced. Then enter the character to be used in its place. 
* <code>Delete</code> Removes the currently selected substitution. 
* <code>OK</code> Saves changes and closes the form 
* <code>Cancel</code> Discards changes and closes the form

Characters/digits not included in the substitution table are sent in their original form.

===Send leading zeros in serial numbers===

Text command: <code>LZ</code> and <code>NOLZ</code>

When checked, macros sending numbers will always send three digits. 

Shorter or longer zero padding can be achieved by adding number within parenthesis 
to the serial number macro e.g., $SERIAL(2).

===Send frequencies rounded to kHz===
If checked, the frequency sent by the $FREQS, $FREQP, and $FREQnn macros will be rounded to the nearest kHz. 
If not checked, the frequency is rounded to the nearest 100 Hz. An 'R' is sent as decimal separator.

===Disable worked-before macros===

Text command: <code>WORKDUPE</code> or <code>WORKDUPEON</code> and <code>NOWORKDUPE</code> or <code>WORKDUPEOFF</code> 

When checked, the <code>$QSOB4</code> and <code>$QSOB4WIPE</code> macros will do nothing, regardless 
if the current callsign is a dupe or not.

Checked by default. It is a bad and outdated practice to not work dupes in a contest.

===Remap keys in keyboard mode===

When checked, keyboard remapping will be active also when sending CW/RTTY text in keyboard mode.

===Remap keys in QTC receive===

When checked, keyboard remapping will be active also in the QTC receive window. 
This option is only available if the contest entry involves receiving QTC.

===Auto sending===

Text command: <code>CWAUTO</code> or <code>AUTOCW</code> and <code>NOCWAUTO</code> or <code>NOAUTOCW</code>

[[image:autocw.png|none|frame]]

When enabled and the mode is CW and you are in Run, DXLog will start sending the Insert message after having 
typed a selected number of characters of the callsign, removing the need to press <code>[Insert]</code> to respond to a call.

The rule for start of transmission of the RUN INSERT message is:

Typed characters contain both a letter and a number AND has reached the threshold number OR typed characters include a slash and 
the number of characters following the slash has reached the threshold number

This means that with the threshold set to 2 transmission will start when pressing

: 7 in SM7IUN
: 2 in SM/E21EIC
: the first 7 in E77DX

and with the threshold set to 3, transmission will start when pressing

: 7 in SM7IUN
: 1 in SM/E21EIC
: the second 7 in E77DX

'''Important:''' When using a number server, a serial number reservation will automatically occur at the start of the RUN INSERT message.

Tip: When you open the dialog to configure auto sending, <code>[Space]</code> will enable/disable and 
<code>[Enter]</code> will press the OK button and close the window.

===Smart correction for $CORRECT===

When checked, DXLog will send only the part of the callsign that was corrected. 
Example: if you correct W6ABB to W6ABC, only ABC will be sent by the <code>$CORRECT</code> macro.

===Copy hour in received QTCs===

When checked, the two hour digits from the previous line will be automatically 
copied to a new line in the receive QTC window.

===QTC window font size===

Sets the font size of the QTC window used in contests with QTC such as Worked All Europe Contest.

==Configure interfaces==

Text command: <code>SETUP</code>

[[File:Portconfig.png|none|frame]]

DXLog currently supports interfaces for up to 8 COM ports and one LPT port. 
To use any of the ports to connect to the hardware and perform a function, 
you must enable the port by checking "Enabled" box.

===Serial ports===

DXLog can communicate with up to eight devices; peripherals or radios. 

For each device, you can select to use a COM port or a "pipe". 
COM ports can be in the range of COM1 to COM40.

There are two types of "pipe" connections; OTRSP and WINKEY. 
These are direct connections and do not rely on a COM port for communication. 
You can only have one of each of these.

You can not select the same COM port for more than one interface. 

Apart from communications interface (COM or pipe) the device type needs to be selected (Winkey, Radio, etc.). 
Additional settings for the device are available by clicking on the setup button on the far right.

'''The "-" port type'''

The "-" device type is a COM port where only the hardware handshake signals are used, 
such as keying or PTT.

It uses a fixed speed of 9600bps, which may cause problems in some cases, such as when 
using a port combiner.

'''Important:''' If you are using a COM-port footswitch together with an external DVK, such as that 
built into microHAM devices, you may need to select the Escape option to reliably stop DVK 
playback when pressing the footswitch.

To make sure a port used for only keying or control is opened at the right speed do the following:

Open the interface configuration panel.

* Select the wanted port and check the enable box.
* Select it as Radio 1 and click Setup.
* Select a random radio model and set the correct speed.
* Set the wanted keying (e.g. CW = DTR, PTT = RTS, Footswitch, Active with Radio 1, etc.)
* Click ''OK''
* Change from "Radio 1" to "-". Do not click Setup.
* Click ''OK''

'''The Winkey port type'''

The default setting is 1200-8-N1 with RTS always on to support the original, serial port Winkey. 
If you have a more modern keyer, you may chose a higher speed. 
'''Important:''' A Winkey always keys both radios and disables COM-port and LPT-port keying.

'''The microHAM port type'''

This device type will support any microHAM keyer with a COM port control interface. 
Serial speed and handshaking signals are ignored when connecting to a microHAM USB 
device router virtual COM port. For more information, refer to the [[Radios_and_Peripherals#microHAM|Microham section]].

'''The OTRSP port type'''

Software PTT (commands X1/X0) is available only with "pipe" connection, otherwise disabled.

Options include to not assert PTT when using DVK and to verify transmitter change before transmissions starts.

The reason for the option to verify transmitter change before transmission starts is to avoid a possible race 
condition that can occur when using a Winkey keyer and an OTRSP device. There is a risk that the keyer receives 
its command first and starts keying risking that the OTRSP device changes transmitter while transmitting. 
Checking the option will make DXLog send an OTRSP query to make sure the transmitter change has occured before keying starts. 
Since such a response is optional in the OTRSP specification, this function must also be optional.

'''The Radio port type'''

See below.

===Digital Voice Keyer===

The Digital Voice Keyer (DVK) section allows PC audio cards or adapters to be used to record and 
play back SSB DVK messages.

For selected radios, it is also possible to use the voice keyer built into the radio. 
The radio's built-in voice keyer is enabled in the [[Menu_Options#Radio_configuration|radio settings]]. 
With a few exceptions, recording is not supported. See the [[Radios|supported radios]] section for more information. 

If you have a microHAM keyer controller, its built-in voice keyer may also be used. 
The microHAM voice keyer is enabled in the [[Menu_Options#microHAM_device_configuration|microHAM settings]]. 

'''Important:''' DXLog's own DVK has priority and must therefore be disabled to allow use of other DVK. 
It is thus important to not enable more than one of these three voice keyer options.

'''Important:''' If you are using DXLog's own DVK with split (transmitting on another frequency) you may 
need to disable radio polling during transmit for stable operation.

To use DXLog's voice keyer:
* Check the enable DVK box in the interface configuration panel.
* Select the relevant DVK playback devices (audio from these must be physically connected the the radio's audio input).
* Select the relevant DVK record device (Usually a microphone connected to the PC's microphone or line input).
* Select muting as required.

In SO2R the audio playback will be channeled to the currently focused radio's playback device. 
If you are using a SO2R controller with internal audio switching, select the controller's audio device 
for both radios. In SO1R and SO2V, audio is always routed to radio 1's device.

The built-in DVK in DXLog will support up to nine different messages: 1, 2, 3, 4, 5, 6, 7, INS, and PLUS. 
'''Important:''' Your external voice keyer may support fewer. 

Recording the messages is done by pressing <code>[Shift]</code> and the wanted function key and ended with <code>[Esc]</code>. 
With no operator [[Menu_Commands#Operator_login|logged in]], the recordings are stored in WAV format in the directory <tt>%appdata%\DXLog.net\Ops</tt>. 
The filenames are <tt>F1.WAV</tt> through <tt>F7.WAV</tt>, <tt>INS.WAV</tt> and <tt>PLUS.WAV</tt>. 
If an operator is logged in, the recordings are located in a subdirectory with the operator's callsign, such as <tt>%appdata%\DXLog.net\Ops\SM7IUN</tt>

Although not recommended, the voice keyer can be used with ESM if DXLog's message convention is used. 
It is described in the [[Getting_started#Voice_memory_playback|getting started]] section.

'''SO1R, SO2R, and SO2V'''

Messages #1 through #7 are played back by pressing function keys <code>[F1]</code> through <code>[F7]</code>. 
Unlike in CW and digital, the same voice message is played back regardless of operating mode, Run or S&P. 
Any macros in messages #1 through #7 are thus ignored in SSB.

The INS and PLUS voice messages are not associated with any keys and can only be played back by a macro. 
<tt>$PBINS</tt> plays back message INS (#8 on external devices) and <tt>$PBPLUS</tt> plays back message PLUS (#9 on external devices).

The keys <code>[Insert]</code> and <code>[+]</code>/<code>[Keypad +]</code> ''work differently'' and do not directly play back a 
voice message when pressed but instead execute the macros in the associated standard message, based on key and operating mode.

This means that in the example below, pressing <code>[Insert]</code> in SSB S&P will play back voice message #2 and then log the QSO.

In SSB mode, all macros sending CW or Digital characters are ignored. In CW, the <tt>$PBINS</tt> and <tt>$PBPLUS</tt> macros are ignored. 
This means that you can create standard messages for the <code>[Insert]</code> and <code>[+]</code>/<code>[Keypad +]</code> keys that works both 
in CW and SSB without the use of conditionals.

An example of this type of multi-mode messages for Worked All Germany in the Mixed class is shown below.

[[image:Dvkmixedcontest.png|none|frame]]

'''Advanced SO2R'''

In Advanced SO2R, the function keys <code>[F1]</code> through <code>[F7]</code> are not directly associated with a 
voice memory but instead executes the active scenario's ''macro string'' associated with the key. 
More information on creating and using SO2R scenarios can be found in the [[Menu_Operating#Edit_SO2R_Scenarios|SO2R Scenarios]] section.

The message/playback macros <tt>$F1</tt> through <tt>$F7</tt> are mode sensitive. The <tt>$PGBINS</tt> and <tt>$PBPLUS</tt> are not. 
In SSB e.g. <tt>$F1</tt> plays back voice memory #1, in CW and Digital it sends the F1 ''standard message'' so 
there is no problem using Advanced SO2R also in a mixed mode contest.

===Radio polling===

The two ''Polling period'' text boxes determine how often DXLog requests information 
from the radio over the CAT interface.

DXLog sends three poll requests per period, i.e. with a setting of 300ms, one poll request is sent every 100ms.

For ICOM, which has a duplex CAT interface, you may experience slow or even missing response 
from the radio if the polling period is set too short since DXLog's polling will consume the entire 
capacity of the CI-V interface. With ICOM you also have a no-polling option called "Transceive" mode. 
You can find more about this feature [[Radios_and_Peripherals#ICOM|HERE]].

A list of recommended polling periods can be found below. Depending on radio model, a shorter interval 
may work and give a better user experience.

{| class="wikitable"
! CAT data rate [bps] !! Poll interval [ms]
|-
| 1200 || 1000
|-
| 2400 || 1000
|-
| 4800 || 800
|-
| 9600 || 600
|-
| 19200 || 400
|-
| 38400 || 200
|-
| 115200 || 100
|}

===PTT===

* PTT lead delay determines the time between PTT activation and start of transmission.
:This value is used both for COM-port keying and Winkey. However, microHAM keyers ignores
:this setting and requires you to set the PTT lead time in the microHAM device router.
* PTT tail delay determines the time between end of transmission and PTT deactivation
* PTT seq delay determines the time between activation of the four available PTT signals: PTT, PTT1, PTT2, and PTT3.

===Keying===

The keying settings are for all keying methods; COM-port, Printer port, or Winkey.

* Max speed sets the maximum speed in WPM.
* Min speed sets the minimum speed in WPM.
* Weight sets the weight of the keying. 50% is standard 3:1 keying. A higher number represents a heavier keying.
* Keying compensation adds to the durations of dits and dahs. Accepts both negative and positive values. Negative values have no effect on Winkey keying.
* Reduced keying stutter selects a keyer with improved immunity to disturbance from other applications running on the PC.

===Printer port configuration===

'''Important:''' Use of the printer port requires installation of a special driver, see the [[Installation#Prerequisites|Installation section]].

To use the parallel printer port (i.e. LPT port), it must be enabled by checking the "Enabled" 
box in the interface configuration panel's Printer port section.

Clicking the Setup opens its configuration panel.

Antenna selection with up to 16 different antennas is supported.

For multi-band antennas, the covered bands should be entered as a comma-separated list as in 
the example below. The operator friendly antenna name in the ''Description'' column is used in the 
''Antenna selector'' window.

'''Important:''' DXLog's band naming convention is to use wavelength up to the 10m band and 
above that, frequency. Band names are thus 160, 80, ..., 12, 10, 50, 144, ...

For more information on antenna selection, see the [[Menu_Windows#Antenna_selector_R1.2FR2|Antenna selector]] section.

The DVK related checkboxes are not implemented.

[[File:Dxl_printer_port_config.png]]

===Radio Setup===

If a COM port is configured as a radio interface, click on 'Setup' to open the Radio Setup form. 
In addition to the generic settings, several radio specific options are available. 

'''Important:''' Radio brand and model specific information can be found in the 
[[Radios_and_Peripherals|Radios and Peripherals]] section.

[[image:Radio_setup_form3.png]]

Radio configuration

* Radio
: Select your radio model. If it is not in the list, feel free to contact the development team.
: Note that many times a similar radio model can be successfully used.
: E.g. many Chinese QRP radios use the Kenwood protocol.

* Speed
: For best performance, use the highest available speed on your radio's CAT interface.
: If there is an "Auto" speed setting, do not use it. It is strongly advised to use a virtual USB CAT port, if available.
: Note that on modern ICOM radios it is necessary to "Unlink" the two CAT interfaces to achieve maximum speed.

* Bits, Parity, Stop
: Set according to the recommendations in your radio's documentation.

* ICOM CI-V address (hex)
: This is by default set to the selected ICOM radio model's factory setting.
: If you change the address in your radio's settings, this has to be set to the same value.

* Use radio's internal voice keyer
: Enables the use of the built-in digital voice keyer on supported radio models (E.g. Elecraft, later ICOM, some Yaesu).
: '''Important:''' If the Enable DVK option is checked in the Port Configuration panel,
: this setting has priority and the radio's DVK will not be used.
: '''Important:''' Due to limitations in the CAT command repertoire for some radios, DXLog may
: not be able to track the radio's transmit/receive state. You can use the
: <code>Options|Log|Show border on TX</code> menu option to determine if this is the case.
: If DXLog can not determine the radio's transmit state, this means 1) software interlock in a
: multi-radio setting will not work reliably with the radio's DVK, and 2) CQ autorepeat will not work.
: '''Important:''' Make sure the option Do not use PTT with voice keyer is checked for
: any device controlling the radio's PTT. If it is not, DXLog will assert the PTT at the start
: of DVK playback and then wait for it to be released, which obviously will never happen.

* Use reverse sideband on CW
: Uses the opposite sideband on CW. Mode is only enforced by DXLog at mode or band changes.

* Use CAT PTT command on Phone and Digital
: Uses a CAT command to switch between receive and transmit when using DXLog's internal voice
: keyer or digital modulator, instead of a COM-port or LPT signal. Only use this as a last
: resort when COM-port PTT is not available.
: Since the time to convey the command to the radio is not insignificant, you may need to increase
: the PTT lead time significantly to avoid hot-switching or lost first syllables.

* Use CAT PTT command on CW
: Uses a CAT command to switch between receive and transmit on CW, instead of a COM-port or LPT signal.
: Only use this option as a last resort when COM-port PTT is not available.
: Since the time to convey the command to the radio is not insignificant, you may need to increase
: the PTT lead time significantly to avoid hot-switching or lost leading dits.

* Use ICOM CI-V "Transceive" mode (reduced polling)
: An ICOM specific feature for which "CI-V Transceive" must be enabled on radio.
: For older ICOM radios with 19200bps or slower CI-V interfaces this option offers a much improved user experience.
: For modern ICOM radios the recommendation is to have this feature ''disabled'', an interface rate of 115200bps,
: "CI-V Transceive" enabled in the radio's set up menu, and polling rate of 100ms. USB Echo Back should be off.

* Control FlexRadio DAX on Phone
: Intended for remote operation with e.g. Maestro. Will temporarily enable DAX during voice keyer playback.

* Reinitialize port after switching from TX to RX
: Upon return to receive, reinitialize the COM port attached to that radio.
: '''Important:''' This is an emergency function and should only be used as a last
: resort when e.g., experiencing bad RF feedback at a DXpedition or a field day
: without access to ferrites.

* Do not poll radio during TX
: Stop polling radio (stop updating frequency, etc.) during transmit.
: May reduce RFI from the CAT interface.
: For e.g. Elecraft this is a recommended option.
: '''Important:''' For natural reasons, polling will only stop during transmit if DXLog is the origin of the PTT signal. The only exceptions are when using a [[microHAM_device_configuration|microHAM]] keyer with TX lock/unlock enabled or a Winkeyer with Detect paddle for interlock enabled.

The two above options may be useful in cases with RF feedback causing unwanted effects. 
They should however be considered as temporary solutions. RF feedback should be addressed at 
the source through proper grounding and ferrite chokes on cables.

* Use radio DATA mode for voice keyer playback
: Switches the radio to data mode during voice keyer playback.
: Intended for for radios that can only use an external modulation input in data modes.
: '''Important:''' Not supported on all radios.

* Always use radio DATA mode for any DIGI mode
: If your radio has a DATA mode for RTTY/PSK/AFSK, checking this option will force the DATA
: mode whenever a DIGI mode is selected.
: '''Important:''' Not supported on all radios.

* Use transverter offsets
: Opens up a configuration panel allowing setting per-band transverter offsets in kHz.

:[[image:Transverteroffsets.png|none|frame]]

* Spectrum

: Allows you to select a supported transceiver model or an external SDR for spectrum display.
: Currently Elecraft K4, SDRPlay, AirSpy and ExtIO type SDR receivers are supported.
: Clicking the ''Setup'' button will allow configuring it for RF or IF reception, etc.

Keying & Control

On many radios the CAT interface's unused hardware handshake signals can be used for keying and control.

In the drop-down menus you can chose to use between them being permanently on or off, CW keying or one 
of four possible PTT signals. The other options (Active radio etc.) are intended for controlling 
external radio controllers or keyers.

'''Important:''' Most Yaesu models have RTS hardware handshaking enabled from factory. Either set RTS 
to "Always on" or disable this function in the radio's settings (better).

'''Important:''' All CW keying via COM-port is disabled if a Winkey is active. PTT is however still active and 
should be disabled with Winkey 2.3 (or later) that has a high performance PTT built in.

The ''DSR/Footswitch'' input (pin 6 in an RS-232C connector) is an input with multiple, alternative uses. 
''PTT'' means that the pin will assert DXLog's PTT. ''R1/R2 toggle'' means that a press on the footswitch will 
switch focus to the other radio. ''R1 on/R2 off'' means that pressing the footswitch will focus radio 1. 
''R1 off/R2 on'' means that pressing the footswitch will focus radio 2. ''TX Rec'' means record to the preselected 
voice keyer memory. ''Escape'' makes pressing the footswitch equivalent to pressing the Escape key. 
The function of ''RX Wait'' is unclear.

* Do not use PTT with voice keyer

: '''Important:''' If you use the radio's built in voice keyer, make sure to check this box
: on the COM port controlling your radio's PTT to avoid a self-locking PTT loop and to make
: sure the transmitter's audio source is not forced to be the microphone.

: If PTT is not asserted when playing back, you may need to uncheck it but this is extremely rare.

==Configure antenna server==

This configuration is for a special antenna hardware used at a few, select contest stations.

[[image:antserv.png|none|frame]]

==Interface specific options==
===Allow different TX/RX antenna===

If checked this option allows different selection for TX and RX antenna with Operating->Antenna selection menu. 

===Use decoder frequency correction===

If checked and audio decoder is used in a digital mode contest, audio frequency in decoder will be 
added or subtracted to the frequency reported by the radio to get effective operating frequency. 
When using a digital mode for which the radio displays the effective operating frequency, such 
as FSK RTTY or FT8, this option should be disabled.

For digital modes when this is not the case, e.g., AFSK RTTY, this option should be enabled.

===Block message transmission if another radio is on the same band===

If checked the Transmitter connected to this DXLog will have it's TX disabled if another radio on the network is on the same band.

===Dual receiver radio (Use split in SO2V)===

If checked (and the technique selected is SO2V) DXLog will send set the radio in split mode when focusing VFO B.

Select this if you are using a radio with a subreceiver, such as Yaesu FTDX101D, ICOM IC-7610, or IC-7851.

===Use different bandmap background for active radio ===

If checked, the background color of radio 1 or radio 2 bandmap will be changed when the radio becomes active. 
'''Important:''' the color used in this mode needs to be selected by using the Colors menu in the bandmap right click menu. 
By default it is set to the same color as the normal background.

=== Automatically open/close digital window on mode change ===

If checked, the digital window for the active radio will be opened when a digital mode is selected. 
If a non-digital mode is selected and the digital window is open, it will be closed. Note that the 
contest configuration must allow both digital and non-digital modes in the same time period (mixed mode). 
The digital window must be configured properly in the RTTY configuration form.

=== Sync radio 1/2 frequency & mode ===

If checked, synchronizes the frequency and mode of physical radio 1 and 2. Does not synchronize VFO in SO2V. 
This option requires radio auto reporting (e.g., ICOM "Transceive") to be disabled or oscillation will occur.

===Band change keys affect both VFO===

With this option checked, <code>[Alt][F1]</code> and <code>[Alt][F2]</code> will change the band of both VFO.

===Select first available antenna on band change ===

If checked, selects the first available antenna on band change.

===Partner and S&P selection===

Controls the function of the [[Menu_Windows#Partner|Partner window]] and [[Menu_Windows#Search_and_Pounce|S&P window]].

==RTTY configuration==

Settings for RTTY decoder types and paths to decoders.

[[File:FrmRTTYConfig.png| 600px]]

Up to three decoders can be used per radio. Note that the decoder for each radio '''must be in a separate user-writable directory''' on your PC.

* '''MMVARI Multimode''' - For MMVARI select MMVARI from the radio buttons 

* '''MMTTY RTTY engine''' - For MMTTY go to http://hamsoft.ca/pages/mmtty.php - download MMTTY engine and extract into a user-writable directory 

* '''2Tone RTTY engine''' - For 2TONE go to http://www.rttycontesting.com/downloads/2tone/ - download the latest 2tone version and extract into a user-writable directory 

* '''GRITTY RTTY decoder''' - For GRITTY go to http://dxatlas.com/Gritty/Files/Gritty.zip and extract into a user-writable directory. GRITTY is run separately from DXLog. Edit its .ini file to set TCP port, RTTY tones, etc. 

* '''EXTFSK, EXTFSK64, TinyFSK''' - For these FSK plugins, go to https://www.qsl.net/j/ja7ude/extfsk/indexe.html and https://www.qsl.net/ja7ude/tinyfsk/index.html. To use any of them with MMTTY, place the .fsk file in the MMTTY directory/ies. To use them with MMVARI, place them in a user-writable directory.

Set the radio buttons for the correct RTTY decoder engine. 
Set the paths to the relevant RTTY decoder engines and MMVARI FSK plugins. 
Set tick box options as appropriate for your operation.

==microHAM device configuration==

Settings for integration with microHAM keyers and SO2R controllers 

You can find more general tips about using microHAM products with DXLog 
in the [[Radios_and_Peripherals#microHAM|Radios and Peripherals section]].

[[image:Mk2r-new9.png|none|frame]]

* '''Enable microHAM device DVK
: Enables the use of the microHAM devices's DVK instead of DXLog's built in DVK.
: Supported for microHAM DKII, MKII, MKIII, MK2R, MK2R+, and u2R.
: '''Important:''' DXLog's own DVK has priority and must thus not be enabled.

* '''Footswitch is PTT
: Enables the use of the microHAM devices's footswitch input for PTT.
: On devices with more than one footswitch/PTT input, DXLog regards them as one.
: No longer optional as of DXLog version 2.4.17 due to removal of this option in microHAM's firmware.

* '''Enable TX lock/unlock
: Enables control of the hardware transmit locking/unlocking built into the device.
: Checking this will enable the software interlock in DXLog to act on all possible means
: of transmission: Message transmission, PTT, Footswitch, and paddle.
: This function is intended for ''multi-station interlock'' but can have other uses since with
: this option checked, keyer PTT, Winkey BKIN, and footswitch status are recognized
: by DXLog and is available e.g. for scripting or transmit/receive antenna selection.
: When using a footswitch with this function it should be connected to the microHAM device.
: Using a COM-port footswitch may cause race conditions since DXLog will be exposed
: to two separate PTT signals with a unpredictable separation in time.
: '''Important''': Winkey BKIN is only recognized with microHAM Device Router 9.3.0 or later.

* '''Enable SW PTT
: Enables the use of software PTT. With this enabled, DXLog will control the devices's
: software PTT via the control interface. Can replace COM-port PTT but comes with
: latency so e.g. PTT lead time may need to be increased.
: Should only be used as last resort when hardware PTT is not possible.

* '''Dual radio device
: Selects single or dual radio microHAM device.
: Should be checked for dual radio devices such as microHAM MK2R, MK2R+, and u2R.
: Should be unchecked for single radio devices, i.e. microHAM DIGI KEYER and micro KEYER, regardless of model.

* '''Operator logon selects DVK bank
: With this option checked, logging on (using <code>[Ctrl][O]</code> or <tt>OPON</tt>) will select the DVK message
: bank for this callsign. If there is no such memory bank defined, it is created.
: With this option unchecked, all operators will use the same memory bank.
: Be aware that with this option checked and no operator logged on, the common memory bank will be used.

* '''Device without CAT interface
: With this option checked, DXLog will force the operating mode of the device.
: This is required for devices such as u2R which lacks a CAT interface and thus can not determine this by itself.
: It can also be used for more advanced devices, such as MK2R+, if its CAT interface is not used.
: Works for both single and dual radio devices.
: '''Important:''' In digital modes DXLog only sends a mode command to the device at startup. This is because radios
: need to be configured differently depending on model and digital mode; PKT, USB-D, DIG, etc.
: To force mode settings onto the microHAM device, type the relevant mode in the entry line and press <code>[Enter]</code>.

* '''RTTY is FSK
: This option is only active for microHAM devices without CAT.
: When checked, it will force the device into FSK mode in RTTY.

* '''Digital is VOICE
: This option should be checked if the device is a microHAM u2R which only supports CW, VOICE, and FSK.
: With this option checked, the default mode for digital operation is VOICE.

* '''Radio 1 RX, Radio 1 TX, Radio 2 RX, and Radio 2 TX tabs'''
: Each tab defines a rule for the two 4-bit BCD outputs on the ACC connector on the back side of the MK2R, MK2R+, or u2R.
: The two ACC outputs are typically used for antenna or PA band selection but can have other uses too.
: The location of the checked box is translated into a 4 bit binary pattern.
: '''Important:''' Band names are 160-10, 50, 70, 144, 432 etc.
: '''Important:''' This means only one box can be checked per row.
: Please refer to the latest microHAM documentation for possible changes to this rule.
: '''Important:''' The coding is not BCD. Check mark location number 1 means 0000, 2 = 0001, ... 13 = 1100, 14 = 1101, 15 = 1110, and 16 means 1111.
: The bit pattern in the Radio 1 RX and Radio 1 TX tabs control the RADIO 1 ACC port and the Radio 2 tabs control the RADIO 2 ACC port.
: The configuration allows up to 25 different band/antenna associations.
: Having multiple antennas on the same band is supported.
: For multi-band antennas you need to include a band line for each band it covers.
: The 60m band has was added in release 2.4.15 so if not visible, clicking RESET will make it appear.
: For information on antenna selection, see the [[Menu_Windows#Antenna_selector_R1.2FR2|Antenna selector]] section.

: '''Important:''' To enable the use of different RX and TX antennas, <code>Options|Interface specific options|Allow different TX/RX antenna</code>
: must be checked. The keyer's respective ACC outputs must also be configured for microHAM protocol control.
: This is done in the ACC tab in the microHAM's Device Router set up as shown below.

:[[image:Microhamrouteracc.png|none|frame]]

==OTRSP device configuration==

* '''Enable OTRSP device DVK
: Enables the use of a digital voice keyer in the OTRSP device.
: Supports recording and playback of up to nine messages, just like DXLog's built-in voice keyer.

* '''Radio 1 and Radio 2 tabs'''
: Each tab defines a selection of states for up to four four-bit Aux outputs. Unlike microHAM, any bit pattern is allowed.
: Each state (i.e. line) associates a band with an antenna usable on that band.
: The configuration allows up to 25 different band/antenna associations.
: Each group of four pins is associated with an Aux output, as listed in the upper left of the panel.
: It is possible to have several antennas for the same band.
: A multi-band antenna needs to have one band-line for each band it covers.
: The bit pattern presented to the Aux outputs is the combination (logical OR) of the currently selected antenna for each radio.
: This means that if Aux 1 is used to control the antenna for radio 1 and Aux 2 is used to control the antenna for
: radio 2, columns 5 through 8 must be unchecked for radio 1 and columns 1 through 4 must be unchecked for radio 2.
: C.f. the example configurations below.
: The 60m band has was added in release 2.4.17 so if not visible, clicking RESET will make it appear.
: '''Important:''' Band names are 160-10, 50, 70, 144, 432 etc.
: '''Important:''' The use of different antennas for transmission and reception is not supported.
: For more information on antenna selection, see the [[Menu_Windows#Antenna_selector_R1.2FR2|Antenna selector]] section.

[[image:OTRSP Setup radio 1.png|none|frame]]

[[image:OTRSP Setup radio 2.png|none|frame]]

==Winkey configuration==

Configure the WinKey properties 
Text command : <code>WKSETUP</code> or <code>WKEY</code>

[[image:winkeyconfig2.png|none|frame]]

'''Important:''' If you are using a microHAM keyer, the below settings will only have effect if 
the Allow logger control option is checked on the USB device router's <tt>CW/Winkey</tt> tab.

'''Important:''' For Winkey 2.3 or later, PTT is managed correctly by the Winkey chip and DXLog PTT should not be used. 
For earlier Winkey, COM port PTT may be required to keep PTT from dropping between transmitted words.

* Keyer mode:
** Iambic A - Curtis A iambic timing
** Iambic B - Curtis B iambic timing
** Ultimatic - Non iambic mode
** Dit
** Dah
** Bug (semi-automatic) - WinKey makes the dits and you make the dahs. Vibroplex style.
: In either Iambic mode, alternating dits and dahs are sent while both paddles are held closed.
: In Iambic mode B, which emulates the legendary Accukeyer, an extra alternate dit or dah is sent after both paddles are released.
: In Ultimatic mode, when both paddles are pressed, the keyer will send a continuous stream of whichever paddle was last pressed.

* Reverse - Reverses the dit/dah paddles (e.g. for keying with the left hand)
* Autospace - If you pause for more than one dit time between a dit or dah, Winkey will interpret this as a letter-space and will not send the next dit or dah until a full letter-space time (3 dits) has passed

* Hang time - Sets PTT hang time for paddle transmission

* Pot controls
** Nothing: Winkey speed knob/potentiometer has no action
** Paddle only: Winkey speed knob affects only paddle CW speed (Recommended)
** Paddle and DXLog : Winkey speed knob changes both DXLog and paddle CW speed

* Two wire: Makes the Winkey assume it is controlled by a 2-wire potentiometer. Rarely used.

* PTT - Enable PTT control from Winkey. Preferably disabled on WKmini. Be aware that this setting is ignored for some integrated Winkey chips, such as in microHAM devices.
* Use two Outputs - WinKey pin 5 keys a second radio. Enable with WKmini to key tip of connector.

* Sidetone - Disables or sets the sidetone frequency on keyers with speaker .

* Extra buffering - Transmits N+1 characters at the time to WinKey. May improve performance with WinKey clones that do not respond timely or with remote operation when using Winkey keying over an internet link. Any number above zero will reduce ability to edit sent text while transmitting.

* Detect paddle for interlock - Makes DXLog detect paddle transmission just as e.g, a footswitch to block other stations if interlock is used
* SO2R Mini extension - Activates protocol extensions for controlling an [https://nn1c.org/so2r/ SO2R Mini].

==MP3 configuration==

Sets the configuration for the MP3 encoder used by the [[Menu_Windows#Contest_Recorder|Contest Recorder]] window.

Player is the output device, normally your PC speaker.

Recorder is the recording device, e.g. the audio device in your SO2R controller or the built-in soundcard in your radio.

Recordings are made in stereo, so both radio 1 and radio 2 (or the main and sub receiver) can be recorded.

The sample rate and coding rate can be set at different values. For normal purposes 8000Hz sample rate and 
24kbps coding rate is sufficient and consumes the least disk space.

[[image:mp3config2.png|none|frame]]

==Rotator configuration==

DXLog supports rotator control using UDP communications to PstRotatorAz by YO3DMU and the EA4TX rotator controller.

'''Important: Do not confuse PstRotatorAz with PstRotator.'''

DXLog also offers a generic UDP broadcast based rotor communication, described [[Additional_Information#Antenna_direction|here]]. This does not 
require any configuration besides enabling it in <code>Options|Broadcast|Antenna direction</code> and selecting the 
desired port in the network configuration panel.

The configuration steps for PstRotatorAz and EA4TX are to be fond below.

You may also find [[http://dxlog.net/sw/files/utilities/DXLog%20rotator%20configuration_v2.pdf this guide by F8GHE]] useful.

[[image:PSTRotator DXLog config3.png]]

Check the "Enable Rotator communication" box at the top of the form.

Enter the required data in each column. Use the Add, Edit, and Delete buttons as required. The columns are:

* Band
: Bandname(s) for which this rotator is active. In meters down to 10, thereafter in Megahertz.
: Comma-separated list if several.
: Example: 15,12,10,50,144

* Ant #
: '''Very important:''' Set to 0 (meaning any antenna) if not using the special Antenna server functionality.
: The number of the antenna for this band turned by this rotator, beginning at 1.
: Antennas are numbered in the order shown on the <t>Radio/Ant Status Window.

* IP Address
: If you are running PstRotatorAz or EA4TX on the same machine as DXLog,
: enter 127.0.0.1. Otherwise enter the IP address of the rotator control server.

* Port
: The UDP port used to communicate with the rotator interface. Normally PstRotatorAz uses
: 12040 for the first rotator, 12042 for the second, etc. However, any port that is free can be used.
: '''Important:''' PstRotatorAz uses two ports, N and N+1, so when configuring multiple rotators, do not use subsequent port numbers.
: Write down the ports used as they are needed for PstRotatorAz or EA4TX configuration.

* Radio
: Determines which radio controls the rototator. Set to zero ("0") for any radio.

* Send freq
: Check this box if you need the radio frequency to be sent to PstRotatorAz.

Select the rotator software type from the drop down list, currently either PstRotatorAz or EA4TX

When completed, press OK.

To configure PstRotatorAz, you may need to refer to the PstRotatorAz manual. Here are the basic steps:

From the PstRotatorAz menu bar, Select <code>Setup|Trackers Setup|DXLog.net/Swisslog</code>.

[[image:Pstrotatoraz-setup.jpg]]

The Setup displayed will be:

[[image:Rotator_tracker_setup_DXLog.png]]

Enter the port number used for this rotator in the Ethernet box. Select 'Azimuth' or 'Callsign' in 
the "Tracking by" box based on preference. Click Save Settings.

Select <code>Tracker|DXLog.net</code> from the PstRotatorAz menu bar.

In the main display, select 'Tracking' from the Mode box. Depending on the view you have selected, you may need to select 
View -> Full View to see the Mode box. The following shows the location of the Mode box in PstRotatorAz:

[[image:PSTRotator_tracking_mode.png]]

If you have more than one rotator, repeat the steps on each instance of PstRotatorAz, using the appropriate UDP Port number. 
See the PstRotatorAz documentation to enable multiple instances of PstRotatorAz.

Once you have everything configured, return to DXLog. Ensure you are on the appropriate band (and the proper antenna selected). 
Enter a callsign or an azimuth value into the callsign field. Press <code>[Ctrl][F12]</code>. DXLog will show the value sent on 
the status line, and the rotator should rotate to the selected azimuth.

Enter a callsign and press <code>[Alt][F12]</code>. Rotator will turn to the long path azimuth.

This completes Rotator configuration. '''Important:''' You may have to restart both DXLog and PSTRotatorAz for correct operation.

==Configure network==
This panel allows configuration of network addresses and identity.

Text command: <code>NETCONFIG</code>

[[image: Network_parameters_form4.png|none|frame]]

* ''Station ID''
: The name/identity of the station used in DXLog networking.
: The name is used for e.g. software interlock, gab messaging, and multiplier passing.
: It is recommended to use explanatory station names such as "INBAND", "RUN1", etc.
: Station names including dash ("-") do not work with macros since dash in a macro is a separator and CW speed reduction.

* ''UDP networking for multiple stations'' (checkbox) Enables UDB based networking. DXLog can use both broadcast-based UDP networking and client-server based networking. Note that UDP is a protocol without confirmation or retransmission and thus vulnerable to packet loss. '''Important:''' Wi-Fi networking is not recommended for any contest station but if used, client-server networking should be used.
** ''UDP network parameters'' IP address and port information for UDP networking. The ''Default'' button will enter the DXLog default parameters. '''Important:''' On computers with multiple active network adapters, the broadcast IP address may have to be entered manually for correct operation.

* ''Act as network server'' (checkbox) Enables client-server based networking with this station as server. '''Important:''' Only one server is allowed on the network.
** ''Server parameters'' The IP address of the PC and the selected port.

* ''No spots via client/server'' (checkbox) Spots will only be forwarded inside the peer-to-peer network and not via client-server connections. Valuable feature when e.g., networking over WAN.

* ''Connect to network server'' (checkbox) Enables client-server based networking with this station as a client.
** ''Client parameters'' IP address and port of the server. This entry box supports both numeric addresses as well as URL via DNS lookup.

* ''Other parameters''
:* ''Network timeout (sec)'': timeout value for network connections.

:* ''Time synchronization server'' (checkbox)
:: Makes the current station the master for station time synchronization.
:: '''Only one station per network should have this option checked''' and all other
:: stations '''must run DXLog as administrator''' to allow adjustment of the computer's time.
:: To run DXLog as administrator, right-click the desktop icon and select the option.

:* ''Serial number server'' (checkbox)
:: Enables the serial number server which allows multiple stations/radios to use serial numbers in chronological
:: sequence for contests that require this, e.g. CQ WPX, in spite of interleaved QSO.
:: '''No more than one station per network may have this option checked.''' (Usually the main run station)
:: Note: All stations must have <code>Options|Networking|Use number server</code> checked to use the server.
:: (Except support stations as these stations do not log).
:: The number server must be used also for SO2R in contests that requires chronological serial numbers.
:: More information can be found in the [[Additional_Information#Using_a_number_server|section on using a number server]].

* ''Live score UDP broadcast''
: IP address and and port number for broadcast of live score information.

* ''DX cluster spots UDP broadcast''
: Up to three IP addresses and port numbers can be specified, separated by space.
: For more information, see [[Additional Information#UDP broadcast|UDP broadcast]].

* ''Radio information UDP broadcast''
: Up to three IP addresses and port numbers can be specified, separated by space.
: For more information, see [[Additional Information#UDP broadcast|UDP broadcast]].

* ''Antenna direction UDP broadcast''
: Up to three IP addresses and port numbers can be specified, separated by space.
: For more information, see [[Additional Information#UDP broadcast|UDP broadcast]].

* ''QSOs UDP broadcast''
: Up to three IP addresses and port numbers can be specified, separated by space.
: For more information, see [[Additional Information#UDP broadcast|UDP broadcast]].

* ''UDP broadcast listener''
: Up to three IP addresses and port numbers can be specified, separated by space.
: For more information, see [[Additional Information#UDP broadcast|UDP broadcast]].

==Enable network==

Text command: <code>NETON</code> or <code>NET</code> and <code>NETOFF</code> or <code>NONET</code>

Enables or disables station networking.

Important: If you intend to use the number server in a multi-station setting it is not sufficient to only enable the network. 
A network interface (UDP or client/server TCP) must also be enabled in the network configuration panel (see above).

[[image:neton.png]]

==Networking==

 

[[image:Options_networking_menu2.png]]

===Synchronize standard messages===

Force the standard (CW/Digital) messages on this station onto all other stations on the network.

===Synchronize log===

Immediately starts the synchronization of logs between networked stations instead of waiting for periodical synchronization. 
May be used to "catch up" a rebooted station more quickly.

===Block logging on this station===

When checked, QSO cannot be added to the log at this PC.

Instead, the callsign entered into the log entry callsign field will be added to the bandmap and the log entry callsign field will be cleared.

This option is usually used for Partner mode or operator training.

===Use serial number server===

This option, when selected, enables the use of a number server. The purpose of a number server 
is to allow all networked stations (or both radios in case of SO2R) to use serial numbers 
in chronological order. The most well known contest with this requirement is CQ WPX.

Only one DXLog instance in a network can be the number server, all other DXLog must have this option unchecked.

When checked, the DXLog number server will be used to determine/reserve the next serial number. 
The reservation of a serial number can either be done with via menu options <code>Tools|Data entry|Space key reserves serial number</code> 
and <code>Tools|Data entry|Insert and F2 messages reserve serial number</code> or by adding <tt>$RESERVENR</tt> 
macro to the F2 RUN and S&P messages.

Typically the space option is preferred for phone whereas the macro option is preferred for CW.

<code>Options|Networking|Use serial number server</code> must be checked on all stations on the network that require 
the use of serial numbers (i.e. all stations logging QSO)

If number reservation is successful, the user will be notified in the status bar at the bottom of the main window 
and the serial number in the QSO entry line will change color (Default red).

If a number is reserved but the QSO is not made, a number reservation can be revoked by wiping the entry line. 
(<code>[Alt][W]</code> or <code>[F11]</code>).

'''Important:''' if you are using the number server on a single computer (for SO2R) you need to enable the network 
but you do not need to enable any networking interfaces in the Network configuration panel. You only need to check 
the ''Serial number server'' box.

===Block logging if serial number reservation is unsuccessful===

When using the serial number server and this option is checked, logging will be blocked 
until a serial number is successfully retrieved from the number server.

When a number server is used and the reservation process has started, DXLog will show the active 
QSO number as 000 until a serial number has been successfully reserved or the reservation is canceled.

===Block standard messages if band/mode change rule is broken===

When operating a contest in a multi-station environment, this option will prevent the use of 
the standard F-key messages if the contest's band/mode change rule is broken. 
Keyboard CW (<code>[Alt][K]</code>) and additional (<code>[Ctrl][Alt][F#]</code>) messages are not affected. 
Blocking all messages is primitive and better control is offered by using the <tt>VIOLATION</tt> 
macro conditional in relevant messages.

===Show different active QSO line color during wait status===

When operating a contest in a Multi transceiver environment, this option will change the color of 
the active log so entry line when the band change rule is violated. 
The use of this option is recommended.

* Example: You make QSO on the multiplier radio on 40m band at 00:00Z.
: In that case, you have to stay with multiplier station on 40m until 00:10Z when you are then allowed
: to QSY to other band with the multiplier station.
: If you do it earlier, or you have multiple multiplier stations, each of them will see the QSO line in
: a different color until the 10 minutes has expired. By default the color is red, until last
: minute when it changes to yellow... and after that it reverts back to the normal background
: color of the logging screen.

In multi/single environment it is very useful for each operator to see if a QSO is allowed on 
that band or not. It's easy, you just have to look at the screen, and if the log entry line is 
red in color, you are not allowed to make a QSO. The timers are also visible in the ''Network status''
and ''Band change info'' windows.

===Block standard messages if no operator is logged on===

If checked, F-key messages are disabled if there is no logged on operator.

===Space key updates QSY Wizard===

If checked, ''HamCAP'' will be automatically invoked when <code>[Space]</code> is pressed 
and QSY information will be shown in the ''QSY wizard'' window

===Enable interlock===

Text command: <code>ILOCK</code> and <code>ILOCKON</code> enables interlock 
Text command: <code>NOILOCK</code> and <code>ILOCKOFF</code> disables interlock 

When this option is checked, software interlock is active. 
Transmission is only possible if the other networked DXLog stations allow it.

When enabled, interlock status is shown as a banner in the ''Operating info'' window.

The ''Radio Status'' window illustrates blocking status through its background color. 
Green means successful transmission, yellow means an interruptible block, and red means 
an uninterruptable block.

[[image:inbandblocking.png]]
[[image:inbandblocked.png]]
[[image:Inbandblockinginterruptable.png]]

===Configure interlock===

Text command: <code>ILOCKC</code> or <code>ILOCKCONFIG</code>

[[image:interlock_options.png|none|frame]]

"Status list" refers to the content of the ''Network status'' window.

===Interlock priority options===

Note that the below options are only available when software interlock is activated.

* '''First one wins'''
: No transmissions are interruptible. The station that first starts
: to transmit is always allowed to complete its transmission.

* '''Last one wins'''
: All transmissions are interruptible. All stations can always
: interrupt the transmission of another station. (Not recommended.)

* '''Last one wins if msg not'''
: All but a defined set of messages are interruptible.

* '''Last one wins if msg is'''
: Only a defined set of messages are interruptible.

* '''If msg/is not selection'''
: Selectable list of messages for more granular control of last one wins strategies.

Although it is considered a good practice to use symmetrical blocking strategies, i.e. having 
identical settings in each participating station, it is possible to have different settings in each station. 
If experimenting with this, keep in mind that the interlock strategy settings refer to the 
behavior of blocked station, not the blocking station.

'''Important:''' For software interlock to work on Phone, a external PTT recognized by DXLog must be used. 
The by far simplest solution is to use a footswitch connected to a microHAM device. 
See the [[Menu_Options#microHAM_device_configuration|microHAM configuration]] section for more details. 
It is also possible to connect a footswitch directly to the computer's RS-232 port, providing it has one. 
How to do this is described [[Additional_Information#Connecting_a_footswitch|HERE]].

[[image:k3_settings2.png|400px]]
 

===Announce QSO progress status in interlock===

Show QSO progress status ("CQ", "QSO", "EXCHANGE") instead of "MAN" '''on the blocked station''' when 
asserting PTT on blocking station.

The rule for determining the status is:
* If the call sign field is empty, the block request reason message is "CQ"
* If the call sign field is not empty and focused, the block request reason message is "QSO"
* If the call sign field is not empty and not focused, the block request reason message is "EXCHANGE"

Note that this setting controls the message sent by the blocking station so it needs to be set on 
all interlocked stations for proper function.

===Optimistic interlock===

Applies to software interlock. If a "blocking allowed" confirmation is not received from all 
stations requested before timeout, assume that all relevant stations are blocked and start 
transmission.

===Allow other stations to abort sending===

Checking this option allows other relevant stations (e.g., an inband station) 
to interrupt your transmission.

<code>[Shift][Esc]</code> aborts transmission on other stations.

The key works differently when software interlock is enabled and when it is not.

* With software interlock enabled, stations matching the interlock criteria will be interrupted.

* With software interlock disabled, stations on the same band for multi-multi and of
:the same type for other operations will be interruped.

Also when this option is disabled, the operator may be informed that another station is trying to abort 
the transmission. This notification can however be disabled, see [[Menu_Options#Log|here]] for more information.

==Broadcast==

For details, see the [[Additional_Information#UDP_broadcast|UDP broadcast section]]

==DX cluster==

DX cluster telnet settings and options 
[[image:Dxclustermenu4.png]] 

===Spot handling policy===

Controls how a new incoming spot (local or cluster) is handled.
Three options are available that differ in terms of what existing spots
are removed before the new spot is added. The result is sensitive to
the spot bandwidth (as set in bandmap Properties) centered on the new spot's frequency:

* '''Standard''' - Remove any existing spot with same band, mode, and call as the new spot;
: and any existing spots within the spot bandwidth of the new spot.
: Keeps a relatively uncluttered spot display, with only the most recent spot shown within the
: spot bandwidth of any frequency on the bandmap.
: Pro: Only shows the most recent spot on each frequency.
: Con: In Run you will not be warned if a station you can not hear, e.g. in your skip zone, is calling CQ on your frequency.
: Con: In a busy, global contest, the band map content can be quite volatile.

* '''Complete''' - Remove any existing spot with same band, mode, and call as the new spot;
: and any existing already-worked ("dupe") spots within the spot bandwidth of the new spot.
: Provides a more complete spot display, allowing displayed non-worked spots to be
: within the spot bandwidth of each other.
: Pro: Provides a complete picture with no risk of missing valuable spots.
: Con: None, really.

* '''None''' - All spots are kept. Can quickly result in a very cluttered
: bandmap with many duplicate spots. Recommended only for testing purposes.
: Resembles "Bandmap type: Multiplier" option prior to release 2.4.3.

===Edit connection list===

Add/remove/edit DX Cluster information.

[[image:DXC_list.png]]

To set a default DX cluster connection, select the connection from the list and click the '''Default''' button.

When editing or adding a new connection, give the connection a meaningful name and enter the address, 
either an IP address or a domain name plus the access port for the telnet connection.

[[image:DXC_def.png]]

The DX Cluster connection list can also be bulk edited by loading the file dxclist.txt in a regular text editor. 
The dxclist.txt file is stored in C:\Program Files (x86)\DXLog\Database and should be overwritten with the latest file available. 
DXLog will automatically use this latest file upon running after the file has been updated.

The dxclist.txt file is formatted as follows:

<code>Display Name=internet_address;port_no;Login_Required_(Yes/No);;</code>

E.g.:

<code>W9PA - No Skimmer=dxc.w9pa.net;23;YES;; *W9PA=dxc.w9pa.net;7373;YES;; W9PA - FT8 Only=dxc.w9pa.net;7374;YES;;</code>

A leading Asterisk "*" before the display name marks the default connection.

===Reset connection list===

Resets the connection list content to its default content. Deletes user additions and changes.

===Reconnect default cluster node at start===

Automatically re-establish connection to DX Cluster on loading or creating a new log.

===Default comment for posted spots===

A default comment when submitting spots to the cluster with <code>Alt-F3</code> or S&P auto-spotting. 
This is typically the name of the contest, such as "CQWW" or "WAE".

===Add exchange to posted spots===

Adds the first part of the contest exchange when submitting spots to the cluster, either manually or automatically. 
This option is only active for contests with where the first part of the exchange does not change, such as e.g. county or zone.

===Self spot comment===

Comment added to self spots. Defaults to the name of the current contest.

===Send spots to SmartSDR===

Sends spots via UDP broadcast for display in other software such as SmartSDR. 
Information on configuration can be found [[Menu_Options#Configure_network|HERE]].

===Don't send ineligible spots to SmartSDR===

Prevents sending spots ineligible for the contest over UDP and to SmartSDR.

===Show talk messages from cluster in GAB window===

Cluster talk messages will be shown in the GAB window.


===Don't show logged call in bandmap in Run===

The default behavior of DXLog is to create a local spot at the current frequency, applying the current 
spot processing policy for erasing adjacent dupes, etc.

Checking this option will prevent this and therefore also give the opportunity to e.g. notice if someone 
else is spotted on your Run frequency.

Note that this setting does not prevent the creation of spots in the bandmap by other, networked stations.

==HamCAP==

HamCAP and VOACAP must be installed for these options to work.

HamCAP is a HF propagation prediction tool and is useful for contest strategy and watching for 
possible openings for multipliers. It relies on VOACAP which operates silently in the background.

HamCAP can be downloaded from http://www.dxatlas.com/Download.asp 
Make sure to use the most recent SSN database. It can be downloaded from the same location.

VOACAP can be downloaded from http://www.greg-hand.com

[[image:hamcap_options.png]]

[[image:hamcapprop.png]]

HamCAP options are:

* '''In background''' - prevents HamCAP from grabbing focus, also when on top.
* '''Always on top''' - makes sure HamCAP is always visible, also in front of DXLog.
* '''Tab''' - controls which HamCAP tab is displayed when invoked from DXLog.

To enable automatic HamCAP prediction by pressing <code>[Space]</code> check <code>Options|Networking|Space key updates QSY Wizard</code>. 

With this option checked, pressing <code>[Space]</code> with a call sign in the entry field will trigger a propagation forecast.

==Data files==
This menu is used to update the SCP and Country files from the internet and set Extra 
info and exchange guessing data base options.

[[image:Options_data_files_menu.png]]

'''It is recommended to update the Country Files and SCP database before every contest'''

===Country files===

Text command: <code>CTYFILES</code> or <code>COUNTRYFILES</code> 
Opens the panel below:

[[File:Dxl_country_files.png]]

Allows you to choose which of the country files you will use for calculation of DXCC, CQ zone, 
ITU zone etc. in the currently active contest. 

It is recommended to always use CTY_WT_MOD.DAT which will provide you with the most 
accurate information.

Click on '''Download''' to update the selected country file from the internet and click OK.

After clicking OK, DXLog will ask you to reload the currently active log in order to 
refresh all calculations. This can easily be done using the text command RELOADNOW.

===Update Super Check Partial database===

Downloads the latest version of the super check partials MASTER.SCP database.

On successful download and update you will be asked to restart DXLog, which 
is easily done with the text command <tt>RELOADNOW</tt>.

:[[image:Master.png]]

===Update prefill database from log===

Updates your local prefill database with information from the currently opened log. 
Missing information will be added and prefill data that was modified when logging will be changed.

Please note that all comments in the original data base file (lines starting with # or !) are lost in this process. 
All three types of databases, ''TXT'', ''CSV'', and ''DTB'' can be updated.

'''VERY IMPORTANT:''' Does not work for "mixed population" contests where not all stations have a fixed exchange.

===Extra info plugins | HamQTH===

Enable or Disable, If enabled, a valid Username and Password must be set in the configuration panel. 
'''Important:''' If your password contains "strange" characters such as ?@#$%& or non-latin letters, the service may not recognize your login.

[[image:hamQTHconf3.png|none|frame]]

===Extra info plugins | QRZ===

Enable or Disable, If enabled, a valid Username and Password must be set in the configuration panel.

'''Important:''' If your password contains "strange" characters such as ?@#$%& or non-latin letters, the service may not recognize your login.

'''Important:''' Requires an active XML subscription with qrz.com.

For more information, see https://www.qrz.com/page/xml_data.html

[[image:QRZconf2.png|none|frame]]

===Prefill database settings===
 
[[image:Prefill database settings2.png|none|frame]]

One or more prefill database(s) may be configured using this panel. 
All information entered here will '''override''' the default database settings 
in the contest configuration. However, when a new log file is created, the default 
settings from the contest configuration file will be used.

To configure the use of a database file, click ''Browse'' and select the database file. 
The standard location for database files is <tt>%appdata%\DXLog.net\Database</tt>. 
Select the database file type using the pull down menu. 
Standard DXLog prefill database files are type ''TXT''. N1MM Logger+ database files are type ''CSV'', and 
WinTest database files are type ''DTB''. Be careful to chose the correct file type.

TXT and CSV files typically have a .TXT filename ending. DTB files typically have a .DTB filename ending.

DXLog supports up to four contest exchange elements. Their name, from left to right, are RCVD, RECINFO, 
RECINFO2, and RECINFO3.

You map an information element in a prefill data base file to an exchange element by specifying its number. 
The first information element following the callsign is number 1, the next is number 2, and so on.

* The line format in a DXLog prefill data base file is:
:<code>callsign1;callsign2;callsign3...=information1;information2;information3...</code>

* The line format in a N1MM Logger+ prefill data base file is:
:<code>callsign,information1,information2,information3,information4</code>

* The format for a standard Win-Test prefill data base file is binary and not possible to easily edit or view.

To not use data for a selected exchange element from a database file, set its number to -1. 
This can be relevant in the case of having several data base files, each contributing to individual exchange elements. 
For example, one data base file for grid locator and another for operator name or state. 
In the example above the first exchange element (name) is collected from information element 
number 1 in the CWOps data basefile, whereas the second exchange element (state) is collected 
from information element number 2 in the NAQP database.

'''Special feature for timed prefill database files''': Some contests use age (license, birth, etc.) as exchange 
which is (unfortunately) not constant over time. Such a database file must include meta command #@NNNN (e.g., #@2022) 
to tell DXLog for which year the file is valid. The #@NNNN command must be the first line in the file. 
The #@NNNN commmand only works for contests with age as the only exchange and will produce a dual digit number as prefill. 
The two special ages "00" (YL) and "99" (club) are unaffected by file age.

DTB files only have one information element per call sign and the column numbers should be left at zero.

The ''Fill format'' text box allows you to optionally specify special formatting of the looked up prefill information, 
using C# string formatting syntax. For example, to append a slash to the prefill, the fill format would be <code>{0}/</code>. 
Note that the argument {0} is of the type ''string'' which means that numerical operations, such as zero padding, will not work.

You can have multiple, overlapping databases. For instance you may have two data bases with grid locator information. 
DXLog will start looking for the call in database #1 and then continue down the list until a match is found. 
This means that as a rule, the most up-to-date database should be placed highest in the list. 
In the Check Partials window the context menu option "Show data from prefill database" will show you the content of all 
databases used.

Exchange elements not used in the current contest (most only have one) are ignored and can be safely left as zero.

==Statistics files==

Allows the creation and saving of statistics.

[[File:statistics_menu.png]]

'''DXCC''': Statistics related to DXCC.

: ''Create multiplier statistics'' - Create DXCC multiplier statistics during the contest.

: ''Save multiplier statistics in file'' - Saves the DXCC multiplier statistics in a file. The file format is SQLite (.sdb).

: ''Import expected mult list from log file'' - Import expected mults from a previous contest log (*.dxn) file.

: ''Clear expected mult list'' - Clear the expected DXCC multiplier list.

==Log==

Log display options. Controls the appearance and functionality of the log fields.

'''Important:''' This sub menu can also invoked by right-clicking the DXLog desktop or 
the log entry window when run in "floating mode".

[[image:options_log_menu_3.png]]

* '''Log and entry lines''' - Opens a panel allowing you to hide or display selected fields in the log and entry lines.
* '''Fonts''' - Set the size of the log text.
* '''Entry line fonts''' - Set the size of the entry line text. '''Important:''' Is never smaller than log.
* '''Headers''' - Controls the display of log column headers. Also offers the option to add headers to the entry line(s).
* '''Show QSOs for all bands''' - Controls the display of QSO in the log lines.
* '''Hide DX cluster multiplier warnings''' - Hides alerts of DX cluster spots being multipliers
* '''Hide alerts for being spotted on other band(s)''' - Hides alerts of being spotted on band(s) other than the currently operated.
* '''Hide network abort warnings''' - Hides alerts about transmission being aborted by another station.
* '''Hide QSO numbers''' - Hides the QSO numbers in the log lines.
* '''QSO number digits''' - Sets the number of visible QSO number digits.
* '''Always show mode in QSO line''' - Controls the display of mode in the log lines. Useful for multimode contests. Note that the contest configuration key <tt>FIELD_MODE_VISIBLE</tt> will override this setting and is used for some contests.
* '''Show date in QSO lines''' - Show date in QSO lines. Can only be modified for an already logged QSO.
* '''Show frequency in QSO lines''' - Show the frequency in the log line in addition to the band. Updates in real time.
* '''Show operator name in QSO lines''' - Show the logged on operator name in the QSO lines.
* '''Colors''' - Edit log background and text colors.
* '''Position''' - Controls location of log and entry field.
* '''SO2R/V view type''' - Sets the way the two entry lines in SO2R and SO2V are displayed. ''Classic'': show entry lines one above the other. ''Side by side'': show entry lines with one on the left and one on the right.
* '''Stay in field when moving up and down log''' - When editing log this option keeps the cursor in the same log field when moving up through the QSO's.
* '''Restrict up arrow movement''' - Prevents the up arrow key from moving the cursor into the logged QSO. Use Goto last QSO <code>[Ctrl][Q]</code> to edit log.
* '''Use focus background color in SO2R(V)''' - Use a different background color for entry line of the currently focused radio.
* '''Show previous and current messages''' - Show CW message as it is being sent below the entry line with the previous message above the log line.
* '''Show RX color status''' - Change the entry line background when radio's audio is active. '''Important:''' Overrides focus color.
* '''Show border on TX''' - Display a colored border around the entry line of the currently transmitting radio.
* '''Show RX wait border''' - Display a border around the entry line of the radio being held in wait status.
* '''Show cursor in entry line without focus''' - Shows a ghost cursor in the entry line without focus. Very useful for SO2R and SO2V.

==Frequency allocation==

In the heat of the moment it is easy to accidentally call a spotted station 
in a frequency where your license does not allow you to operate.

This function is to prevent exactly this.

When enabled, DXLog will issue a warning pop-up window when grabbing a 
spot in the bandmap or DX cluster announcement windows that would violate 
the selected license.

If desired, DXLog can also block F-key transmission when outside the selected license.

If your license is not listed, please contact the development team for adding it.

[[image:frequencyallocation.png]]

[[image:outofband.png]]

[[image:outofband2.png]]

==Windows==
There are two different ways that DXLog handles the opening of information windows.

* ''Included in the main window'': All windows are opened inside the main window.
* ''Floating'': Enable to use multiple monitors. All windows will be opened outside
: of the main window and can be moved as needed. Please note that in this mode,
: the color of the title bar of each window is not settable.

==Toolbar==

Enable or Disable DXLog toolbar 
[[image:toolbar.png]]

==Reset window positions==

This option brings all windows back to the upper left corner of the screen, useful if a window has been lost off the screen when changing resolution or in a multi screen environment.

Additional Information

2026-04-12T13:41:00Z

Sm7iun: /* QSO information */

==Using alternative configurations==

Window positions, coloring and general look and feel is saved in each log file but all other settings such as 
radio control, keying, and networking is saved in a common, contest-independent configuration file.

By default, the configuration file name is <tt>DXLog.net.config</tt> and it is located in the <tt>%appdata%\DXLog.net</tt> configuration folder.

This folder is also reachable via the <code>File|Open configuration folder</code> menu item.

[[image:configfolder.png]]

DXLog can be made to use an alternative configuration file with the command line option <tt>-cfg=<filename></tt>.

A convenient way to use this option is to create a separate Windows desktop shortcut including the command line option 
and give it a meaningful name.

[[image:Desktopshortcut.png]]

The command line option is simply added to the end of the Target text box in the shortcut's properties. 
Double-clicking the icon will start DXLog with the alternative configuration which will also be remembered between sessions. 
In the picture below the target of the shortcut is

[[image:Desktopshortcutconfig.png]]

'''Important:''' If you want to use an alternative configuration, do not just modify the desktop shortcut created at installation 
since this shortcut will be deleted when you upgrade DXLog. Instead make a copy, rename, and add the command line option. 
You should keep the command line option outside the apostrophes, like this

<tt>"C:\Program Files (x86)\DXLog.net\DXLog.net.exe" -cfg=SO2R.config</tt>

==Using a number server==

For contests involving serial numbers you need to secure that the sent number and the (slightly later) 
logged serial numbers are the same. In a straightforward SO1R or SO2V scenario, serial numbers are simply 
chronological but in more complex station configurations such as Multi-single or Multi-2 with inband, and 
advanced SO2R, QSO can be interleaved and requires a central source source of serial numbers together 
with a mechanic to protect an already sent serial number from re-use by another radio.

In DXLog this is achieved with a central number server. A number server can be used either 
by a single instance of DXLog (for SO2R) or by multiple stations on the same LAN.

The use of a number server involves three, natural, steps:

* Activating the server on a single station
* Making sure all stations use it
* Verifying functionality, making sure serial numbers are correctly reserved

The number server is activated in the <code>Options|Configure network</code> panel, described [[Menu_Options#Configure_network|HERE]].

[[image:startnumberserver.png]]

Since the server uses a networking socket, <code>Options|Networking</code> must be enabled '''also''' when 
using a single computer in SO2R. In the case of multiple stations, UDP networking or Client-Server 
networking must also be enabled to transfer the numbers over the LAN. For SO2R, this is however not 
necessary. When using Client-Server networking, a client cannot be number server.

There must only be one number server in a local network and all stations using it must have 
<code>Options|Networking|Use number server</code> checked like in the picture below.

'''Important:''' The number client/server functionality is not very robust. 
If you have stations joining/leaving your network or being rebooted, it is 
best to restart DXLog on all stations to guarantee correct function.

[[image:usenumberserver.png]]

The option <code>Block logging if serial number reservation is unsuccessful</code> can be used as an extra precaution 
but is not necessary in SO2R since the communication with the number server does not leave the computer.

There are three methods for reserving a number from the server:

* Checking <code>Tools|Data entry|Space key reserves serial number</code> and using the space key to reserve serial numbers. This is typically used on phone or when operating "old school" with F-keys.
* Checking <code>Tools|Data entry|Insert and F2 messages reserve serial number</code> and letting DXLog automatically reserve a serial number right before $SERIAL sends it. This is the preferred and most straightforward way for CW and digital.
* Adding the $RESERVENR macro to messages like illustrated below. 

These methods can of course also be combined. 

The $RESERVENR macro is "smart" and will only reserve a serial number if the callsign entry field is not empty and a 
serial number is not already reserved. The same goes for the menu items.

[[image:reservemessages.PNG]]

The sign of a serial number being reserved is that it turns red. It then stays reserved (and red) until the 
QSO is logged or the entry line is cleared with <code>[Alt][W]</code>.

An option that can prove useful is <code>Tools|Data entry|Cancel serial number reservation only if callsign field is empty</code>. 
In the case that you send the exchange and realize you got the other station's callsign call completely wrong, a reflex can be to hit 
<code>[Alt][W]</code> and start typing. If this is your habit, this option will prevent you from releasing the 
already sent serial number, thereby avoiding you the trouble to send a new one to the other station.

[[image:reservednumber.png]]

==Networking over internet==

When, for instance, activating a special event callsign it is possible to network multiple DXLog stations over the internet.

'''Pro tip:''' Consider displaying the callsign, message ID, Message text, etc. fields in the ''Network status'' 
window when operating a distributed station. Also, learn to use the gab <code>[Alt][G]</code> and <code>[Alt][J]</code> function.

===VLAN/VPN Solution===

The most secure way for remote networking is to rely on a VLAN (virtual LAN) software. There are several available such as:

ZeroTier https://www.zerotier.com/ 
FreeLan http://www.freelan.org/ 
Player.me https://player.me/ 
OpenVPN https://openvpn.net/

Each VLAN solutions have their own particular set up which is covered in their respective documentations. 
With a VLAN solution, all DXLog configurations are the same as when operating in a regular LAN however with a few exceptions.

One weakness with connections over the internet (a.k.a. WAN), including VLAN solutions, is that they are prone to packet loss. 
Packet loss is disastrous to DXLog's (or any logger's) "standard" UDP networking.

It is therefore essential to use '''only client/server networking over a VLAN'''. 
'''This also means you should never use interlock over an internet connection unless you use a zero packet loss VPN tunnel.'''

ZeroTier is particularly popular since it is free.

Since DXLog is able to mix TCP (client/server) and UDP (peer-to-peer) networking, a distributed station set up should be configured to rely on TCP 
for the wide-area network and UDP for the local network at each station location. Below you will find the station 
set up for the Swedish HQ station SE9HQ in the 2019 IARU HF Championship. The DXLog.net.DXC cluster client was run 
on SK3W-A which distributed spots to all stations over the network. Inband interlock was also used at the SK3W location.

[[image:SE9HQ-network-eng.png|800px]]

Important to note:

* For the server as well as the main clients, ''Server IP'' should be set to the server's VLAN IP address, '''not''' its LAN address.
* The '''server''' should check both "Act as network server" and "UDP network broadcast for multiple stations".
* The '''main clients''' should check both "Connect to network server" and "UDP network broadcast for multiple stations".
* The '''sub clients''' should check only "UDP networking for multiple stations".
* Interlock (which is UDP-based) over VLAN does not work reliably because of packet loss.
: Therefore, it is important to configure any interlock to '''only''' consider relevant operating positions,
: which all must be local. Use the possibility to only consider named stations for the interlock in the software 
: interlock set up. <code>Options|Networking|Software interlock</code> "Custom station ID(s)"
* For a large set-up with many stations connecting as clients to a central server you may overload the server if you also
: distribute spots via all client-server connections. In this case, check the "No spots via client/server" option
: on all stations and use '''local DX cluster connections''' via UDP at each location.
: '''Important:''' Limitations in Windows networking makes client/server networking unreliable beyond 10 station locations.
* Make sure to check <code>Options->Load contest at startup</code> to avoid opening the wrong log after a restart.
* '''Remote commands are not forwarded''' in the network but are executed in the station where they arrive.
: Thus, to clear all logs, disconnect networking on each main client, execute the remote command CLEARLOGNOW on each main client
: to clear the logs of all sub clients and do not reconnect until the server and all other main clients have done the same.

===Port forwarding Solution===

If you are less worried about competitors or government agencies listening in on your contest data, 
it is possible to route the traffic directly over the internet using port forwarding at the server.

'''Important security notice: This solution is not without risk. It offers no security or authentication. 
Any DXLog station running the same contest configuration, knowing the URL or IP address and IP port of the 
server can connect to the server station. There are no means to disconnect a station by force.'''

Also note the comment about '''remote commands''' in the section above.

With a port forwarding solution, the following must be observed:

* '''Server configuration'''
:* Only one of the stations should be configured as the '''server'''.
:* "Connect to network server" should not be checked on this station and
:: "UDP networking for multiple stations" should only be enabled if it is used to
:: communicate with a cluster client or other stations locally on the same LAN.
:: Either use a central cluster connection (uncheck "No spots via client/server")
:: or use one cluster connection per station location (check "No spots via client/server").
:: If one cluster connection per station location is used, make sure they
:: all use different SSID to prevent disconnects, such as E7HQ-1, E7HQ-2, etc.
:: This will ensure the cluster node regards all connections as having the same callsign
:: which is essential for e.g., correctly receiving own spots.
:* The PC acting as server must be configured for a fixed LAN IP address. This is done
:: either by manually configuring the networking settings in the PC to use a fixed
:: LAN IP address, or by setting up the router in the server's LAN to to always allocate
:: the same IP address to it.
:* The internet connection used by the server PC must ''either'' have a fixed public IP address ''or''
:: use dynamic DNS. Otherwise clients will not be able to reliable connect over the internet.
:* The server's TCP/IP port (e.g., <code>9888</code>) must be forwarded to the server by the server LAN's router.
:: Only TCP traffic should be forwarded. DXLog UDP traffic is not carried well over the internet.

:: [[image:serverconfig.png|600px]]
:: '''Example configuration for server for networking over internet'''

::[[image:portforwarding.png|600px]]
::'''Example of port forwarding UI in router'''

* '''All other stations'''
:* All other PC in the multi-station set up should be set up as clients.
:* Over the internet, "Server:" is either the static, public IP address of the server's internet
:: connection (e.g. <code>5.140.211.42</code>) or the dynamic DNS address (e.g. <code>hq.sm7iun.se</code>).
:: Clients connecting over the internet does not have to enable UDP networking and ''should not''
:: enable a server.
:* A client may connect via UDP if it is on the same LAN as the server ''or'' a "main client".
:: A "main client" is a client that connects to the server using the "Connect to network server" option in
:: the networking set up panel. A "main client" acts as a UDP gateway which means that if
:: several computers on a LAN are part of the same multi station set up but the server is located
:: elsewhere, only one computer in that LAN needs to connect as a client and the rest can use UDP.
:* Software interlock is UDP-based and can only reliably be used locally. Never over the internet.
:: If used, make sure the interlock is explicitly limited to local stations. See above for more details.

::[[image:clientconfig.png|600px]]
::'''Example configuration of client for networking over internet'''

* In a multi-station setting it is recommended to enable
: <code>Options|Networking|Block standard messages if no operator is logged on</code>
* Make sure <code>Options|Enable network</code> is checked.
* It is also a very good idea to check <code>Options|Load contest at startup</code> to reduce the
: risk of the wrong contest log file being loaded by any stations.

==Real time upload to Club Log Live Stream==

'''Important:''' Club Log truncates QSO time to minutes which means that if you mix real time upload 
with manual upload, make sure to check "QSO time in minutes" when creating ADIF export files.

The author of Club Log, Michael Wall, G7VJR, has developed a very powerful agent for real time uploads. 
It works with all the three major loggers, DXLog, N1MM Logger+, and Win-Test.

It can either be used as is, with a command line user interface, or with an optional user interface front end.

Information on how to download and configure it can be found [[https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads HERE]]

The Club Log Gateway can either listen to DXLog's native multi-station networking protocol or to N1MM style XML broadcast.

To use DXLog's networking protocol, make sure the same port (default 9888) is used in the gateway and DXLog 
and that UDP networking is enabled in DXLog. Do not enable QSO broadcast.

Although this works, it is recommended to use N1MM style broadcast since it contains information like logged on operator, etc.

To use this make sure the port (default 12060) is the same in N1MM port setting in the gateway and in the 
QSO broadcast port settings in DXLog's network configuration. Also make sure to se the DXLog port number 
in the gateway is not the same as that used in DXLog to avoid QSO duplication.

Also set:

<code>Options|Broadcast|QSOs</code> 
<code>Options|Broadcast|QSOs</code> 
<code>Options|Broadcast|Use N1MM QSO format</code> 
<code>Options|Broadcast|QSO time in minutes only</code>

'''Important:''' If you are going to also upload exported ADIF files to Club Log, it is important to also 
check "QSO time in minutes" in the ADIF export configuration to avoid creating virtual dupes, since Club 
Log does not know seconds.

==Diversity reception==

Diversity means receiving the same signal through two different receive chains, including antenna. 
With two antennas having different characteristics this can give substantial benefits in receiving 
fading and/or weak signals or separating calls in a large pile-up. Particularly on low bands.

DXLog supports diversity operation on a selected number of radio models.

For the supported radios, diversity operation can be toggled on and off using <code>[Ctrl][-]</code> or <code>[Ctrl][Keypad -]</code>.

If enabled via the radio's controls, DXLog will automatically detect diversity operation and enable 
the necessary mechanics. Diversity operation is indicated by a small DIV icon in the frequency 
counter box for the radio's band map.

'''Yaesu FTDX101D

Yaesu calls this feature "Sync" and it has a dedicated button up and left of the main VFO knob. 
Enabling this will make DXLog update both VFO with the same information when grabbing spots. 
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO. 
Since both VFO are kept on the same frequency, split operation is not supported.

'''ICOM IC-7851 and IC-7610

ICOM calls this feature "Tracking" and it can be enabled either via a menu entry or a long press on the "MAIN/SUB" button. 
Enabling this will make DXLog update both VFO with the same information when grabbing spots. 
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO. 
Since both VFO are kept on the same frequency, split operation is not supported.

'''Elecraft K3/K3S/K4

Elecraft calls this feature by its proper name. It is enabled by a long press on the "Sub" button. 
It should be noted that Elecraft's implementation where the main VFO controls both the main and 
sub receivers allows for split operation, i.e. transmitting on a different frequency using VFO B.

==UDP broadcast==

For interaction with other applications, DXLog can broadcast useful information as 
XML datagrams over UDP. 

There are five types of broadcast messages produced by DXLog:

* QSO information. Sent when logging.
* Radio information. Sent at changes as well as periodically.
* Antenna direction information. Sent when rotor control is invoked.
* Callsign look-up information
* Spots

QSO can be broadcasted in traditional DXLog format or in a more N1MM-like format.

Radio information can report SO2V as a single physical radio or as two physical radios, like N1MM.

There is an option to truncate the broadcasted QSO time to full minutes for better 
interoperability with some online services and software such as MSHV.

In addition, DXLog can also recognize QSY commands from Waterfall Bandmap and log QSO done as well as create 
local spots from decodes broadcasted by WSJT-X and its forks.

The broadcasting of QSO and radio related data is enabled using the <code>Options|Broadcast</code> submenu.

The broadcasting of spots is enabled by checking <code>Options|DX Cluster|Send spots to SmartSDR</code>.

[[image:radiobroadcastenable3.png]]

[[image:sendspotstosmartsdr.png]]

UDP broadcast parameters are configured in the <code>Options|Network configuration</code> panel. 
Please note that up to three ports can be specified for each broadcast, thereby supporting 
multiple receivers of the information.

[[image:Networksettingsbroadcast3.png]]

If you are writing a C# application to make use of these datagrams, there is a very nice online tool 
for creating an object from a sample XML datagram here https://xmltocsharp.azurewebsites.net/ 

In C# parsing is easily done using Linq. One example of XML parsing and deserialization using Linq 
can be found here https://github.com/bjornekelund/ICOMautomagic

===QSO information===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program
|-
| qsoid
| A unique string for this QSO. If this QSO is edited another contactinfo message will be sent with the same qsoid. Note that the qsoid is only unique within one instance of DXLog. If the computer is networked to others running DXLog the different computers may have a different qsoid for the same QSO.
|-
| contestname
| The name of the contest as it would be written to a Cabrillo file.
|-
| timestamp
| The UTC date and time of the QSO.
|-
| mycall
| The callsign of this station.
|-
| band
| The band on which the QSO was made. In MHz with period as decimal separator. For cross band QSO, the transmit band.
|-
| txfreq
| The frequency on which the QSO was made.
|-
| rxfreq
| The frequency on which the party station was received.
|-
| prop_mode
| Empty or SAT for satellite QSO.
|-
| sat_name
| The name of the satellite for satellite QSO, otherwise empty.
|-
| operator
| The callsign of the operator if the OPON command was used to set it, otherwise blank.
|-
| mode
| The mode used for the QSO.
|-
| call
| The callsign of the station worked.
|-
| countryprefix
| The DXCC country of the station worked.
|-
| wpxprefix
| The WPX prefix of the station worked.
|-
| snt
| The RST sent. This is always included whether or not the contest exchange contains an RST.
|-
| rcv
| The RST received. This is always included whether or not the contest exchange contains an RST.
|-
| nr
| The number sent if the exchange uses a serial number, otherwise the QSO number from this station.
|-
| exch1
| The first element in the contest exchange if any.
|-
| exch2
| The second element in the contest exchange if any.
|-
| exch3
| The third element in the contest exchange if any.
|-
| exch4
| The fourth element in the contest exchange if any.
|-
| xqso
| True if this QSO should not be counted towards the score.
|-
| invalid
| True if this QSO is invalid, for example a DX QSO in a domestic contest.
|-
| duplicate
| True if this QSO is a dupe (the station has previously been worked).
|-
| rule10broken
| True if this QSO breaks the 10 minute or similar rule. Note that a QSO may not break the 10 minute rule when it is logged but may later if another QSO is edited. This may not cause a broadcast.
|-
| azimuth
| The approximate direction of the station worked, in degrees.
|-
| distance
| The approximate distance of the station worked, in kilometers.
|-
| stationid
| The station ID of the station which made the QSO.
|-
| stationqso
| A unique QSO ID generated by the logging station. The combination of stationid and stationqso forms a unique identifier for the QSO.
|-
| stationtype
| The type of station - R for run, R1 for run 1 etc.
|-
| local
| True if this broadcast is due to this QSO being logged or edited on this computer.
|-
| runqso
| True if QSO logged in Run, false if S&P, and empty if unknown. '''Important:''' Only valid when local is True.
|-
| mult1
| The name of the multiplier if this station is a new multipllier, empty otherwise.
|-
| mult2
| The name of the multiplier if this station is a new multiplier, emtpy otherwise.
|-
| mult3
| The name of the multiplier if this station is a new multiplier, empty otherwise.
|-
| points
| The logged points for the QSO.
|-
| period
| The number of the operating period.
|-
| guid
| The GUID in hex format.
|-
| newqso
| True if a new QSO, False if this message is an update to an existing QSO.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<contactinfo>
<logger>DXLog v2.4.13</logger>
<qsoid>19</qsoid>
<contestname>ARRL-SS-CW</contestname>
<timestamp>2020-01-13 18:28:07</timestamp>
<mycall>SM7IUN</mycall>
<band>3.5</band>
<txfreq>352376</txfreq>
<rxfreq>352376</rxfreq>
<prop_mode></prop_mode>
<sat_name></sat_name>
<operator></operator>
<mode>CW</mode>
<call>K4BAI</call>
<countryprefix>K</countryprefix>
<wpxprefix>K4</wpxprefix>
<snt>599</snt>
<rcv>599</rcv>
<nr>19</nr>
<exch1>076</exch1>
<exch2>B</exch2>
<exch3>54</exch3>
<exch4>GA</exch4>
<xqso>False</xqso>
<invalid>False</invalid>
<duplicate>False</duplicate>
<rule10broken>False</rule10broken>
<azimuth>225</azimuth>
<distance>1388</distance>
<stationid>STN1</stationid>
<stationqso>19</stationqso>
<stationtype>R1</stationtype>
<local>True</local>
<runqso>True</local>
<mult1>GA</mult1>
<mult2></mult2>
<mult3></mult3>
<points>3</points>
<period>1</period>
<guid>11223344556677889900aabbccddeeff</newqso>
<newqso>True</newqso>
</contactinfo>
</pre>

Alternative N1MM format

Note that the band name uses the computer's local number format so it may use either comma 
or period as decimal separator. The ID is a number rather than an alphanumeric string.

Also note that IsRunQSO is only valid when IsOriginal is True.

<pre><?xml version="1.0" encoding="utf-8"?>
<contactinfo>
<app>N1MM</app>
<contestname>CWOps</contestname>
<timestamp>2020-01-17 16:43:38</timestamp>
<mycall>SM7IUN</mycall>
<band>3.5</band>
<rxfreq>352519</rxfreq>
<txfreq>352519</txfreq>
<operator></operator>
<mode>CW</mode>
<call>K1XM</call>
<countryprefix>K</countryprefix>
<wpxprefix>K1</wpxprefix>
<stationprefix>K1XM</stationprefix>
<continent>NA</continent>
<snt>599</snt>
<sntnr>5</sntnr>
<rcv>599</rcv>
<misctext></misctext>
<ismultiplier1>1</ismultiplier1>
<ismultiplier2>0</ismultiplier2>
<ismultiplier3>0</ismultiplier3>
<points>l</points>
<radionr>l</radionr>
<run1run2>1<run1run2>
<IsOriginal>False</IsOriginal>
<NetBiosName>DESKTOP-23AB</NetBiosName>
<IsRunQSO>0</IsRunQSO>
<StationName>STATION_B</StationName>
<ID>23</ID>
<IsClaimedQso>true</IsClaimedQso>
</contactinfo>
</pre>

===Radio information===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| The name of the logging program.
|-
| logger
| The name and version of the logging program.
|-
| Station
| The ID of the station.
|-
| RadioNr
| The radio being described.
|-
| Freq
| The receiving frequency.
|-
| TXFreq
| The transmitting frequency
|-
| InactiveFreq
| The frequency of the VFO not receiving.
|-
| Mode
| The reported radio's mode.
|-
| OpCall
| The callsign of the operator if the OPON command was used to set it, otherwise blank.
|-
| mycall
| The callsign of the station.
|-
| IsRunning
| "True" if the station is running, "False" if search and pounce.
|-
| FocusEntry
| The Windows handle for the focused entry window.
|-
| Antenna
| Antenna number.
|-
| Rotors
| Rotators used by selected antenna (not currently used by DXLog).
|-
| FocusRadioNr
| The radio which has keyboard focus. In SO2V with "Report SO2V as two radios" checked, radio 2 is the sub/B VFO.
|-
| IsStereo
| True if headphones are listening to two radios.
|-
| IsSplit
| True if radio is set to split.
|-
| ActiveRadioNr
| The radio which is transmitting, if any.
|-
| Technique
| SO1R, SO2R, SO2R_ADV, or SO2V
|-
| StationType
| Station role: R, M, R1, R2, or R+.
|-
| isTransmitting
| True if a DXLog is transmitting. False if DXLog is not aware of transmission.
|-
| IFFrequency
| Optional element only used with Elecraft K3/K4. Contains the current IF frequency in Hz.
|-
|}

Important note: In SO2V the format differs from some other loggers and is:

: Only physical radio 1 is reported.
: <tt>Freq</tt> and <tt>TXFreq</tt> are the frequency of the currently focused VFO.
: <tt>InactiveFreq</tt> is the frequency of the currently unfocused VFO.
: <tt>ActiveRadio</tt> is always 1.
: <tt>FocusedRadioNr</tt> is 1 when the main/A VFO is focused, 2 otherwise.
: <tt>IsSplit</tt> is always false.

With the option "Report SO2V as two radios" checked, the reporting is similar to some other loggers and is:

: The two VFO are reported as two physical radios.
: <tt>Freq</tt> and <tt>TXFreq</tt> for radio 1 are the frequency of the main/A VFO.
: <tt>Freq</tt> and <tt>TXFreq</tt> for radio 2 are the frequency of the sub/B VFO.
: <tt>InactiveFreq</tt> is the frequency of the other VFO.
: <tt>ActiveRadio</tt> and <tt>FocusedRadioNr</tt> are 1 when the main/A VFO is focused, 2 otherwise.
: <tt>IsSplit</tt> is always false.

Example message:

<pre><?xml version = "1.0"?>
<RadioInfo>
<app>DXLog</app>
<logger>DXLog v2.4.13</logger>
<Station>STN1</Station>
<RadioNr>1</RadioNr>
<Freq>704000</Freq>
<TXFreq>704000</TXFreq>
<InactiveFreq>702500</InactiveFreq>
<Mode>CW</Mode>
<OpCall>K1XM</OpCall>
<mycall>HQ9X</mycall>
<IsRunning>False</IsRunning>
<FocusEntry>591124</FocusEntry>
<Antenna>1</Antenna>
<Rotors>ABC</Rotors>
<FocusRadioNr>1</FocusRadioNr>
<IsStereo>False</IsStereo>
<IsSplit>False</IsSplit>
<ActiveRadioNr>1</ActiveRadioNr>
<Technique>SO2R</Technique>
<StationType>R1</StationType>
<IsTransmitting>False</IsTransmitting>
<IFFrequency>8215000</IFFrequency>
</RadioInfo>
</pre>

===Antenna direction===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program.
|-
| station
| The ID of the station.
|-
| radio
| The radio associated with the rotator.
|-
| go
| True if the rotator should be turned.
|-
| stop
| True if the rotator should be stopped if it is turning.
|-
| azimuth
| The direction to turn the rotator if go is True.
|-
| frequency
| The transmit frequency of the specified radio.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<Rotator>
<logger>DXLog v2.4.13</logger>
<station>STN1</station>
<radio>2</radio>
<go>True</go>
<azimuth>252</azimuth>
<frequency>2800200</frequency>
</Rotator>

</pre>
<pre><?xml version="1.0" encoding="utf-8"?>
<Rotator>
<logger>DXLog v2.4.13</logger>
<station>STN1</station>
<radio>2</radio>
<stop>True</stop>
<frequency>2800200</frequency>
</Rotator>
</pre>

===Callsign lookup===

Sent either when callsign in entry row is changed or when space or tab is pressed.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program.
|-
| contestname
| The name of the contest.
|-
| mycall
| Station's call
|-
| band
| Current band
|-
| txfreq
| Transmitter frequency
|-
| operator
| The call sign of the logged in operator
|-
| mode
| Operating mode
|-
| call
| Call entered in the logging field
|-
| countryprefix
| DXCC entity prefix
|-
| wpxprefix
| WPX prefix
|-
| azimuth
| Short path antenna direction
|-
| distance
| Distance in km
|-
| stationid
| The ID of the station sending the datagram
|-
| stationtype
| The role of the station sending the datagram; R, R1, R2, M, or R+
|-
| period
| Contest period
|-
| reason
| Reason for transmission; SpaceOrTab or CallChanged
|-
|}

Example message:

<pre><?xml version = "1.0"?>
<lookupinfo>
<logger>DXLog v2.4.20</logger>
<contestname>DARC-WAEDC-CW</contestname>
<mycall>K1XM</mycall>
<band>20</band>
<txfreq>1400200</txfreq>
<operator></operator>
<mode>CW</mode>
<call>E7DX</call>
<countryprefix>E7</countryprefix>
<wpxprefix>E7</wpxprefix>
<azimuth>54</azimuth>
<distance>6824</distance>
<stationid></stationid>
<stationtype>R</stationtype>
<period>1</period>
<reason>SpaceOrTab</reason>
</lookupinfo>
</pre>

===Spot===

Sent for every incoming spot from the DX cluster that is valid for the current contest.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| Application sending the message.
|-
| StationName
| The station issuing the broadcast.
|-
| dxcall
| The callsign of the spotted station.
|-
| frequency
| Frequency in kHz with decimal sign of the PC's current locale. (sic)
|-
| spottercall
| The callsign of the spotter. Station name if locally spotted or result of a logging operation.
|-
| timestamp
| Spot time in format yyyy-MM-dd HH:mm:ss
|-
| action
| add or delete.
|-
| mode
| actual or guessed mode of the spot in capitals.
|-
| comment
| The comment section of the spot.
|-
| status
| Spot status. Valid values are "dupe", "double mult", "single mult", and "new qso".
|-
| statuslist
| Same as status
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<spot>
<app>DXLog.net</app>
<StationName>CONTEST-PC</StationName>
<dxcall>E7DX</dxcall>
<frequency>14022.3</frequency>
<spottercall>SM7IUN-#</spottercall>
<timestamp>2O23-07-15 14:29:37</timestamp>
<action>add</action>
<mode>CW</mode>
<comment>CW 31 DB 42 WPM CQ</comment>
<status>single mult</status>
<statuslist>single mult</statuslist>
</spot></pre>

===Broadcast listener===

DXLog also listens for commands over UDP.

Currently only one command is implemented, <code><radio_setfrequency></code>, which is a QSY command.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| Application sending the command
|-
| radionr
| The radio to be changed. In SO2V radio 2 means VFO B. Optional as of DXLog 2.5.20.
|-
| frequency
| Requested frequency. Both period and comma is accepted as decimal separator.
|-
| mousebutton
| Which mouse button was used to create message, if any. Optional.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<radio_setfrequency>
<app>WaterfallBandmap</app>
<radionr>1</radionr>
<frequency>21022.194</frequency>
<mousebutton>Left</mousebutton>
</radio_setfrequency>
</pre>

==SDR integration==

===HDSDR, OmniRig, and microHAM===

''Contributed by Ingo SM5AJV/SE5E''

Until DXLog offers SDR integration there are still ways to get a waterfall/spectrum display with DXLog.

I have integrated the free SDR software [http://www.hdsdr.de/ HDSDR] with DXLog using
[http://www.microham.com Microham Device Router], 
[http://dxatlas.com/OmniRig/ OmniRig]
and [https://www.autohotkey.com/ AutoHotkey].

As illustrated below I place the HDSDR window at the very top of the desktop with DXLog right below.

I share my transceiver's (an Elecraft K3) antenna with the SDR. The receiver antenna signal from my 
K3's RX-ANT OUT is connected to the input of a 3dB power splitter. The two outputs from the splitter 
are connected RX-ANT IN on the K3 and the SDR Receiver antenna input, respectively. On a K3 you 
need to enable the RX-antenna input to make this to work. An additional benefit with this method 
is that the SDR is protected during transmission. It is a widely used method and is e.g. described 
by Bob N6TV in this
[http://dxlog.net/sw/files/utilities/Adding%20an%20SDR%20to%20an%20SO2R%20Station.pdf presentation].

'''Screenshot of my desktop:

[[Image:Sdrdesktop.png|800px]]

Since both DXLog and HDSDR need to communicate with the radio, you need to "split" 
the CAT communication. microHAM's USB Device Router provides a second, independent, 
CAT port that can be used via HDSDR's omniRig interface.

'''"PORT" Tab on microHamRouter:

[[Image:Sdrmicrohamrouter.png|800px]]

'''OmniRig settings in HDSDR:

[[Image:Sdromnirig.png|200px]]

With this set up, the radio, DxLog, and HDSDR will be fully synchronized. For instance, you can 
click in the waterfall to make the radio QSY, and it is easy to quickly find a clean frequency.

To make the integration even better I use a small AutoHotkey script. The script pulls entry focus 
back to DxLog after clicking on the HDSDR waterfall and in DXLog it allows you to use hotkeys to 
control HDSDR. <code>[Ctrl][Alt]+</code> and <code>[Ctrl][Alt]-</code> zooms the waterfall/spectrum 
in and out, and <code>[Ctrl][Alt]C</code> centers it.

'''AutoHotkey script:

SetTitleMatchMode, 2
#InstallKeybdHook
#IfWinActive, HDSDR
{
F4:: return ; disable F4
~LButton Up::
sleep, 1
Winactivate, DXLog
return
}
#IfWinActive, DXLog
{
^!+:: ControlSend ,, ^{+}, HDSDR
^!-:: ControlSend ,, ^{-}, HDSDR
^!c:: ControlSend ,, {c}, HDSDR
}

The script can be downloaded [http://DXLog/sw/files/utilities/dxlog_hdsr.ahk here].

If you start two instances of HDSDR with two different SDR you can even have two waterfalls 
running at the same time.

I have not yet found a way to display cluster spots in the HDSDR spectrum panel. 
But I still find it very useful to check band activity and it allows me to easily find 
a new Run frequency on a crowded band.

===Waterfall Bandmap===

The free waterfall/spot display utility "Waterfall Bandmap" by Steve N2IC is supported by DXLog.

Waterfall Bandmap supports almost any SDR that produce I/Q output either via ExtIO.DLL or a 
sound card; SDRPlay, FunCubeProPlus, HackRF, SDR-IQ, RTLSDR, SoftRock, etc.

A zip file with an executable binary and a Microsoft word document with installation and 
configuration instructions can be found here: https://groups.io/g/waterfallbandmap/files

If you are not a member of the support forum group, you need to apply for membership to download. 
Membership is free.

[[Image:Waterfallbandmap.png]]

The SDR can be connected either to a separate receive antenna, an external receiver output on 
your transceiver or to an IF output, should your transceiver have one. If connected to an antenna, 
keep in mind that you may need protection from the transmitter such as a T/R relay or a passive level limiter.

Please refer to Waterfall Bandmap's documentation for setting it up with your SDR.

Waterfall Bandmap needs two information feeds over UDP: Radio information and spot information. 
Both are provided as UDP broadcast by DXLog.

The default port for both is 13063 and this needs to be set in DXLog's Network configuration panel. 
If Waterfall Bandmap runs on the same computer as DXLog, the broadcast address can be left at the default 127.0.0.1.

[[Image:Setbroadcastportsforwfbandmap.png]]

Clicking on the waterfall display can set the frequency of DXLog. (Left click sets VFO A, right click sets VFO B.) 
To enable this functionality, check the option <code>Options|Broadcast|Receive Broadcasts</code> 
Also make sure "UDP broadcast listener" includes port 13064 in the network settings panel.

The radio information feed needs to be enabled by checking the <code>Options|Broadcast|Radio information</code> option

[[Image:radiobroadcastenable2.png]]

and the spot feed needs to be enabled by checking the <code>Options|DX Cluster|Send spots to SmartSDR</code> option.

[[Image:Enablesendspotstosmartsdr.png]]

==Time synchronization==

In a multi-station setting, the time needs to be accurately synchronized across all networked PC.

Windows' built in time synchronization is very crude and for a PC with poor clock stability the 
inaccuracy of the clock may be up to a minute. Which of course is not acceptable for contesting.

DXLog has built in support for time synchronization as described in the [[Menu Options#Configure network|Configure network section]].

Due to Windows' security system, this however requires all except the PC running as time server to 
run DXLog with elevated permissions. There is unfortunately no way around this inconvenience.

An equally accurate and less intrusive method is to use a standalone time synchronization application on each networked PC. 
This will keep each PC's clock accurate within a fraction of a second.

Contrary to a solution built into a logger it also has the great benefit of being an "install and forget" solution.

A popular application is Dimension 4 by Thinking Man Software. It is free for personal use and 
can be downloaded here: https://dxlog.net/sw/files/utilities/d4time531.msi

It runs in the background and only shows up as a tiny icon in your system tray. 
You hover the mouse above the icon to check status and right-click to open and change settings.

:::[[image:dimension4tray.png|50px]]

After installation a brief configuration is required.

First of all, allow the application to disable Windows' time service and to modify your system clock.

For maximum accuracy, select a time server geographically close to your location. 
When in doubt, you can always add the global server "pool.ntp.org" to the list and use that. 

There are also national and continental pools of time servers. You can find them here https://www.ntppool.org.

[[image:dimension4b.png]]

Make sure the check boxes "Load Dimension 4 at startup", "Start minimized", "Hide when minimized", 
and "Display icon in tray" are all checked.

[[image:dimension4advanced.png]]

Click the Advanced button and also make sure the option "Use the selected server" is selected.

Make sure the application reports a successful connection to the selected time server. 
From here on, you can basically forget the application. 
It will silently start with your PC and always keep its time accurate.

==Disabling USB power management==

In the interest of saving energy, Windows habitually power down USB interfaces 
when it believes there is inactivity. Some USB-to-serial and USB audio devices 
respond poorly to being suspended or powered down so as a rule this "feature" should 
be disabled when used in a ham radio environment.

There are two places where this functionality needs to be disabled; the device driver 
and Windows' energy management.

To disable it for each USB interface and device, open Windows settings. (Click the Windows 
icon in the lower left corner and then chose the cogwheel.) Type ''device manager'' and
select the result.

[[image:devicemanager-c.png|none|frame]]

This opens up a new window, Windows' Device Manager.

[[image:devicemanager2b.png|none|frame]]

For '''every''' USB interface component (there may be many), COM-port, and audio device, 
and '''uncheck''' the option ''Allow the computer to turn this device off to save power''.

The devices you are looking for are in the categories: ''Ports (COM & LPT)'', 
''Sound, video and game controllers'', ''Universal serial bus controllers'',

Note that some devices may not have a ''Power Management'' tab.

[[image:usbdevicemanager.png|none|frame]]

The next step is to disable Windows ''Selective suspend'' feature for USB interfaces.

Go back to Windows Settings and type ''edit power'', click the appearing ''Edit power plan'' menu entry.

[[image:editpowerplan2.png|none|frame]]

This should open the window below, the plan editing panel.

[[image:editplansettings.png|none|frame]]

Click ''Change advanced power settings''. Scroll down to ''USB settings'' and make 
sure ''USB selective suspend setting'' is '''disabled''' for all situations.

[[image:Advancedsettings.png|none|frame]]

To prevent audio devices from becoming unreachable or going into sleep mode you should also 
disable exclusive access. While changing this, also make sure all audio enhancements are disabled.

You reach the detailed audio device settings by entering Windows settings, search for Control panel, 
and in the Control panel view, select Hardware and audio, and then Sound.

[[image:Audiodevice.png]]

Reboot your computer to make sure all settings are recognized by Windows.

==Interlock and inband operation==

In contest station terminology, the term ''Interlock'' refers to a technical solution preventing 
more than one station from using a shared resource, typically an antenna, at the same time.

The most common use for interlock is for inband operation. Inband operation means to have multiple 
transmitters on a single band, interleaving their transmissions. Sometimes on a split-second basis.

As long as you never have more than one transmitter active at any time, the majority of contests allow 
an unlimited number of transmitters and receivers on a single band for multi-operator categories. 
This fact is used by most big contest stations.

For an inband solution to be effective, each station must be able to receive while the 
other station transmits. This means it requires a separate, high performance receive antenna 
with very good isolation from the transmitter antenna. The most common way to 
achieve this is physical separation and geographic orientation to minimize the situations 
when they will radiate/listen in the direction of the other antenna.

For a station operating in the M/M, M/S, or M/2 category, inband operation can boost the points 
per hour performance significantly. It is also a lot more fun.

However, as with everything else, it comes at a cost. An efficient inband solution has:

* A high performance receive antenna for each operated band(s) with very good isolation from the transmitter antenna.
* A fail-safe antenna switching hardware.
* Interlock-capable keyers and/or station controllers.
* An interlock-capable contest logging software

A typical inband configuration can be seen in the illustration below.

[[image:inbandconcept-trx.jpg|800px]]

DXLog offers a software-based interlock which can be configured in a variety of ways, e.g. based on frequency 
band, operating mode, or station role. It supports an unlimited number of stations interlocking each other 
using a great variety of strategies.

The interlock relies on UDP networking and is overlaid on the communication for multi-station logging. 
UDP networking has the benefit of speed and low latency but is, unlike TCP, susceptible to packet loss. 
This means that a '''wired LAN''' is a necessity for any station using interlock. 
For the same reason, it is also not recommended to run interlock over e.g. VLAN/VPN link for 
geographically distributed stations.

A software interlock is not 100% reliable. Computer or software malfunction, networking issues such as packet 
loss, etc. can cause interlock to fail, even if only momentarily.

For this reason it is necessary to also accompany a software interlock with a fail-safe '''hardware''' interlock. 
Without hardware supported interlock you run the risk of not only violating contest rules but also cause serious equipment damage. 
Some contests, such as CQ WW, explicitly requires hardware interlock when using multiple stations on the same band.

There are many designs and even commercial products available for hardware interlock. 
One example of a simple but effective two station hardware interlock which also supports 
power amplifier sharing can be found [https://sm7iun.se/contest/inband/ HERE].

The purpose of this section is to describe steps of setting up a basic two station in-band solution with 
DXLog and microHAM keyers. The microHAM keyers are not mandatory but offers a much better user experience 
and removes the need for additional hardware.

'''Pro tip:''' Consider checking <code>Options|Networking|Allow other stations to abort sending</code> 
which will allow your partner station to interrupt your transmission with <code>[Shift][Esc]</code> in 
critical situations. Be careful though, the use of this function requires good judgment to avoid violence.

===Networking===

Open the networking configuration panel with <code>Options|Configure network</code> and make sure each 
station has a unique name and that only UDP networking is enabled.

Make sure the two stations use the same broadcast IP address and that it is in line with your LAN's 
configuration. Pressing the <tt>Default</tt> button is a good way to ensure this.

Make sure the menu option <code>Options|Enable network</code> has a checkmark.

[[image:inbandnetworkrun.png|left|frame]][[image:inbandnetworkinband.png|none|frame]] 

===DXLog Interlock configuration===

First of all, make sure that the <code>Options|Interface specific options|Prevent TX if another radio is on same band</code> 
is '''not''' enabled. This option completely prevents transmission if more than one networked station is set to the same band 
and the whole idea with inband is to have exactly that.

Next, activate software interlock on both stations using the menu option <code>Options|Networking|Software interlock</code> 
or by typing the commmand <tt>ILOCKON</tt>.

[[image:inbandinterlock2.png|none|frame]]

There are multiple options for configuring the interlock. In a simple set up with only two stations, the topmost 
option ''Same band from status list'' is a good choice. This option will prevent more than one station transmitting 
on the same band, regardless of mode.

In an environment with many stations (such as a multi-operator-multi-transmitter station) it is 
recommended to use the bottom option to only interlock with one or several named stations. 
This will reduce both LAN traffic and inband operation latency. This is particularly important when 
running parts of the DXLog network over high latency links such as VLAN/VPN or if some stations (albeit not 
part of the interlock cluster) are connected via Wi-Fi.

For more advanced scenarios you can also use interlock based on mode or station type (e.g. Run 1, Run 2, Mult, etc.).

The "status list" listing the networked DXLog stations is displayed in the ''Status Window'' which is opened 
with <code>Windows|Status window</code> or <code>[Alt][J]</code>.

[[image:inbandstatuslist2.png]]

DXLog also offers great flexibility when it comes to interlock strategy. The most straightforward and 
most commonly used is ''First one wins''. This is also typically the behavior of "unintelligent" 
hardware solutions when not assisted by software. With this strategy, the station starting to transmit 
first can not be interrupted and always gets to finish its transmission.

[[image:inbandinterlockoptions.png]]

With a ''Last one wins'' strategy, the transmitting station can be interrupted. A carte blanche permission 
to interrupt all transmissions by the other station may however be counterproductive in a real contest situation.

For this reason, DXLog offers additional control of which transmit actions can be interrupted and which can not. 
This is a powerful tool but requires both operators to be aware of it and may require 
practice before fully effective.

[[image:inbandstrategyexceptions.png]]

''F1'' through ''F7'', ''PLUS'' and ''INS'' refers to DXLog's standard messages. ''KEYB'' means a free text transmission 
from the keyboard using the <code>[Alt][K]</code> function and ''MAN'' means manual transmission using either paddle 
break-in or a footswitch.

For CW, DXLog recognizes paddle break in from a K1EL Winkey-compatible keyer as described in the [[Menu_Options#Winkey_Configuration|Winkey configuration section]].

Since DXLog recognizes a footswitch connected to a microHAM device, this is a recommended approach for phone. 
It is also possible to connect a footswitch to the DSR pin (pin 6) on a physical COM-port on the PC, but today 
few PC have such a port and it also requires additional circuitry.
Details on how to do this is available [[Additional_Information#Connecting_a_footswitch|HERE]].

===microHAM configuration===

Open the microHAM device configuration panel with <code>Options|microHAM device configuration</code>.

[[image:Mk2r-new9.png|none|frame]]

Check the option ''Enable TX lock/unlock''. This will do two things; it will enable DXLog to prevent 
transmission and and it will make DXLog aware of the microHAM device's PTT status. The latter is particularly 
important since it means DXLog will recognize PTT assertion not only by a footswitch connected to the 
microHAM device but also by the built-in Winkeyer (requires microHAM USB Device Router version 9.3.0 or later) 
'''Paddle-based break-in in an inband solution is currently unique for microHAM with DXLog.'''

'''Important:''' Making DXLog "PTT aware" means that care has to be taken in how PTT is set up. If you, for instance, 
enable DXLog PTT for the voice keyer, this will create a self-reinforcing feedback loop and PTT will thus never drop.

Check the option ''Dual radio device'' if you are using a u2R, MK2R, or MK2R+, otherwise, leave this unchecked.

Check the option ''Device without CAT interface'' if the device lacks a CAT interface (like the u2R) 
or if its CAT interface is not connected to the radio. This option will make sure the e.g. keying and 
audio routing is always set correctly in line with the operating mode (Voice, CW, or RTTY).

===Operating===

Inband operation requires a fair amount of training and it is a good idea to define and agree 
on general rules for operation, such as hand signals for challenging QSO, beforehand.

There are more than enough YouTube videos of inband operators yelling at each other.

The operating tactics may have to be adjusted during the contest. If Run is slow, 
doing S&P on the inband station can increase the points per minute significantly. 
However, if Run is strong, an overly active inband operator doing S&P, but not working 
multipliers, may actually reduce the station's points per minute significantly.

Real-time interlock status is shown in the ''Radio status'' window, which is opened with 
<code>Windows|Radio status</code>.

[[image:inbandblocking.png]] [[image:inbandblocked.png]]

For Phone contesting, you typically rely on footswitches for PTT and the option 
<code>Options|Networking|Show QSO status when blocking</code> makes the blocking 
station send a more helpful blocking cause than ''MAN''.

With this option enabled, the blocking station will instead send ''CQ'', ''QSO'', or ''EXCHANGE'' 
as blocking cause, determined by cursor location and entry field content at the locking station.

Further reading can be found in the [[Menu_Options#microHAM_device_configuration|microHAM device configuration]] and [[Menu_Options#Networking|Networking]] sections.

==Connecting a footswitch==

To free up both hands in Phone contesting, a footswitch PTT is a great help.

Also, to use interlock in Phone contesting, a footswitch is mandatory.

There are two basic ways to interface a footswitch with DXLog; via a microHAM device (which is the recommended solution) 
or directly connected to a physical serial port on the PC (which very few PC have today).

The connection of a footswitch to a microHAM device is very straightforward and by checking the ''Enable TX lock/unlock'' 
in the ''microHAM device configuration'' panel, it is recognized by DXLog.

Lacking a microHAM device, it is also possible to use the computer's DB9 RS-232 serial port connector, providing it has one.

The required steps to do this are:
* Connect a 10k resistor between DB9 pin 6 and pin 7.
* In the port's settings (<code>Options|Configure interfaces</code>) set DTR (pin 4) to ''Always On'' and RTS (pin 7) to ''Always Off'' for the port.
* Connect the footswitch between DB9 pins 4 and pin 6. '''Important:''' Neither pole on the footswitch must be connected to ground.
* In the radio's configuration panel, check ''use CAT PTT command on Phone'' and set ''Footswitch (pin 6)'' to ''PTT''

==Support for CC Cluster==

CC Cluster is today the main choice for contest use.

It offers a high quality, database-verified, flow of skimmer spots and a rapid 3-minute respotting period for skimmer spots.

It also publishes unique spots from less common locations which are valuable for DX chasers or as contest multipliers.

To make use of the display of own spot in the world map, make sure to issue the command '''<tt>SET/OWN</tt>''' to the cluster node. 
This setting is persistent and only needs to be done once.

A list of cluster nodes that runs CC Cluster can be found here: [https://www.dxcluster.info/telnet/index.php?software=CC%20Cluster CC Cluster nodes]

A description of the command line syntax can be found here: [http://bcdxc.org/ve7cc/ccc/CCC_Commands.htm CC Cluster command syntax]

A convenient software for setting up filters etc. can be found here [http://www.bcdxc.org/ve7cc/default.htm#prog CC User]

[[Image:Ccclustersspotflow.png]]

==Support for AR Cluster 6==

With the author tragically SK, AR Cluster is no longer under development but still available as an executable binary.

In its standard configuration, AR Cluster offers no consolidation of skimmer spots meaning a very high flow of spots 
that can become extreme during a major contest weekend.

With the advent of skimmers, the traffic on the DX Cluster has risen dramatically. Even though CW skimmers are generally 
quite reliable, the absolute number of busted spots can be quite high during a busy contest.

Jose CT1BOH has developed an algorithm for evaluating spot quality which is included in version 6 of AR Cluster. 
Today many cluster nodes runs this version and thereby offer this mechanic. 
A complete list can be found here: [http://www.dxcluster.info/telnet/index.php?software=AR-Cluster AR Cluster nodes]

To enable the functionality on a cluster node running AR Cluster 6, the command

<tt>'''SET DX EXTENSION SKIMMERQUALITY'''</tt>

needs to be issued to the cluster node. The easiest way to do this in DXLog is via <code>[Alt][T]</code>. 
This setting will be remembered at subsequent logins.

The quality of the spots is indicated by a character ("tag") in the last column of the comment field and, 
in some cases, a corrected callsign within parenthesis. This syntax is recognized by DXLog and can reduce the 
number of bad spots in your bandmap.

The CT1BOH skimmer quality algorithm is based on three parts:

; Validation : When a callsign is first spotted, it is tagged with "?" in the last column of the spot's comment field. If the callsign of an unverified spot closely resembles an already verified one on the same frequency, the verified callsign is provided within parenthesis in the spot's comment field. When two or more skimmers agree on the spot, it is considered verified and the tag becomes "V".

; Frequency : When a verified spot appears more than 0.35kHz off its verified frequency, the spot is tagged "Q" for QSY. Once verified, this becomes the new verified frequency and it is tagged "V".

; Probability : The algorithm checks uncertain spots for resemblance with already verified spots and spots at or near the same frequency. If the resemblance is high enough, the spot is considered busted "B" and the corrected callsign is provided within parenthesis in the spot's comment field.

Below you can see an example of the spot flow from W9PA-4 with skimmer quality enabled. 
The flow contains one unverified and one busted spot.

[[image:spotquality.png]]

DXLog's policy for spots with CT1BOH skimmer quality tags is the following:

: '''V''' - Accept spot.
: '''Q''' - Accept spot.
: '''?''' - Accept spot. Use corrected call when provided.
: '''B''' - Accept spot if corrected call provided. Else ignore.

DXLog recognizes the skimmer quality tags but consolidates them for consistency 
with other cluster nodes' quality tags and to minimize confusion when mixing spot flows. 
The legend is:

: '''?''' means a spot with ? This is an unreliable spot.
: '''P''' means a spot with Q or B with correction. This is a fairly reliable spot.
: '''V''' means a spot with V. This spot is considered validated.

This basic policy can be modified by using additional filters at the cluster node end. Some examples are:

: <tt>'''SET DX FILTER NOT SKIMBUSTED'''</tt> - Do not send busted spots at all
: <tt>'''SET DX FILTER NOT SKIMQSY'''</tt> - Do not send QSY spots
: <tt>'''SET DX FILTER SKIMVALID'''</tt> - Only send verified spots
: <tt>'''SET DX FILTER NOT SKIMUNKNOWN'''</tt> - Do not send unreliable spots
: <tt>'''SET DX FILTER SKIMMER'''</tt> - Do not send manual spots

You can also compose more complex filters such as:

: <tt>'''SET DX FILTER SKIMVALID OR SKIMBUSTED OR NOT SKIMMER'''</tt>

This can be a good filter for most contests. It will will only provide valid or busted skimmer spots together with manual spots. 
It is safe to receive busted spots since DXLog will ignore them if there is no corrected callsign included. 

For assisted operation in serious contesting you however need to allow also unknown spots since weak stations spotted 
only by one or a few skimmers may never reach validated status. You do this by adding <tt>'''OR SKIMUNKNOWN'''</tt> to the filter.

Both the bandmap and the DX cluster announcement windows have the option to display the spot quality tag. 
These windows will show two additional tags; L and C. L stands for local spot, created by yourself or one of your team members. 
C stands for corrected, i.e., a B or ? spot where a corrected call has been included in the spot's comment field.

The AR6 filtering syntax offers a lot of flexibility. Another example:

: <tt>'''SET DX FILTER (SKIMVALID OR NOT SKIMMER OR ((SKIMQSY OR SKIMUNKNOWN) AND (CTY <> K AND CONT <> EU )))'''</tt>

will provide only validated and human spots except if they are from outside the US and EU.

If you get lost in the filter settings you can always reset with : <tt>'''SET DX DEFAULT'''</tt>.

Some more guidance on how to work with filters on AR-Cluster nodes can be found in [http://dxlog.net/sw/files/utilities/AR_Cluster_v6_User_Manual.pdf this document].

==Support for DXSpider==

DXSpider is the most dominant DX cluster software but has historically not been a 
good choice for contesters. The reasons for this include: Long respotting time, lack 
of pass function for own spots, and suppression of spots from a single skimmer.

The good news is however that the author Dirk G1TLH has worked hard to address these 
aspects of the otherwise brilliant software.

From '''version 1.57 release 440''' the respotting time is now 3 minutes and there is a 
<tt>SET/SEEME</tt> command that passes all spots without consolidation of your own callsign.

So if your favorite cluster node is not running this version, ask the owner to upgrade asap.

Yet another reason for its popularity is its extreme resource-efficiency which allows it to run 
virtually any Linux capable hardware, including a $20 Raspberry Pi Zero.

A list of all DX cluster nodes running DX Spider can be found here: [https://www.dxcluster.info/telnet/index.php?software=DX%20Spider DX Spider cluster nodes]

[[image:dxspiderflow.png]]

DXLog recognizes the <tt>Q:#</tt> skimmer quality tag in the comment field and converts them into 
"CT1BOH-like" quality tags that can be displayed in DXLog's bandmap. The legend is:

: '''?''' means a spot with Q:1, i.e. heard by only one skimmer. This is an unreliable spot.
: '''P''' means a spot with Q:2, i.e. heard by only two skimmers. This is a fairly reliable spot.
: '''V''' means a spot with Q:3 or higher, i.e. heard by several skimmers. This spot is considered validated.

Since a DXSpider node currently needs to be specially configured by the owner to publish Q:1 spots, very few do this. 
Also, since DXSpider lacks busted call detection, the the quality of the spot flow will suffer if this is done.

A typical cluster line looks like this:

'''<tt><nowiki>DX de PY2MKU-# 14065.0 SM7IUN CW 29dB Q:9* Z:14,15,20 1922Z</nowiki></tt>'''

The Q parameter is the number of skimmers spotting the call. The trailing star means they do not quite agree 
on the frequency. A trailing plus means the station has been spotted for more than one hour. The Z parameter 
lists the CQ zones in which the callsign is spotted.

There is a wealth of information to be found on the [http://wiki.dxcluster.org/index.php/Main_Page DXSpider wiki].

==Support for N2WQ Cluster==

Introduced in late 2025, Rudy N2WQ has developed the first new DX cluster node software in decades.

The N2WQ-2 cluster has some unique features like a more advanced callsign validation than 
AR 6 and propagation estimation tags embedded in the spot comments. An example can be seen below.

[[image:n2wpspotflow.png]]

When you connect to dxc.n2wq.com port 8300 and you have set your 4-digit Maidenhead grid (SET GRID), there 
will be a single character just before the DX’s grid locator. This character is the path prediction glyph.

It is a crowdsourced, real-time estimate of how reliable the path is between you and the DX on that band right now, 
based on recent on-air propagation reports from RBN and PSKreporter. Its values and meaning are:

: > High: Strong path. If you can hear them, you should be able to work them.
: = Medium: Decent path. Workable with normal contest/DX technique.
: < Low: Weak path. Possible, but expect repeats, timing, and patience.
: - Unlikely: Marginal. Try only if it’s rare/needed, or you have a strong station advantage.

A missing glyph means insufficient data to estimate the path.

the glyph is mode-aware. A path that looks great for a very sensitive mode (FT8) can look 
more moderate for a less sensitive one (SSB).

You can filter spots by path reliability using the PASS/REJECT PATH command.

It is important to be aware that the glyph does not know:

: Your antenna gain/pattern, height, or takeoff angle
: Your transmit power and duty cycle constraints
: Your operating technique (timing, split discipline, pileup strategy)
: Short-lived phenomena the network has not yet “seen” such as sporadic E or aurora.

The cluster ingests upwards of 50,000 CW, FT, RTTY, and WSPR spots per minute. To compare different modes 
fairly, the system normalizes reports onto a common “FT8-equivalent” scale (so a CW SNR can be compared 
to an FT8 SNR).

Your grid and the DX grid are mapped into small geographic cells and the cluster calculates propagation 
at two levels:

: Fine (local): what’s happening close to your area (~180 miles).
:: On averages there are about 90,000 DE/DX pairs being tracked
: Coarse (regional): what’s happening in the broader region around
:: you (~480 miles). On average, there are about 30,000 DE/DX pairs.

If there isn’t enough local data, the system leans more on regional behavior. 
If there’s plenty of local data, it uses that more heavily.

Sometimes you can hear them better than they can hear you (or the reverse) due to noise 
floors, antennas, geography, or ionospheric effects. The system tracks both:

: Receive direction: DX to you (can you hear them?)
: Transmit direction: you to DX (can they hear you?)

It combines these into one “path reliability” estimate, weighting receive a bit more 
because if you can’t hear them, you can’t work them.

Propagation changes fast, so older reports get discounted using a half-life (data fades 
in influence over time). Typical behavior by band:

: Low bands (160/80m): slower changes (longer half-life)
: Mid bands (40–20m): medium pace
: High bands (15–6m): fast changes (shorter half-life)

In practice, this means glyphs can shift in minutes on 10m/6m, and more slowly on 80m/160m. 
Also, new openings take time to show up. A "insufficient" can simply mean “the path just opened 
and the cluster hasn’t collected enough recent reports yet.”

Your local noise floor heavily affects what you can receive, so the cluster lets you tell 
it what your noise environment is. This mainly tunes the receive-side expectation (DX to you).

Set it with SET NOISE SUBURBAN. Available profiles per ITU:

: QUIET: very low noise, rural/remote
: RURAL: mild noise
: SUBURBAN: typical neighborhood QRM
: URBAN: elevated noise, dense housing
: INDUSTRIAL: severe noise

If you don’t set it, the system may assume a quieter environment than you actually 
have, and your receive-side glyphs can look too optimistic.

Treat the glyph as a real-time probability hint that helps you spend your operating 
time where the odds are best. When you see > on a needed multiplier, move fast. 
When you see -, be intentional about whether it’s worth the time. 
And when you see a space, fall back to classic DX/contest instincts and your own ears.

The N2WQ cluster also offers spot quality tags between the DX grid and the time.

A quality (in terms of callsign reliability) tag can be V, P, S, C, or ? where V means validated, 
P highly likely, S less likely, C corrected, and ? unsure.

The propagation and quality tags can be displayed in the bandmaps and the DX cluster announcement window.

DXLog recognizes the skimmer quality tags but consolidates them before display for consistency 
with other cluster nodes' quality tags and to minimize confusion when mixing spot flows. 
The legend is:

: '''?''' means a spot with ? or S. This is an unreliable spot.
: '''P''' means a spot with P or C. This is a fairly reliable spot.
: '''V''' means a spot with V. This spot is considered verified.

==Interacting with WSJT-X==

Important: When in a DXpedition/multi-station setting, always use local host 127.0.0.1 as the 
broadcast address to prevent packets being picked up by other stations in the network. 
Also, enabling the creation of local spots from decodes may overwhelm DXLog.

DXLog can add QSO performed with WSJT-X to its log. Note that this functionality only works 
for contests with grid as the first and only exchange or for DXPedition type logs.

DXLog can also create local spots from WSJT-X decodes by checking 
<code>Options|Broadcast|Spot WSJT-X decodes</code>.

To enable logging of WSJT-X QSO, set up WSJT-X to broadcast information:

[[image:Wsjt-x-udp.png]]

[[image:Radiobroadcastenable3.png]]

Activate DXLog's UDP listener by checking <code>Options|Broadcast|Receive broadcasts</code> and set 
the same port number as in WSTJ-X in DXLog's network configuration panel.

[[image:Dxlog-udp.png]]

==Using Winkey FSK==

Winkey FSK is not natively supported by DXLog's digital mode engines MMVARI or MMTTY but 
Rafal EI6LA has developed a plugin for MMTTY that makes this possible.

You can find it [https://github.com/RafalLukawiecki/WinKeyerMMTY here].

==Interfacing with LogHX==

Christian F8GHE has prepared a guide on how to do this.

You can find it [http://dxlog.net/sw/files/utilities/DXLOG-LogHX_UDP-config_v2.pdf here].

==Self-spotting==

More and more contests allow spotting your own station on the DX cluster.

DXLog supports this, even when operating unassisted, as long as you connect to the cluster.

DXLog has three mechanics for self-spotting.

DXLog blocks self spotting unless specifically allowed in the contest rules. 
Should you find that DXLog incorrectly allows or blocks self-spotting, please make 
the development team aware via the support reflector.

* The <tt>$SPOTME</tt> macro command. This macro will create a cluster spot of the station's
: call at the earliest 15 seconds after being invoked the first time on a new frequency.
: Thereafter it will spot as frequent as allowed by the contest. If the contest rules do not
: specify a minimum period, 10 minutes will be used.

* Checking the menu option <code>Tools|Data entry|Run F1 message self-spots when permitted</code>.
: Works exactly like the <tt>$SPOTME</tt> macro command but is triggered by sending the
: Run F1 message which happens when pressing <code>[Enter]</code> with an empty entry line
: in Run, pressing <code>[F1]</code> in Run, or with Auto-CQ.

* Clicking the menu item <code>Commands|Self-spot</code> or pressing its shortcut key <code>[Ctrl][S]</code>.
: This will immediately create a spot of the station's call but no more often than
: every two seconds to avoid accidental multiple spots.

==DXpedition use==

DXLog is a popular choice for top tier dxpeditions. Below we have collected advice based on experience 
on how to best use DXLog in a dxpedition setting.

* Use client/server networking between stations. Never use UDP over Wi-Fi or WAN links.
* Use the "Minimal data" option in ADIF export to save on satellite link cost.
* For Club Log real time upload, use [https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads Club Log's upload app]
* Club Log truncate QSO time to minutes so to avoid creating dupes when mixing manual and real time upload to Club Log, check ''QSO time in minutes'' when doing ADIF export.
* Use the "Minimal data" option in ADIF export to save on satellite link cost.
* Follow [[Additional_Information#Interacting_with_WSJT-X|the instructions]] to log QSO made with WSJT-X and MSHV.
* Check <code>Options|Broadcast|Spot WSJT-X decodes</code> to make decoded calls appear in e.g., DX cluster announcements.
* You can extend the number of digits in the QSO count with <code>Options|Log|QSO number digits</code>

==Beacon spots on DX cluster==

Although propagation measurements based on FT8 communications has reduced the 
value of beacons, there are still hundreds of them in operation.

Identifying with CW, they are typically reported on reported on the DX cluster.

When beacon spots are received by DXLog, they are always displayed in the bandmap. 
In DXLog, beacon spots are recognized by having a trailing <tt>/B</tt>.

The DX cluster announcement window never shows or counts beacon spots.

Beacon spots can be enabled and disabled in the cluster node.

For CC Cluster, the commands are <tt>SET/BEACON</tt> and <tt>UNSET/BEACON</tt>.

For DXSpider, command is part of the <tt>SET/SKIMMER</tt> command where <tt>SET/SKIMMER</tt> 
or e.g., <tt>SET/SKIMMER CW BCN FT RTTY</tt> will pass beacon spots and <tt>UNSET/SKIMMER</tt> 
or any <tt>SET/SKIMMER</tt> listing modes but not BCN will block them.

AR 6 cluster nodes always pass beacon spots when skimmer spots are enabled. They cannot be disabled.

==Using Piper text-to-speech synthesis==

James M0DST has prepared 7 sample scripts that can be mapped to F keys.

James' comments on the scripts are:

This is just an extended proof of concept. Feel free to play using your own scripts. 
There is a lot of code duplication across the scripts. I may simplify some of this in the future. 
I tried base classes, but the current script engine would need some rework to support that. 
Repeat isn't supported. You will need to press the key manually. 
Multiple op voices are not supported currently. You could hack this in with little effort. 
There is no documentation at present. This feature is experimental whilst I decide how I want 
to move it forward (if at all). If you want to adjust the speed, you can do it per script. 
See SpeakingRate in the F2 script. Lower number is faster.

You can visit https://rhasspy.github.io/piper-samples/ to hear the voices. Set the model in the script.

Any comments or thoughts on anything related to this should be sent to me directly or on the list.

I really suggest training your own voice. I haven't done it yet, but I will when I have time. 
Using common amateur radio phrases in the training data will help teach it to sound more like a ham.

If you improve the scripts, please send them to me and I will update the files behind this link. 
Once everything is stable and formalized I will pass the links to Bjorn for the website, and we 
will add some real documentation.

Experimental scripts:
[https://drive.google.com/file/d/1EhfOpxsL57yuf-1WorASnGf-SBsmfqu7/view?usp=drive_link F1]
[https://drive.google.com/file/d/1MgviBec7HCXIOJZtDZXl0qXlrU-TwMoD/view?usp=drive_link F2]
[https://drive.google.com/file/d/1yAgY5E-KdOcmToXMJQ2lRNhjBIQrJIb9/view?usp=drive_link F3]
[https://drive.google.com/file/d/1-ftWUhFlc4-quwGPIVmNujQ4q-J5E3EZ/view?usp=drive_link F4]
[https://drive.google.com/file/d/1h3C_kLl9C4CEH6kATGAZbfDkfY6KlgqB/view?usp=drive_link F5]
[https://drive.google.com/file/d/1e4tAHz-_dU92RybaFeSuLCd0V7Gk_lWy/view?usp=drive_link F6]
[https://drive.google.com/file/d/1UGxgOpqOjOzl7yFTjrVaml9m5o8gBq5y/view?usp=drive_link F7]

Additional Information

2026-04-12T13:05:00Z

Sm7iun: /* QSO information */

==Using alternative configurations==

Window positions, coloring and general look and feel is saved in each log file but all other settings such as 
radio control, keying, and networking is saved in a common, contest-independent configuration file.

By default, the configuration file name is <tt>DXLog.net.config</tt> and it is located in the <tt>%appdata%\DXLog.net</tt> configuration folder.

This folder is also reachable via the <code>File|Open configuration folder</code> menu item.

[[image:configfolder.png]]

DXLog can be made to use an alternative configuration file with the command line option <tt>-cfg=<filename></tt>.

A convenient way to use this option is to create a separate Windows desktop shortcut including the command line option 
and give it a meaningful name.

[[image:Desktopshortcut.png]]

The command line option is simply added to the end of the Target text box in the shortcut's properties. 
Double-clicking the icon will start DXLog with the alternative configuration which will also be remembered between sessions. 
In the picture below the target of the shortcut is

[[image:Desktopshortcutconfig.png]]

'''Important:''' If you want to use an alternative configuration, do not just modify the desktop shortcut created at installation 
since this shortcut will be deleted when you upgrade DXLog. Instead make a copy, rename, and add the command line option. 
You should keep the command line option outside the apostrophes, like this

<tt>"C:\Program Files (x86)\DXLog.net\DXLog.net.exe" -cfg=SO2R.config</tt>

==Using a number server==

For contests involving serial numbers you need to secure that the sent number and the (slightly later) 
logged serial numbers are the same. In a straightforward SO1R or SO2V scenario, serial numbers are simply 
chronological but in more complex station configurations such as Multi-single or Multi-2 with inband, and 
advanced SO2R, QSO can be interleaved and requires a central source source of serial numbers together 
with a mechanic to protect an already sent serial number from re-use by another radio.

In DXLog this is achieved with a central number server. A number server can be used either 
by a single instance of DXLog (for SO2R) or by multiple stations on the same LAN.

The use of a number server involves three, natural, steps:

* Activating the server on a single station
* Making sure all stations use it
* Verifying functionality, making sure serial numbers are correctly reserved

The number server is activated in the <code>Options|Configure network</code> panel, described [[Menu_Options#Configure_network|HERE]].

[[image:startnumberserver.png]]

Since the server uses a networking socket, <code>Options|Networking</code> must be enabled '''also''' when 
using a single computer in SO2R. In the case of multiple stations, UDP networking or Client-Server 
networking must also be enabled to transfer the numbers over the LAN. For SO2R, this is however not 
necessary. When using Client-Server networking, a client cannot be number server.

There must only be one number server in a local network and all stations using it must have 
<code>Options|Networking|Use number server</code> checked like in the picture below.

'''Important:''' The number client/server functionality is not very robust. 
If you have stations joining/leaving your network or being rebooted, it is 
best to restart DXLog on all stations to guarantee correct function.

[[image:usenumberserver.png]]

The option <code>Block logging if serial number reservation is unsuccessful</code> can be used as an extra precaution 
but is not necessary in SO2R since the communication with the number server does not leave the computer.

There are three methods for reserving a number from the server:

* Checking <code>Tools|Data entry|Space key reserves serial number</code> and using the space key to reserve serial numbers. This is typically used on phone or when operating "old school" with F-keys.
* Checking <code>Tools|Data entry|Insert and F2 messages reserve serial number</code> and letting DXLog automatically reserve a serial number right before $SERIAL sends it. This is the preferred and most straightforward way for CW and digital.
* Adding the $RESERVENR macro to messages like illustrated below. 

These methods can of course also be combined. 

The $RESERVENR macro is "smart" and will only reserve a serial number if the callsign entry field is not empty and a 
serial number is not already reserved. The same goes for the menu items.

[[image:reservemessages.PNG]]

The sign of a serial number being reserved is that it turns red. It then stays reserved (and red) until the 
QSO is logged or the entry line is cleared with <code>[Alt][W]</code>.

An option that can prove useful is <code>Tools|Data entry|Cancel serial number reservation only if callsign field is empty</code>. 
In the case that you send the exchange and realize you got the other station's callsign call completely wrong, a reflex can be to hit 
<code>[Alt][W]</code> and start typing. If this is your habit, this option will prevent you from releasing the 
already sent serial number, thereby avoiding you the trouble to send a new one to the other station.

[[image:reservednumber.png]]

==Networking over internet==

When, for instance, activating a special event callsign it is possible to network multiple DXLog stations over the internet.

'''Pro tip:''' Consider displaying the callsign, message ID, Message text, etc. fields in the ''Network status'' 
window when operating a distributed station. Also, learn to use the gab <code>[Alt][G]</code> and <code>[Alt][J]</code> function.

===VLAN/VPN Solution===

The most secure way for remote networking is to rely on a VLAN (virtual LAN) software. There are several available such as:

ZeroTier https://www.zerotier.com/ 
FreeLan http://www.freelan.org/ 
Player.me https://player.me/ 
OpenVPN https://openvpn.net/

Each VLAN solutions have their own particular set up which is covered in their respective documentations. 
With a VLAN solution, all DXLog configurations are the same as when operating in a regular LAN however with a few exceptions.

One weakness with connections over the internet (a.k.a. WAN), including VLAN solutions, is that they are prone to packet loss. 
Packet loss is disastrous to DXLog's (or any logger's) "standard" UDP networking.

It is therefore essential to use '''only client/server networking over a VLAN'''. 
'''This also means you should never use interlock over an internet connection unless you use a zero packet loss VPN tunnel.'''

ZeroTier is particularly popular since it is free.

Since DXLog is able to mix TCP (client/server) and UDP (peer-to-peer) networking, a distributed station set up should be configured to rely on TCP 
for the wide-area network and UDP for the local network at each station location. Below you will find the station 
set up for the Swedish HQ station SE9HQ in the 2019 IARU HF Championship. The DXLog.net.DXC cluster client was run 
on SK3W-A which distributed spots to all stations over the network. Inband interlock was also used at the SK3W location.

[[image:SE9HQ-network-eng.png|800px]]

Important to note:

* For the server as well as the main clients, ''Server IP'' should be set to the server's VLAN IP address, '''not''' its LAN address.
* The '''server''' should check both "Act as network server" and "UDP network broadcast for multiple stations".
* The '''main clients''' should check both "Connect to network server" and "UDP network broadcast for multiple stations".
* The '''sub clients''' should check only "UDP networking for multiple stations".
* Interlock (which is UDP-based) over VLAN does not work reliably because of packet loss.
: Therefore, it is important to configure any interlock to '''only''' consider relevant operating positions,
: which all must be local. Use the possibility to only consider named stations for the interlock in the software 
: interlock set up. <code>Options|Networking|Software interlock</code> "Custom station ID(s)"
* For a large set-up with many stations connecting as clients to a central server you may overload the server if you also
: distribute spots via all client-server connections. In this case, check the "No spots via client/server" option
: on all stations and use '''local DX cluster connections''' via UDP at each location.
: '''Important:''' Limitations in Windows networking makes client/server networking unreliable beyond 10 station locations.
* Make sure to check <code>Options->Load contest at startup</code> to avoid opening the wrong log after a restart.
* '''Remote commands are not forwarded''' in the network but are executed in the station where they arrive.
: Thus, to clear all logs, disconnect networking on each main client, execute the remote command CLEARLOGNOW on each main client
: to clear the logs of all sub clients and do not reconnect until the server and all other main clients have done the same.

===Port forwarding Solution===

If you are less worried about competitors or government agencies listening in on your contest data, 
it is possible to route the traffic directly over the internet using port forwarding at the server.

'''Important security notice: This solution is not without risk. It offers no security or authentication. 
Any DXLog station running the same contest configuration, knowing the URL or IP address and IP port of the 
server can connect to the server station. There are no means to disconnect a station by force.'''

Also note the comment about '''remote commands''' in the section above.

With a port forwarding solution, the following must be observed:

* '''Server configuration'''
:* Only one of the stations should be configured as the '''server'''.
:* "Connect to network server" should not be checked on this station and
:: "UDP networking for multiple stations" should only be enabled if it is used to
:: communicate with a cluster client or other stations locally on the same LAN.
:: Either use a central cluster connection (uncheck "No spots via client/server")
:: or use one cluster connection per station location (check "No spots via client/server").
:: If one cluster connection per station location is used, make sure they
:: all use different SSID to prevent disconnects, such as E7HQ-1, E7HQ-2, etc.
:: This will ensure the cluster node regards all connections as having the same callsign
:: which is essential for e.g., correctly receiving own spots.
:* The PC acting as server must be configured for a fixed LAN IP address. This is done
:: either by manually configuring the networking settings in the PC to use a fixed
:: LAN IP address, or by setting up the router in the server's LAN to to always allocate
:: the same IP address to it.
:* The internet connection used by the server PC must ''either'' have a fixed public IP address ''or''
:: use dynamic DNS. Otherwise clients will not be able to reliable connect over the internet.
:* The server's TCP/IP port (e.g., <code>9888</code>) must be forwarded to the server by the server LAN's router.
:: Only TCP traffic should be forwarded. DXLog UDP traffic is not carried well over the internet.

:: [[image:serverconfig.png|600px]]
:: '''Example configuration for server for networking over internet'''

::[[image:portforwarding.png|600px]]
::'''Example of port forwarding UI in router'''

* '''All other stations'''
:* All other PC in the multi-station set up should be set up as clients.
:* Over the internet, "Server:" is either the static, public IP address of the server's internet
:: connection (e.g. <code>5.140.211.42</code>) or the dynamic DNS address (e.g. <code>hq.sm7iun.se</code>).
:: Clients connecting over the internet does not have to enable UDP networking and ''should not''
:: enable a server.
:* A client may connect via UDP if it is on the same LAN as the server ''or'' a "main client".
:: A "main client" is a client that connects to the server using the "Connect to network server" option in
:: the networking set up panel. A "main client" acts as a UDP gateway which means that if
:: several computers on a LAN are part of the same multi station set up but the server is located
:: elsewhere, only one computer in that LAN needs to connect as a client and the rest can use UDP.
:* Software interlock is UDP-based and can only reliably be used locally. Never over the internet.
:: If used, make sure the interlock is explicitly limited to local stations. See above for more details.

::[[image:clientconfig.png|600px]]
::'''Example configuration of client for networking over internet'''

* In a multi-station setting it is recommended to enable
: <code>Options|Networking|Block standard messages if no operator is logged on</code>
* Make sure <code>Options|Enable network</code> is checked.
* It is also a very good idea to check <code>Options|Load contest at startup</code> to reduce the
: risk of the wrong contest log file being loaded by any stations.

==Real time upload to Club Log Live Stream==

'''Important:''' Club Log truncates QSO time to minutes which means that if you mix real time upload 
with manual upload, make sure to check "QSO time in minutes" when creating ADIF export files.

The author of Club Log, Michael Wall, G7VJR, has developed a very powerful agent for real time uploads. 
It works with all the three major loggers, DXLog, N1MM Logger+, and Win-Test.

It can either be used as is, with a command line user interface, or with an optional user interface front end.

Information on how to download and configure it can be found [[https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads HERE]]

The Club Log Gateway can either listen to DXLog's native multi-station networking protocol or to N1MM style XML broadcast.

To use DXLog's networking protocol, make sure the same port (default 9888) is used in the gateway and DXLog 
and that UDP networking is enabled in DXLog. Do not enable QSO broadcast.

Although this works, it is recommended to use N1MM style broadcast since it contains information like logged on operator, etc.

To use this make sure the port (default 12060) is the same in N1MM port setting in the gateway and in the 
QSO broadcast port settings in DXLog's network configuration. Also make sure to se the DXLog port number 
in the gateway is not the same as that used in DXLog to avoid QSO duplication.

Also set:

<code>Options|Broadcast|QSOs</code> 
<code>Options|Broadcast|QSOs</code> 
<code>Options|Broadcast|Use N1MM QSO format</code> 
<code>Options|Broadcast|QSO time in minutes only</code>

'''Important:''' If you are going to also upload exported ADIF files to Club Log, it is important to also 
check "QSO time in minutes" in the ADIF export configuration to avoid creating virtual dupes, since Club 
Log does not know seconds.

==Diversity reception==

Diversity means receiving the same signal through two different receive chains, including antenna. 
With two antennas having different characteristics this can give substantial benefits in receiving 
fading and/or weak signals or separating calls in a large pile-up. Particularly on low bands.

DXLog supports diversity operation on a selected number of radio models.

For the supported radios, diversity operation can be toggled on and off using <code>[Ctrl][-]</code> or <code>[Ctrl][Keypad -]</code>.

If enabled via the radio's controls, DXLog will automatically detect diversity operation and enable 
the necessary mechanics. Diversity operation is indicated by a small DIV icon in the frequency 
counter box for the radio's band map.

'''Yaesu FTDX101D

Yaesu calls this feature "Sync" and it has a dedicated button up and left of the main VFO knob. 
Enabling this will make DXLog update both VFO with the same information when grabbing spots. 
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO. 
Since both VFO are kept on the same frequency, split operation is not supported.

'''ICOM IC-7851 and IC-7610

ICOM calls this feature "Tracking" and it can be enabled either via a menu entry or a long press on the "MAIN/SUB" button. 
Enabling this will make DXLog update both VFO with the same information when grabbing spots. 
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO. 
Since both VFO are kept on the same frequency, split operation is not supported.

'''Elecraft K3/K3S/K4

Elecraft calls this feature by its proper name. It is enabled by a long press on the "Sub" button. 
It should be noted that Elecraft's implementation where the main VFO controls both the main and 
sub receivers allows for split operation, i.e. transmitting on a different frequency using VFO B.

==UDP broadcast==

For interaction with other applications, DXLog can broadcast useful information as 
XML datagrams over UDP. 

There are five types of broadcast messages produced by DXLog:

* QSO information. Sent when logging.
* Radio information. Sent at changes as well as periodically.
* Antenna direction information. Sent when rotor control is invoked.
* Callsign look-up information
* Spots

QSO can be broadcasted in traditional DXLog format or in a more N1MM-like format.

Radio information can report SO2V as a single physical radio or as two physical radios, like N1MM.

There is an option to truncate the broadcasted QSO time to full minutes for better 
interoperability with some online services and software such as MSHV.

In addition, DXLog can also recognize QSY commands from Waterfall Bandmap and log QSO done as well as create 
local spots from decodes broadcasted by WSJT-X and its forks.

The broadcasting of QSO and radio related data is enabled using the <code>Options|Broadcast</code> submenu.

The broadcasting of spots is enabled by checking <code>Options|DX Cluster|Send spots to SmartSDR</code>.

[[image:radiobroadcastenable3.png]]

[[image:sendspotstosmartsdr.png]]

UDP broadcast parameters are configured in the <code>Options|Network configuration</code> panel. 
Please note that up to three ports can be specified for each broadcast, thereby supporting 
multiple receivers of the information.

[[image:Networksettingsbroadcast3.png]]

If you are writing a C# application to make use of these datagrams, there is a very nice online tool 
for creating an object from a sample XML datagram here https://xmltocsharp.azurewebsites.net/ 

In C# parsing is easily done using Linq. One example of XML parsing and deserialization using Linq 
can be found here https://github.com/bjornekelund/ICOMautomagic

===QSO information===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program
|-
| qsoid
| A unique string for this QSO. If this QSO is edited another contactinfo message will be sent with the same qsoid. Note that the qsoid is only unique within one instance of DXLog. If the computer is networked to others running DXLog the different computers may have a different qsoid for the same QSO.
|-
| contestname
| The name of the contest as it would be written to a Cabrillo file.
|-
| timestamp
| The UTC date and time of the QSO.
|-
| mycall
| The callsign of this station.
|-
| band
| The band on which the QSO was made. In MHz with period as decimal separator. For cross band QSO, the transmit band.
|-
| txfreq
| The frequency on which the QSO was made.
|-
| rxfreq
| The frequency on which the party station was received.
|-
| prop_mode
| Empty or SAT for satellite QSO.
|-
| sat_name
| The name of the satellite for satellite QSO, otherwise empty.
|-
| operator
| The callsign of the operator if the OPON command was used to set it, otherwise blank.
|-
| mode
| The mode used for the QSO.
|-
| call
| The callsign of the station worked.
|-
| countryprefix
| The DXCC country of the station worked.
|-
| wpxprefix
| The WPX prefix of the station worked.
|-
| snt
| The RST sent. This is always included whether or not the contest exchange contains an RST.
|-
| rcv
| The RST received. This is always included whether or not the contest exchange contains an RST.
|-
| nr
| The number sent if the exchange uses a serial number, otherwise the QSO number from this station.
|-
| exch1
| The first element in the contest exchange if any.
|-
| exch2
| The second element in the contest exchange if any.
|-
| exch3
| The third element in the contest exchange if any.
|-
| exch4
| The fourth element in the contest exchange if any.
|-
| xqso
| True if this QSO should not be counted towards the score.
|-
| invalid
| True if this QSO is invalid, for example a DX QSO in a domestic contest.
|-
| duplicate
| True if this QSO is a dupe (the station has previously been worked).
|-
| rule10broken
| True if this QSO breaks the 10 minute or similar rule. Note that a QSO may not break the 10 minute rule when it is logged but may later if another QSO is edited. This may not cause a broadcast.
|-
| azimuth
| The approximate direction of the station worked, in degrees.
|-
| distance
| The approximate distance of the station worked, in kilometers.
|-
| stationid
| The station ID of the station which made the QSO.
|-
| stationqso
| A unique QSO ID generated by the logging station. The combination of stationid and stationqso forms a unique identifier for the QSO.
|-
| stationtype
| The type of station - R for run, R1 for run 1 etc.
|-
| local
| True if this broadcast is due to this QSO being logged or edited on this computer.
|-
| runqso
| True if QSO logged in Run, false if S&P, and empty if unknown. '''Important:''' Only valid when local is True.
|-
| mult1
| The name of the multiplier if this station is a new multipllier, empty otherwise.
|-
| mult2
| The name of the multiplier if this station is a new multiplier, emtpy otherwise.
|-
| mult3
| The name of the multiplier if this station is a new multiplier, empty otherwise.
|-
| points
| The logged points for the QSO.
|-
| period
| The number of the operating period.
|-
| guid
| The GUID in hex format.
|-
| newqso
| True if a new QSO, False if this message is an update to an existing QSO.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<contactinfo>
<logger>DXLog v2.4.13</logger>
<qsoid>19</qsoid>
<contestname>ARRL-SS-CW</contestname>
<timestamp>2020-01-13 18:28:07</timestamp>
<mycall>SM7IUN</mycall>
<band>3.5</band>
<txfreq>352376</txfreq>
<operator></operator>
<mode>CW</mode>
<call>K4BAI</call>
<countryprefix>K</countryprefix>
<wpxprefix>K4</wpxprefix>
<snt>599</snt>
<rcv>599</rcv>
<nr>19</nr>
<exch1>076</exch1>
<exch2>B</exch2>
<exch3>54</exch3>
<exch4>GA</exch4>
<xqso>False</xqso>
<invalid>False</invalid>
<duplicate>False</duplicate>
<rule10broken>False</rule10broken>
<azimuth>225</azimuth>
<distance>1388</distance>
<stationid>STN1</stationid>
<stationqso>19</stationqso>
<stationtype>R1</stationtype>
<local>True</local>
<runqso>True</local>
<mult1>GA</mult1>
<mult2></mult2>
<mult3></mult3>
<points>3</points>
<period>1</period>
<guid>11223344556677889900aabbccddeeff</newqso>
<newqso>True</newqso>
</contactinfo>
</pre>

Alternative N1MM format

Note that the band name uses the computer's local number format so it may use either comma 
or period as decimal separator. The ID is a number rather than an alphanumeric string.

Also note that IsRunQSO is only valid when IsOriginal is True.

<pre><?xml version="1.0" encoding="utf-8"?>
<contactinfo>
<app>N1MM</app>
<contestname>CWOps</contestname>
<timestamp>2020-01-17 16:43:38</timestamp>
<mycall>SM7IUN</mycall>
<band>3.5</band>
<rxfreq>352519</rxfreq>
<txfreq>352519</txfreq>
<operator></operator>
<mode>CW</mode>
<call>K1XM</call>
<countryprefix>K</countryprefix>
<wpxprefix>K1</wpxprefix>
<stationprefix>K1XM</stationprefix>
<continent>NA</continent>
<snt>599</snt>
<sntnr>5</sntnr>
<rcv>599</rcv>
<misctext></misctext>
<ismultiplier1>1</ismultiplier1>
<ismultiplier2>0</ismultiplier2>
<ismultiplier3>0</ismultiplier3>
<points>l</points>
<radionr>l</radionr>
<run1run2>1<run1run2>
<IsOriginal>False</IsOriginal>
<NetBiosName>DESKTOP-23AB</NetBiosName>
<IsRunQSO>0</IsRunQSO>
<StationName>STATION_B</StationName>
<ID>23</ID>
<IsClaimedQso>true</IsClaimedQso>
</contactinfo>
</pre>

===Radio information===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| The name of the logging program.
|-
| logger
| The name and version of the logging program.
|-
| Station
| The ID of the station.
|-
| RadioNr
| The radio being described.
|-
| Freq
| The receiving frequency.
|-
| TXFreq
| The transmitting frequency
|-
| InactiveFreq
| The frequency of the VFO not receiving.
|-
| Mode
| The reported radio's mode.
|-
| OpCall
| The callsign of the operator if the OPON command was used to set it, otherwise blank.
|-
| mycall
| The callsign of the station.
|-
| IsRunning
| "True" if the station is running, "False" if search and pounce.
|-
| FocusEntry
| The Windows handle for the focused entry window.
|-
| Antenna
| Antenna number.
|-
| Rotors
| Rotators used by selected antenna (not currently used by DXLog).
|-
| FocusRadioNr
| The radio which has keyboard focus. In SO2V with "Report SO2V as two radios" checked, radio 2 is the sub/B VFO.
|-
| IsStereo
| True if headphones are listening to two radios.
|-
| IsSplit
| True if radio is set to split.
|-
| ActiveRadioNr
| The radio which is transmitting, if any.
|-
| Technique
| SO1R, SO2R, SO2R_ADV, or SO2V
|-
| StationType
| Station role: R, M, R1, R2, or R+.
|-
| isTransmitting
| True if a DXLog is transmitting. False if DXLog is not aware of transmission.
|-
| IFFrequency
| Optional element only used with Elecraft K3/K4. Contains the current IF frequency in Hz.
|-
|}

Important note: In SO2V the format differs from some other loggers and is:

: Only physical radio 1 is reported.
: <tt>Freq</tt> and <tt>TXFreq</tt> are the frequency of the currently focused VFO.
: <tt>InactiveFreq</tt> is the frequency of the currently unfocused VFO.
: <tt>ActiveRadio</tt> is always 1.
: <tt>FocusedRadioNr</tt> is 1 when the main/A VFO is focused, 2 otherwise.
: <tt>IsSplit</tt> is always false.

With the option "Report SO2V as two radios" checked, the reporting is similar to some other loggers and is:

: The two VFO are reported as two physical radios.
: <tt>Freq</tt> and <tt>TXFreq</tt> for radio 1 are the frequency of the main/A VFO.
: <tt>Freq</tt> and <tt>TXFreq</tt> for radio 2 are the frequency of the sub/B VFO.
: <tt>InactiveFreq</tt> is the frequency of the other VFO.
: <tt>ActiveRadio</tt> and <tt>FocusedRadioNr</tt> are 1 when the main/A VFO is focused, 2 otherwise.
: <tt>IsSplit</tt> is always false.

Example message:

<pre><?xml version = "1.0"?>
<RadioInfo>
<app>DXLog</app>
<logger>DXLog v2.4.13</logger>
<Station>STN1</Station>
<RadioNr>1</RadioNr>
<Freq>704000</Freq>
<TXFreq>704000</TXFreq>
<InactiveFreq>702500</InactiveFreq>
<Mode>CW</Mode>
<OpCall>K1XM</OpCall>
<mycall>HQ9X</mycall>
<IsRunning>False</IsRunning>
<FocusEntry>591124</FocusEntry>
<Antenna>1</Antenna>
<Rotors>ABC</Rotors>
<FocusRadioNr>1</FocusRadioNr>
<IsStereo>False</IsStereo>
<IsSplit>False</IsSplit>
<ActiveRadioNr>1</ActiveRadioNr>
<Technique>SO2R</Technique>
<StationType>R1</StationType>
<IsTransmitting>False</IsTransmitting>
<IFFrequency>8215000</IFFrequency>
</RadioInfo>
</pre>

===Antenna direction===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program.
|-
| station
| The ID of the station.
|-
| radio
| The radio associated with the rotator.
|-
| go
| True if the rotator should be turned.
|-
| stop
| True if the rotator should be stopped if it is turning.
|-
| azimuth
| The direction to turn the rotator if go is True.
|-
| frequency
| The transmit frequency of the specified radio.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<Rotator>
<logger>DXLog v2.4.13</logger>
<station>STN1</station>
<radio>2</radio>
<go>True</go>
<azimuth>252</azimuth>
<frequency>2800200</frequency>
</Rotator>

</pre>
<pre><?xml version="1.0" encoding="utf-8"?>
<Rotator>
<logger>DXLog v2.4.13</logger>
<station>STN1</station>
<radio>2</radio>
<stop>True</stop>
<frequency>2800200</frequency>
</Rotator>
</pre>

===Callsign lookup===

Sent either when callsign in entry row is changed or when space or tab is pressed.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program.
|-
| contestname
| The name of the contest.
|-
| mycall
| Station's call
|-
| band
| Current band
|-
| txfreq
| Transmitter frequency
|-
| operator
| The call sign of the logged in operator
|-
| mode
| Operating mode
|-
| call
| Call entered in the logging field
|-
| countryprefix
| DXCC entity prefix
|-
| wpxprefix
| WPX prefix
|-
| azimuth
| Short path antenna direction
|-
| distance
| Distance in km
|-
| stationid
| The ID of the station sending the datagram
|-
| stationtype
| The role of the station sending the datagram; R, R1, R2, M, or R+
|-
| period
| Contest period
|-
| reason
| Reason for transmission; SpaceOrTab or CallChanged
|-
|}

Example message:

<pre><?xml version = "1.0"?>
<lookupinfo>
<logger>DXLog v2.4.20</logger>
<contestname>DARC-WAEDC-CW</contestname>
<mycall>K1XM</mycall>
<band>20</band>
<txfreq>1400200</txfreq>
<operator></operator>
<mode>CW</mode>
<call>E7DX</call>
<countryprefix>E7</countryprefix>
<wpxprefix>E7</wpxprefix>
<azimuth>54</azimuth>
<distance>6824</distance>
<stationid></stationid>
<stationtype>R</stationtype>
<period>1</period>
<reason>SpaceOrTab</reason>
</lookupinfo>
</pre>

===Spot===

Sent for every incoming spot from the DX cluster that is valid for the current contest.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| Application sending the message.
|-
| StationName
| The station issuing the broadcast.
|-
| dxcall
| The callsign of the spotted station.
|-
| frequency
| Frequency in kHz with decimal sign of the PC's current locale. (sic)
|-
| spottercall
| The callsign of the spotter. Station name if locally spotted or result of a logging operation.
|-
| timestamp
| Spot time in format yyyy-MM-dd HH:mm:ss
|-
| action
| add or delete.
|-
| mode
| actual or guessed mode of the spot in capitals.
|-
| comment
| The comment section of the spot.
|-
| status
| Spot status. Valid values are "dupe", "double mult", "single mult", and "new qso".
|-
| statuslist
| Same as status
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<spot>
<app>DXLog.net</app>
<StationName>CONTEST-PC</StationName>
<dxcall>E7DX</dxcall>
<frequency>14022.3</frequency>
<spottercall>SM7IUN-#</spottercall>
<timestamp>2O23-07-15 14:29:37</timestamp>
<action>add</action>
<mode>CW</mode>
<comment>CW 31 DB 42 WPM CQ</comment>
<status>single mult</status>
<statuslist>single mult</statuslist>
</spot></pre>

===Broadcast listener===

DXLog also listens for commands over UDP.

Currently only one command is implemented, <code><radio_setfrequency></code>, which is a QSY command.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| Application sending the command
|-
| radionr
| The radio to be changed. In SO2V radio 2 means VFO B. Optional as of DXLog 2.5.20.
|-
| frequency
| Requested frequency. Both period and comma is accepted as decimal separator.
|-
| mousebutton
| Which mouse button was used to create message, if any. Optional.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<radio_setfrequency>
<app>WaterfallBandmap</app>
<radionr>1</radionr>
<frequency>21022.194</frequency>
<mousebutton>Left</mousebutton>
</radio_setfrequency>
</pre>

==SDR integration==

===HDSDR, OmniRig, and microHAM===

''Contributed by Ingo SM5AJV/SE5E''

Until DXLog offers SDR integration there are still ways to get a waterfall/spectrum display with DXLog.

I have integrated the free SDR software [http://www.hdsdr.de/ HDSDR] with DXLog using
[http://www.microham.com Microham Device Router], 
[http://dxatlas.com/OmniRig/ OmniRig]
and [https://www.autohotkey.com/ AutoHotkey].

As illustrated below I place the HDSDR window at the very top of the desktop with DXLog right below.

I share my transceiver's (an Elecraft K3) antenna with the SDR. The receiver antenna signal from my 
K3's RX-ANT OUT is connected to the input of a 3dB power splitter. The two outputs from the splitter 
are connected RX-ANT IN on the K3 and the SDR Receiver antenna input, respectively. On a K3 you 
need to enable the RX-antenna input to make this to work. An additional benefit with this method 
is that the SDR is protected during transmission. It is a widely used method and is e.g. described 
by Bob N6TV in this
[http://dxlog.net/sw/files/utilities/Adding%20an%20SDR%20to%20an%20SO2R%20Station.pdf presentation].

'''Screenshot of my desktop:

[[Image:Sdrdesktop.png|800px]]

Since both DXLog and HDSDR need to communicate with the radio, you need to "split" 
the CAT communication. microHAM's USB Device Router provides a second, independent, 
CAT port that can be used via HDSDR's omniRig interface.

'''"PORT" Tab on microHamRouter:

[[Image:Sdrmicrohamrouter.png|800px]]

'''OmniRig settings in HDSDR:

[[Image:Sdromnirig.png|200px]]

With this set up, the radio, DxLog, and HDSDR will be fully synchronized. For instance, you can 
click in the waterfall to make the radio QSY, and it is easy to quickly find a clean frequency.

To make the integration even better I use a small AutoHotkey script. The script pulls entry focus 
back to DxLog after clicking on the HDSDR waterfall and in DXLog it allows you to use hotkeys to 
control HDSDR. <code>[Ctrl][Alt]+</code> and <code>[Ctrl][Alt]-</code> zooms the waterfall/spectrum 
in and out, and <code>[Ctrl][Alt]C</code> centers it.

'''AutoHotkey script:

SetTitleMatchMode, 2
#InstallKeybdHook
#IfWinActive, HDSDR
{
F4:: return ; disable F4
~LButton Up::
sleep, 1
Winactivate, DXLog
return
}
#IfWinActive, DXLog
{
^!+:: ControlSend ,, ^{+}, HDSDR
^!-:: ControlSend ,, ^{-}, HDSDR
^!c:: ControlSend ,, {c}, HDSDR
}

The script can be downloaded [http://DXLog/sw/files/utilities/dxlog_hdsr.ahk here].

If you start two instances of HDSDR with two different SDR you can even have two waterfalls 
running at the same time.

I have not yet found a way to display cluster spots in the HDSDR spectrum panel. 
But I still find it very useful to check band activity and it allows me to easily find 
a new Run frequency on a crowded band.

===Waterfall Bandmap===

The free waterfall/spot display utility "Waterfall Bandmap" by Steve N2IC is supported by DXLog.

Waterfall Bandmap supports almost any SDR that produce I/Q output either via ExtIO.DLL or a 
sound card; SDRPlay, FunCubeProPlus, HackRF, SDR-IQ, RTLSDR, SoftRock, etc.

A zip file with an executable binary and a Microsoft word document with installation and 
configuration instructions can be found here: https://groups.io/g/waterfallbandmap/files

If you are not a member of the support forum group, you need to apply for membership to download. 
Membership is free.

[[Image:Waterfallbandmap.png]]

The SDR can be connected either to a separate receive antenna, an external receiver output on 
your transceiver or to an IF output, should your transceiver have one. If connected to an antenna, 
keep in mind that you may need protection from the transmitter such as a T/R relay or a passive level limiter.

Please refer to Waterfall Bandmap's documentation for setting it up with your SDR.

Waterfall Bandmap needs two information feeds over UDP: Radio information and spot information. 
Both are provided as UDP broadcast by DXLog.

The default port for both is 13063 and this needs to be set in DXLog's Network configuration panel. 
If Waterfall Bandmap runs on the same computer as DXLog, the broadcast address can be left at the default 127.0.0.1.

[[Image:Setbroadcastportsforwfbandmap.png]]

Clicking on the waterfall display can set the frequency of DXLog. (Left click sets VFO A, right click sets VFO B.) 
To enable this functionality, check the option <code>Options|Broadcast|Receive Broadcasts</code> 
Also make sure "UDP broadcast listener" includes port 13064 in the network settings panel.

The radio information feed needs to be enabled by checking the <code>Options|Broadcast|Radio information</code> option

[[Image:radiobroadcastenable2.png]]

and the spot feed needs to be enabled by checking the <code>Options|DX Cluster|Send spots to SmartSDR</code> option.

[[Image:Enablesendspotstosmartsdr.png]]

==Time synchronization==

In a multi-station setting, the time needs to be accurately synchronized across all networked PC.

Windows' built in time synchronization is very crude and for a PC with poor clock stability the 
inaccuracy of the clock may be up to a minute. Which of course is not acceptable for contesting.

DXLog has built in support for time synchronization as described in the [[Menu Options#Configure network|Configure network section]].

Due to Windows' security system, this however requires all except the PC running as time server to 
run DXLog with elevated permissions. There is unfortunately no way around this inconvenience.

An equally accurate and less intrusive method is to use a standalone time synchronization application on each networked PC. 
This will keep each PC's clock accurate within a fraction of a second.

Contrary to a solution built into a logger it also has the great benefit of being an "install and forget" solution.

A popular application is Dimension 4 by Thinking Man Software. It is free for personal use and 
can be downloaded here: https://dxlog.net/sw/files/utilities/d4time531.msi

It runs in the background and only shows up as a tiny icon in your system tray. 
You hover the mouse above the icon to check status and right-click to open and change settings.

:::[[image:dimension4tray.png|50px]]

After installation a brief configuration is required.

First of all, allow the application to disable Windows' time service and to modify your system clock.

For maximum accuracy, select a time server geographically close to your location. 
When in doubt, you can always add the global server "pool.ntp.org" to the list and use that. 

There are also national and continental pools of time servers. You can find them here https://www.ntppool.org.

[[image:dimension4b.png]]

Make sure the check boxes "Load Dimension 4 at startup", "Start minimized", "Hide when minimized", 
and "Display icon in tray" are all checked.

[[image:dimension4advanced.png]]

Click the Advanced button and also make sure the option "Use the selected server" is selected.

Make sure the application reports a successful connection to the selected time server. 
From here on, you can basically forget the application. 
It will silently start with your PC and always keep its time accurate.

==Disabling USB power management==

In the interest of saving energy, Windows habitually power down USB interfaces 
when it believes there is inactivity. Some USB-to-serial and USB audio devices 
respond poorly to being suspended or powered down so as a rule this "feature" should 
be disabled when used in a ham radio environment.

There are two places where this functionality needs to be disabled; the device driver 
and Windows' energy management.

To disable it for each USB interface and device, open Windows settings. (Click the Windows 
icon in the lower left corner and then chose the cogwheel.) Type ''device manager'' and
select the result.

[[image:devicemanager-c.png|none|frame]]

This opens up a new window, Windows' Device Manager.

[[image:devicemanager2b.png|none|frame]]

For '''every''' USB interface component (there may be many), COM-port, and audio device, 
and '''uncheck''' the option ''Allow the computer to turn this device off to save power''.

The devices you are looking for are in the categories: ''Ports (COM & LPT)'', 
''Sound, video and game controllers'', ''Universal serial bus controllers'',

Note that some devices may not have a ''Power Management'' tab.

[[image:usbdevicemanager.png|none|frame]]

The next step is to disable Windows ''Selective suspend'' feature for USB interfaces.

Go back to Windows Settings and type ''edit power'', click the appearing ''Edit power plan'' menu entry.

[[image:editpowerplan2.png|none|frame]]

This should open the window below, the plan editing panel.

[[image:editplansettings.png|none|frame]]

Click ''Change advanced power settings''. Scroll down to ''USB settings'' and make 
sure ''USB selective suspend setting'' is '''disabled''' for all situations.

[[image:Advancedsettings.png|none|frame]]

To prevent audio devices from becoming unreachable or going into sleep mode you should also 
disable exclusive access. While changing this, also make sure all audio enhancements are disabled.

You reach the detailed audio device settings by entering Windows settings, search for Control panel, 
and in the Control panel view, select Hardware and audio, and then Sound.

[[image:Audiodevice.png]]

Reboot your computer to make sure all settings are recognized by Windows.

==Interlock and inband operation==

In contest station terminology, the term ''Interlock'' refers to a technical solution preventing 
more than one station from using a shared resource, typically an antenna, at the same time.

The most common use for interlock is for inband operation. Inband operation means to have multiple 
transmitters on a single band, interleaving their transmissions. Sometimes on a split-second basis.

As long as you never have more than one transmitter active at any time, the majority of contests allow 
an unlimited number of transmitters and receivers on a single band for multi-operator categories. 
This fact is used by most big contest stations.

For an inband solution to be effective, each station must be able to receive while the 
other station transmits. This means it requires a separate, high performance receive antenna 
with very good isolation from the transmitter antenna. The most common way to 
achieve this is physical separation and geographic orientation to minimize the situations 
when they will radiate/listen in the direction of the other antenna.

For a station operating in the M/M, M/S, or M/2 category, inband operation can boost the points 
per hour performance significantly. It is also a lot more fun.

However, as with everything else, it comes at a cost. An efficient inband solution has:

* A high performance receive antenna for each operated band(s) with very good isolation from the transmitter antenna.
* A fail-safe antenna switching hardware.
* Interlock-capable keyers and/or station controllers.
* An interlock-capable contest logging software

A typical inband configuration can be seen in the illustration below.

[[image:inbandconcept-trx.jpg|800px]]

DXLog offers a software-based interlock which can be configured in a variety of ways, e.g. based on frequency 
band, operating mode, or station role. It supports an unlimited number of stations interlocking each other 
using a great variety of strategies.

The interlock relies on UDP networking and is overlaid on the communication for multi-station logging. 
UDP networking has the benefit of speed and low latency but is, unlike TCP, susceptible to packet loss. 
This means that a '''wired LAN''' is a necessity for any station using interlock. 
For the same reason, it is also not recommended to run interlock over e.g. VLAN/VPN link for 
geographically distributed stations.

A software interlock is not 100% reliable. Computer or software malfunction, networking issues such as packet 
loss, etc. can cause interlock to fail, even if only momentarily.

For this reason it is necessary to also accompany a software interlock with a fail-safe '''hardware''' interlock. 
Without hardware supported interlock you run the risk of not only violating contest rules but also cause serious equipment damage. 
Some contests, such as CQ WW, explicitly requires hardware interlock when using multiple stations on the same band.

There are many designs and even commercial products available for hardware interlock. 
One example of a simple but effective two station hardware interlock which also supports 
power amplifier sharing can be found [https://sm7iun.se/contest/inband/ HERE].

The purpose of this section is to describe steps of setting up a basic two station in-band solution with 
DXLog and microHAM keyers. The microHAM keyers are not mandatory but offers a much better user experience 
and removes the need for additional hardware.

'''Pro tip:''' Consider checking <code>Options|Networking|Allow other stations to abort sending</code> 
which will allow your partner station to interrupt your transmission with <code>[Shift][Esc]</code> in 
critical situations. Be careful though, the use of this function requires good judgment to avoid violence.

===Networking===

Open the networking configuration panel with <code>Options|Configure network</code> and make sure each 
station has a unique name and that only UDP networking is enabled.

Make sure the two stations use the same broadcast IP address and that it is in line with your LAN's 
configuration. Pressing the <tt>Default</tt> button is a good way to ensure this.

Make sure the menu option <code>Options|Enable network</code> has a checkmark.

[[image:inbandnetworkrun.png|left|frame]][[image:inbandnetworkinband.png|none|frame]] 

===DXLog Interlock configuration===

First of all, make sure that the <code>Options|Interface specific options|Prevent TX if another radio is on same band</code> 
is '''not''' enabled. This option completely prevents transmission if more than one networked station is set to the same band 
and the whole idea with inband is to have exactly that.

Next, activate software interlock on both stations using the menu option <code>Options|Networking|Software interlock</code> 
or by typing the commmand <tt>ILOCKON</tt>.

[[image:inbandinterlock2.png|none|frame]]

There are multiple options for configuring the interlock. In a simple set up with only two stations, the topmost 
option ''Same band from status list'' is a good choice. This option will prevent more than one station transmitting 
on the same band, regardless of mode.

In an environment with many stations (such as a multi-operator-multi-transmitter station) it is 
recommended to use the bottom option to only interlock with one or several named stations. 
This will reduce both LAN traffic and inband operation latency. This is particularly important when 
running parts of the DXLog network over high latency links such as VLAN/VPN or if some stations (albeit not 
part of the interlock cluster) are connected via Wi-Fi.

For more advanced scenarios you can also use interlock based on mode or station type (e.g. Run 1, Run 2, Mult, etc.).

The "status list" listing the networked DXLog stations is displayed in the ''Status Window'' which is opened 
with <code>Windows|Status window</code> or <code>[Alt][J]</code>.

[[image:inbandstatuslist2.png]]

DXLog also offers great flexibility when it comes to interlock strategy. The most straightforward and 
most commonly used is ''First one wins''. This is also typically the behavior of "unintelligent" 
hardware solutions when not assisted by software. With this strategy, the station starting to transmit 
first can not be interrupted and always gets to finish its transmission.

[[image:inbandinterlockoptions.png]]

With a ''Last one wins'' strategy, the transmitting station can be interrupted. A carte blanche permission 
to interrupt all transmissions by the other station may however be counterproductive in a real contest situation.

For this reason, DXLog offers additional control of which transmit actions can be interrupted and which can not. 
This is a powerful tool but requires both operators to be aware of it and may require 
practice before fully effective.

[[image:inbandstrategyexceptions.png]]

''F1'' through ''F7'', ''PLUS'' and ''INS'' refers to DXLog's standard messages. ''KEYB'' means a free text transmission 
from the keyboard using the <code>[Alt][K]</code> function and ''MAN'' means manual transmission using either paddle 
break-in or a footswitch.

For CW, DXLog recognizes paddle break in from a K1EL Winkey-compatible keyer as described in the [[Menu_Options#Winkey_Configuration|Winkey configuration section]].

Since DXLog recognizes a footswitch connected to a microHAM device, this is a recommended approach for phone. 
It is also possible to connect a footswitch to the DSR pin (pin 6) on a physical COM-port on the PC, but today 
few PC have such a port and it also requires additional circuitry.
Details on how to do this is available [[Additional_Information#Connecting_a_footswitch|HERE]].

===microHAM configuration===

Open the microHAM device configuration panel with <code>Options|microHAM device configuration</code>.

[[image:Mk2r-new9.png|none|frame]]

Check the option ''Enable TX lock/unlock''. This will do two things; it will enable DXLog to prevent 
transmission and and it will make DXLog aware of the microHAM device's PTT status. The latter is particularly 
important since it means DXLog will recognize PTT assertion not only by a footswitch connected to the 
microHAM device but also by the built-in Winkeyer (requires microHAM USB Device Router version 9.3.0 or later) 
'''Paddle-based break-in in an inband solution is currently unique for microHAM with DXLog.'''

'''Important:''' Making DXLog "PTT aware" means that care has to be taken in how PTT is set up. If you, for instance, 
enable DXLog PTT for the voice keyer, this will create a self-reinforcing feedback loop and PTT will thus never drop.

Check the option ''Dual radio device'' if you are using a u2R, MK2R, or MK2R+, otherwise, leave this unchecked.

Check the option ''Device without CAT interface'' if the device lacks a CAT interface (like the u2R) 
or if its CAT interface is not connected to the radio. This option will make sure the e.g. keying and 
audio routing is always set correctly in line with the operating mode (Voice, CW, or RTTY).

===Operating===

Inband operation requires a fair amount of training and it is a good idea to define and agree 
on general rules for operation, such as hand signals for challenging QSO, beforehand.

There are more than enough YouTube videos of inband operators yelling at each other.

The operating tactics may have to be adjusted during the contest. If Run is slow, 
doing S&P on the inband station can increase the points per minute significantly. 
However, if Run is strong, an overly active inband operator doing S&P, but not working 
multipliers, may actually reduce the station's points per minute significantly.

Real-time interlock status is shown in the ''Radio status'' window, which is opened with 
<code>Windows|Radio status</code>.

[[image:inbandblocking.png]] [[image:inbandblocked.png]]

For Phone contesting, you typically rely on footswitches for PTT and the option 
<code>Options|Networking|Show QSO status when blocking</code> makes the blocking 
station send a more helpful blocking cause than ''MAN''.

With this option enabled, the blocking station will instead send ''CQ'', ''QSO'', or ''EXCHANGE'' 
as blocking cause, determined by cursor location and entry field content at the locking station.

Further reading can be found in the [[Menu_Options#microHAM_device_configuration|microHAM device configuration]] and [[Menu_Options#Networking|Networking]] sections.

==Connecting a footswitch==

To free up both hands in Phone contesting, a footswitch PTT is a great help.

Also, to use interlock in Phone contesting, a footswitch is mandatory.

There are two basic ways to interface a footswitch with DXLog; via a microHAM device (which is the recommended solution) 
or directly connected to a physical serial port on the PC (which very few PC have today).

The connection of a footswitch to a microHAM device is very straightforward and by checking the ''Enable TX lock/unlock'' 
in the ''microHAM device configuration'' panel, it is recognized by DXLog.

Lacking a microHAM device, it is also possible to use the computer's DB9 RS-232 serial port connector, providing it has one.

The required steps to do this are:
* Connect a 10k resistor between DB9 pin 6 and pin 7.
* In the port's settings (<code>Options|Configure interfaces</code>) set DTR (pin 4) to ''Always On'' and RTS (pin 7) to ''Always Off'' for the port.
* Connect the footswitch between DB9 pins 4 and pin 6. '''Important:''' Neither pole on the footswitch must be connected to ground.
* In the radio's configuration panel, check ''use CAT PTT command on Phone'' and set ''Footswitch (pin 6)'' to ''PTT''

==Support for CC Cluster==

CC Cluster is today the main choice for contest use.

It offers a high quality, database-verified, flow of skimmer spots and a rapid 3-minute respotting period for skimmer spots.

It also publishes unique spots from less common locations which are valuable for DX chasers or as contest multipliers.

To make use of the display of own spot in the world map, make sure to issue the command '''<tt>SET/OWN</tt>''' to the cluster node. 
This setting is persistent and only needs to be done once.

A list of cluster nodes that runs CC Cluster can be found here: [https://www.dxcluster.info/telnet/index.php?software=CC%20Cluster CC Cluster nodes]

A description of the command line syntax can be found here: [http://bcdxc.org/ve7cc/ccc/CCC_Commands.htm CC Cluster command syntax]

A convenient software for setting up filters etc. can be found here [http://www.bcdxc.org/ve7cc/default.htm#prog CC User]

[[Image:Ccclustersspotflow.png]]

==Support for AR Cluster 6==

With the author tragically SK, AR Cluster is no longer under development but still available as an executable binary.

In its standard configuration, AR Cluster offers no consolidation of skimmer spots meaning a very high flow of spots 
that can become extreme during a major contest weekend.

With the advent of skimmers, the traffic on the DX Cluster has risen dramatically. Even though CW skimmers are generally 
quite reliable, the absolute number of busted spots can be quite high during a busy contest.

Jose CT1BOH has developed an algorithm for evaluating spot quality which is included in version 6 of AR Cluster. 
Today many cluster nodes runs this version and thereby offer this mechanic. 
A complete list can be found here: [http://www.dxcluster.info/telnet/index.php?software=AR-Cluster AR Cluster nodes]

To enable the functionality on a cluster node running AR Cluster 6, the command

<tt>'''SET DX EXTENSION SKIMMERQUALITY'''</tt>

needs to be issued to the cluster node. The easiest way to do this in DXLog is via <code>[Alt][T]</code>. 
This setting will be remembered at subsequent logins.

The quality of the spots is indicated by a character ("tag") in the last column of the comment field and, 
in some cases, a corrected callsign within parenthesis. This syntax is recognized by DXLog and can reduce the 
number of bad spots in your bandmap.

The CT1BOH skimmer quality algorithm is based on three parts:

; Validation : When a callsign is first spotted, it is tagged with "?" in the last column of the spot's comment field. If the callsign of an unverified spot closely resembles an already verified one on the same frequency, the verified callsign is provided within parenthesis in the spot's comment field. When two or more skimmers agree on the spot, it is considered verified and the tag becomes "V".

; Frequency : When a verified spot appears more than 0.35kHz off its verified frequency, the spot is tagged "Q" for QSY. Once verified, this becomes the new verified frequency and it is tagged "V".

; Probability : The algorithm checks uncertain spots for resemblance with already verified spots and spots at or near the same frequency. If the resemblance is high enough, the spot is considered busted "B" and the corrected callsign is provided within parenthesis in the spot's comment field.

Below you can see an example of the spot flow from W9PA-4 with skimmer quality enabled. 
The flow contains one unverified and one busted spot.

[[image:spotquality.png]]

DXLog's policy for spots with CT1BOH skimmer quality tags is the following:

: '''V''' - Accept spot.
: '''Q''' - Accept spot.
: '''?''' - Accept spot. Use corrected call when provided.
: '''B''' - Accept spot if corrected call provided. Else ignore.

DXLog recognizes the skimmer quality tags but consolidates them for consistency 
with other cluster nodes' quality tags and to minimize confusion when mixing spot flows. 
The legend is:

: '''?''' means a spot with ? This is an unreliable spot.
: '''P''' means a spot with Q or B with correction. This is a fairly reliable spot.
: '''V''' means a spot with V. This spot is considered validated.

This basic policy can be modified by using additional filters at the cluster node end. Some examples are:

: <tt>'''SET DX FILTER NOT SKIMBUSTED'''</tt> - Do not send busted spots at all
: <tt>'''SET DX FILTER NOT SKIMQSY'''</tt> - Do not send QSY spots
: <tt>'''SET DX FILTER SKIMVALID'''</tt> - Only send verified spots
: <tt>'''SET DX FILTER NOT SKIMUNKNOWN'''</tt> - Do not send unreliable spots
: <tt>'''SET DX FILTER SKIMMER'''</tt> - Do not send manual spots

You can also compose more complex filters such as:

: <tt>'''SET DX FILTER SKIMVALID OR SKIMBUSTED OR NOT SKIMMER'''</tt>

This can be a good filter for most contests. It will will only provide valid or busted skimmer spots together with manual spots. 
It is safe to receive busted spots since DXLog will ignore them if there is no corrected callsign included. 

For assisted operation in serious contesting you however need to allow also unknown spots since weak stations spotted 
only by one or a few skimmers may never reach validated status. You do this by adding <tt>'''OR SKIMUNKNOWN'''</tt> to the filter.

Both the bandmap and the DX cluster announcement windows have the option to display the spot quality tag. 
These windows will show two additional tags; L and C. L stands for local spot, created by yourself or one of your team members. 
C stands for corrected, i.e., a B or ? spot where a corrected call has been included in the spot's comment field.

The AR6 filtering syntax offers a lot of flexibility. Another example:

: <tt>'''SET DX FILTER (SKIMVALID OR NOT SKIMMER OR ((SKIMQSY OR SKIMUNKNOWN) AND (CTY <> K AND CONT <> EU )))'''</tt>

will provide only validated and human spots except if they are from outside the US and EU.

If you get lost in the filter settings you can always reset with : <tt>'''SET DX DEFAULT'''</tt>.

Some more guidance on how to work with filters on AR-Cluster nodes can be found in [http://dxlog.net/sw/files/utilities/AR_Cluster_v6_User_Manual.pdf this document].

==Support for DXSpider==

DXSpider is the most dominant DX cluster software but has historically not been a 
good choice for contesters. The reasons for this include: Long respotting time, lack 
of pass function for own spots, and suppression of spots from a single skimmer.

The good news is however that the author Dirk G1TLH has worked hard to address these 
aspects of the otherwise brilliant software.

From '''version 1.57 release 440''' the respotting time is now 3 minutes and there is a 
<tt>SET/SEEME</tt> command that passes all spots without consolidation of your own callsign.

So if your favorite cluster node is not running this version, ask the owner to upgrade asap.

Yet another reason for its popularity is its extreme resource-efficiency which allows it to run 
virtually any Linux capable hardware, including a $20 Raspberry Pi Zero.

A list of all DX cluster nodes running DX Spider can be found here: [https://www.dxcluster.info/telnet/index.php?software=DX%20Spider DX Spider cluster nodes]

[[image:dxspiderflow.png]]

DXLog recognizes the <tt>Q:#</tt> skimmer quality tag in the comment field and converts them into 
"CT1BOH-like" quality tags that can be displayed in DXLog's bandmap. The legend is:

: '''?''' means a spot with Q:1, i.e. heard by only one skimmer. This is an unreliable spot.
: '''P''' means a spot with Q:2, i.e. heard by only two skimmers. This is a fairly reliable spot.
: '''V''' means a spot with Q:3 or higher, i.e. heard by several skimmers. This spot is considered validated.

Since a DXSpider node currently needs to be specially configured by the owner to publish Q:1 spots, very few do this. 
Also, since DXSpider lacks busted call detection, the the quality of the spot flow will suffer if this is done.

A typical cluster line looks like this:

'''<tt><nowiki>DX de PY2MKU-# 14065.0 SM7IUN CW 29dB Q:9* Z:14,15,20 1922Z</nowiki></tt>'''

The Q parameter is the number of skimmers spotting the call. The trailing star means they do not quite agree 
on the frequency. A trailing plus means the station has been spotted for more than one hour. The Z parameter 
lists the CQ zones in which the callsign is spotted.

There is a wealth of information to be found on the [http://wiki.dxcluster.org/index.php/Main_Page DXSpider wiki].

==Support for N2WQ Cluster==

Introduced in late 2025, Rudy N2WQ has developed the first new DX cluster node software in decades.

The N2WQ-2 cluster has some unique features like a more advanced callsign validation than 
AR 6 and propagation estimation tags embedded in the spot comments. An example can be seen below.

[[image:n2wpspotflow.png]]

When you connect to dxc.n2wq.com port 8300 and you have set your 4-digit Maidenhead grid (SET GRID), there 
will be a single character just before the DX’s grid locator. This character is the path prediction glyph.

It is a crowdsourced, real-time estimate of how reliable the path is between you and the DX on that band right now, 
based on recent on-air propagation reports from RBN and PSKreporter. Its values and meaning are:

: > High: Strong path. If you can hear them, you should be able to work them.
: = Medium: Decent path. Workable with normal contest/DX technique.
: < Low: Weak path. Possible, but expect repeats, timing, and patience.
: - Unlikely: Marginal. Try only if it’s rare/needed, or you have a strong station advantage.

A missing glyph means insufficient data to estimate the path.

the glyph is mode-aware. A path that looks great for a very sensitive mode (FT8) can look 
more moderate for a less sensitive one (SSB).

You can filter spots by path reliability using the PASS/REJECT PATH command.

It is important to be aware that the glyph does not know:

: Your antenna gain/pattern, height, or takeoff angle
: Your transmit power and duty cycle constraints
: Your operating technique (timing, split discipline, pileup strategy)
: Short-lived phenomena the network has not yet “seen” such as sporadic E or aurora.

The cluster ingests upwards of 50,000 CW, FT, RTTY, and WSPR spots per minute. To compare different modes 
fairly, the system normalizes reports onto a common “FT8-equivalent” scale (so a CW SNR can be compared 
to an FT8 SNR).

Your grid and the DX grid are mapped into small geographic cells and the cluster calculates propagation 
at two levels:

: Fine (local): what’s happening close to your area (~180 miles).
:: On averages there are about 90,000 DE/DX pairs being tracked
: Coarse (regional): what’s happening in the broader region around
:: you (~480 miles). On average, there are about 30,000 DE/DX pairs.

If there isn’t enough local data, the system leans more on regional behavior. 
If there’s plenty of local data, it uses that more heavily.

Sometimes you can hear them better than they can hear you (or the reverse) due to noise 
floors, antennas, geography, or ionospheric effects. The system tracks both:

: Receive direction: DX to you (can you hear them?)
: Transmit direction: you to DX (can they hear you?)

It combines these into one “path reliability” estimate, weighting receive a bit more 
because if you can’t hear them, you can’t work them.

Propagation changes fast, so older reports get discounted using a half-life (data fades 
in influence over time). Typical behavior by band:

: Low bands (160/80m): slower changes (longer half-life)
: Mid bands (40–20m): medium pace
: High bands (15–6m): fast changes (shorter half-life)

In practice, this means glyphs can shift in minutes on 10m/6m, and more slowly on 80m/160m. 
Also, new openings take time to show up. A "insufficient" can simply mean “the path just opened 
and the cluster hasn’t collected enough recent reports yet.”

Your local noise floor heavily affects what you can receive, so the cluster lets you tell 
it what your noise environment is. This mainly tunes the receive-side expectation (DX to you).

Set it with SET NOISE SUBURBAN. Available profiles per ITU:

: QUIET: very low noise, rural/remote
: RURAL: mild noise
: SUBURBAN: typical neighborhood QRM
: URBAN: elevated noise, dense housing
: INDUSTRIAL: severe noise

If you don’t set it, the system may assume a quieter environment than you actually 
have, and your receive-side glyphs can look too optimistic.

Treat the glyph as a real-time probability hint that helps you spend your operating 
time where the odds are best. When you see > on a needed multiplier, move fast. 
When you see -, be intentional about whether it’s worth the time. 
And when you see a space, fall back to classic DX/contest instincts and your own ears.

The N2WQ cluster also offers spot quality tags between the DX grid and the time.

A quality (in terms of callsign reliability) tag can be V, P, S, C, or ? where V means validated, 
P highly likely, S less likely, C corrected, and ? unsure.

The propagation and quality tags can be displayed in the bandmaps and the DX cluster announcement window.

DXLog recognizes the skimmer quality tags but consolidates them before display for consistency 
with other cluster nodes' quality tags and to minimize confusion when mixing spot flows. 
The legend is:

: '''?''' means a spot with ? or S. This is an unreliable spot.
: '''P''' means a spot with P or C. This is a fairly reliable spot.
: '''V''' means a spot with V. This spot is considered verified.

==Interacting with WSJT-X==

Important: When in a DXpedition/multi-station setting, always use local host 127.0.0.1 as the 
broadcast address to prevent packets being picked up by other stations in the network. 
Also, enabling the creation of local spots from decodes may overwhelm DXLog.

DXLog can add QSO performed with WSJT-X to its log. Note that this functionality only works 
for contests with grid as the first and only exchange or for DXPedition type logs.

DXLog can also create local spots from WSJT-X decodes by checking 
<code>Options|Broadcast|Spot WSJT-X decodes</code>.

To enable logging of WSJT-X QSO, set up WSJT-X to broadcast information:

[[image:Wsjt-x-udp.png]]

[[image:Radiobroadcastenable3.png]]

Activate DXLog's UDP listener by checking <code>Options|Broadcast|Receive broadcasts</code> and set 
the same port number as in WSTJ-X in DXLog's network configuration panel.

[[image:Dxlog-udp.png]]

==Using Winkey FSK==

Winkey FSK is not natively supported by DXLog's digital mode engines MMVARI or MMTTY but 
Rafal EI6LA has developed a plugin for MMTTY that makes this possible.

You can find it [https://github.com/RafalLukawiecki/WinKeyerMMTY here].

==Interfacing with LogHX==

Christian F8GHE has prepared a guide on how to do this.

You can find it [http://dxlog.net/sw/files/utilities/DXLOG-LogHX_UDP-config_v2.pdf here].

==Self-spotting==

More and more contests allow spotting your own station on the DX cluster.

DXLog supports this, even when operating unassisted, as long as you connect to the cluster.

DXLog has three mechanics for self-spotting.

DXLog blocks self spotting unless specifically allowed in the contest rules. 
Should you find that DXLog incorrectly allows or blocks self-spotting, please make 
the development team aware via the support reflector.

* The <tt>$SPOTME</tt> macro command. This macro will create a cluster spot of the station's
: call at the earliest 15 seconds after being invoked the first time on a new frequency.
: Thereafter it will spot as frequent as allowed by the contest. If the contest rules do not
: specify a minimum period, 10 minutes will be used.

* Checking the menu option <code>Tools|Data entry|Run F1 message self-spots when permitted</code>.
: Works exactly like the <tt>$SPOTME</tt> macro command but is triggered by sending the
: Run F1 message which happens when pressing <code>[Enter]</code> with an empty entry line
: in Run, pressing <code>[F1]</code> in Run, or with Auto-CQ.

* Clicking the menu item <code>Commands|Self-spot</code> or pressing its shortcut key <code>[Ctrl][S]</code>.
: This will immediately create a spot of the station's call but no more often than
: every two seconds to avoid accidental multiple spots.

==DXpedition use==

DXLog is a popular choice for top tier dxpeditions. Below we have collected advice based on experience 
on how to best use DXLog in a dxpedition setting.

* Use client/server networking between stations. Never use UDP over Wi-Fi or WAN links.
* Use the "Minimal data" option in ADIF export to save on satellite link cost.
* For Club Log real time upload, use [https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads Club Log's upload app]
* Club Log truncate QSO time to minutes so to avoid creating dupes when mixing manual and real time upload to Club Log, check ''QSO time in minutes'' when doing ADIF export.
* Use the "Minimal data" option in ADIF export to save on satellite link cost.
* Follow [[Additional_Information#Interacting_with_WSJT-X|the instructions]] to log QSO made with WSJT-X and MSHV.
* Check <code>Options|Broadcast|Spot WSJT-X decodes</code> to make decoded calls appear in e.g., DX cluster announcements.
* You can extend the number of digits in the QSO count with <code>Options|Log|QSO number digits</code>

==Beacon spots on DX cluster==

Although propagation measurements based on FT8 communications has reduced the 
value of beacons, there are still hundreds of them in operation.

Identifying with CW, they are typically reported on reported on the DX cluster.

When beacon spots are received by DXLog, they are always displayed in the bandmap. 
In DXLog, beacon spots are recognized by having a trailing <tt>/B</tt>.

The DX cluster announcement window never shows or counts beacon spots.

Beacon spots can be enabled and disabled in the cluster node.

For CC Cluster, the commands are <tt>SET/BEACON</tt> and <tt>UNSET/BEACON</tt>.

For DXSpider, command is part of the <tt>SET/SKIMMER</tt> command where <tt>SET/SKIMMER</tt> 
or e.g., <tt>SET/SKIMMER CW BCN FT RTTY</tt> will pass beacon spots and <tt>UNSET/SKIMMER</tt> 
or any <tt>SET/SKIMMER</tt> listing modes but not BCN will block them.

AR 6 cluster nodes always pass beacon spots when skimmer spots are enabled. They cannot be disabled.

==Using Piper text-to-speech synthesis==

James M0DST has prepared 7 sample scripts that can be mapped to F keys.

James' comments on the scripts are:

This is just an extended proof of concept. Feel free to play using your own scripts. 
There is a lot of code duplication across the scripts. I may simplify some of this in the future. 
I tried base classes, but the current script engine would need some rework to support that. 
Repeat isn't supported. You will need to press the key manually. 
Multiple op voices are not supported currently. You could hack this in with little effort. 
There is no documentation at present. This feature is experimental whilst I decide how I want 
to move it forward (if at all). If you want to adjust the speed, you can do it per script. 
See SpeakingRate in the F2 script. Lower number is faster.

You can visit https://rhasspy.github.io/piper-samples/ to hear the voices. Set the model in the script.

Any comments or thoughts on anything related to this should be sent to me directly or on the list.

I really suggest training your own voice. I haven't done it yet, but I will when I have time. 
Using common amateur radio phrases in the training data will help teach it to sound more like a ham.

If you improve the scripts, please send them to me and I will update the files behind this link. 
Once everything is stable and formalized I will pass the links to Bjorn for the website, and we 
will add some real documentation.

Experimental scripts:
[https://drive.google.com/file/d/1EhfOpxsL57yuf-1WorASnGf-SBsmfqu7/view?usp=drive_link F1]
[https://drive.google.com/file/d/1MgviBec7HCXIOJZtDZXl0qXlrU-TwMoD/view?usp=drive_link F2]
[https://drive.google.com/file/d/1yAgY5E-KdOcmToXMJQ2lRNhjBIQrJIb9/view?usp=drive_link F3]
[https://drive.google.com/file/d/1-ftWUhFlc4-quwGPIVmNujQ4q-J5E3EZ/view?usp=drive_link F4]
[https://drive.google.com/file/d/1h3C_kLl9C4CEH6kATGAZbfDkfY6KlgqB/view?usp=drive_link F5]
[https://drive.google.com/file/d/1e4tAHz-_dU92RybaFeSuLCd0V7Gk_lWy/view?usp=drive_link F6]
[https://drive.google.com/file/d/1UGxgOpqOjOzl7yFTjrVaml9m5o8gBq5y/view?usp=drive_link F7]

Additional Information

2026-04-09T17:35:38Z

Sm7iun: /* Support for DXSpider */

==Using alternative configurations==

Window positions, coloring and general look and feel is saved in each log file but all other settings such as 
radio control, keying, and networking is saved in a common, contest-independent configuration file.

By default, the configuration file name is <tt>DXLog.net.config</tt> and it is located in the <tt>%appdata%\DXLog.net</tt> configuration folder.

This folder is also reachable via the <code>File|Open configuration folder</code> menu item.

[[image:configfolder.png]]

DXLog can be made to use an alternative configuration file with the command line option <tt>-cfg=<filename></tt>.

A convenient way to use this option is to create a separate Windows desktop shortcut including the command line option 
and give it a meaningful name.

[[image:Desktopshortcut.png]]

The command line option is simply added to the end of the Target text box in the shortcut's properties. 
Double-clicking the icon will start DXLog with the alternative configuration which will also be remembered between sessions. 
In the picture below the target of the shortcut is

[[image:Desktopshortcutconfig.png]]

'''Important:''' If you want to use an alternative configuration, do not just modify the desktop shortcut created at installation 
since this shortcut will be deleted when you upgrade DXLog. Instead make a copy, rename, and add the command line option. 
You should keep the command line option outside the apostrophes, like this

<tt>"C:\Program Files (x86)\DXLog.net\DXLog.net.exe" -cfg=SO2R.config</tt>

==Using a number server==

For contests involving serial numbers you need to secure that the sent number and the (slightly later) 
logged serial numbers are the same. In a straightforward SO1R or SO2V scenario, serial numbers are simply 
chronological but in more complex station configurations such as Multi-single or Multi-2 with inband, and 
advanced SO2R, QSO can be interleaved and requires a central source source of serial numbers together 
with a mechanic to protect an already sent serial number from re-use by another radio.

In DXLog this is achieved with a central number server. A number server can be used either 
by a single instance of DXLog (for SO2R) or by multiple stations on the same LAN.

The use of a number server involves three, natural, steps:

* Activating the server on a single station
* Making sure all stations use it
* Verifying functionality, making sure serial numbers are correctly reserved

The number server is activated in the <code>Options|Configure network</code> panel, described [[Menu_Options#Configure_network|HERE]].

[[image:startnumberserver.png]]

Since the server uses a networking socket, <code>Options|Networking</code> must be enabled '''also''' when 
using a single computer in SO2R. In the case of multiple stations, UDP networking or Client-Server 
networking must also be enabled to transfer the numbers over the LAN. For SO2R, this is however not 
necessary. When using Client-Server networking, a client cannot be number server.

There must only be one number server in a local network and all stations using it must have 
<code>Options|Networking|Use number server</code> checked like in the picture below.

'''Important:''' The number client/server functionality is not very robust. 
If you have stations joining/leaving your network or being rebooted, it is 
best to restart DXLog on all stations to guarantee correct function.

[[image:usenumberserver.png]]

The option <code>Block logging if serial number reservation is unsuccessful</code> can be used as an extra precaution 
but is not necessary in SO2R since the communication with the number server does not leave the computer.

There are three methods for reserving a number from the server:

* Checking <code>Tools|Data entry|Space key reserves serial number</code> and using the space key to reserve serial numbers. This is typically used on phone or when operating "old school" with F-keys.
* Checking <code>Tools|Data entry|Insert and F2 messages reserve serial number</code> and letting DXLog automatically reserve a serial number right before $SERIAL sends it. This is the preferred and most straightforward way for CW and digital.
* Adding the $RESERVENR macro to messages like illustrated below. 

These methods can of course also be combined. 

The $RESERVENR macro is "smart" and will only reserve a serial number if the callsign entry field is not empty and a 
serial number is not already reserved. The same goes for the menu items.

[[image:reservemessages.PNG]]

The sign of a serial number being reserved is that it turns red. It then stays reserved (and red) until the 
QSO is logged or the entry line is cleared with <code>[Alt][W]</code>.

An option that can prove useful is <code>Tools|Data entry|Cancel serial number reservation only if callsign field is empty</code>. 
In the case that you send the exchange and realize you got the other station's callsign call completely wrong, a reflex can be to hit 
<code>[Alt][W]</code> and start typing. If this is your habit, this option will prevent you from releasing the 
already sent serial number, thereby avoiding you the trouble to send a new one to the other station.

[[image:reservednumber.png]]

==Networking over internet==

When, for instance, activating a special event callsign it is possible to network multiple DXLog stations over the internet.

'''Pro tip:''' Consider displaying the callsign, message ID, Message text, etc. fields in the ''Network status'' 
window when operating a distributed station. Also, learn to use the gab <code>[Alt][G]</code> and <code>[Alt][J]</code> function.

===VLAN/VPN Solution===

The most secure way for remote networking is to rely on a VLAN (virtual LAN) software. There are several available such as:

ZeroTier https://www.zerotier.com/ 
FreeLan http://www.freelan.org/ 
Player.me https://player.me/ 
OpenVPN https://openvpn.net/

Each VLAN solutions have their own particular set up which is covered in their respective documentations. 
With a VLAN solution, all DXLog configurations are the same as when operating in a regular LAN however with a few exceptions.

One weakness with connections over the internet (a.k.a. WAN), including VLAN solutions, is that they are prone to packet loss. 
Packet loss is disastrous to DXLog's (or any logger's) "standard" UDP networking.

It is therefore essential to use '''only client/server networking over a VLAN'''. 
'''This also means you should never use interlock over an internet connection unless you use a zero packet loss VPN tunnel.'''

ZeroTier is particularly popular since it is free.

Since DXLog is able to mix TCP (client/server) and UDP (peer-to-peer) networking, a distributed station set up should be configured to rely on TCP 
for the wide-area network and UDP for the local network at each station location. Below you will find the station 
set up for the Swedish HQ station SE9HQ in the 2019 IARU HF Championship. The DXLog.net.DXC cluster client was run 
on SK3W-A which distributed spots to all stations over the network. Inband interlock was also used at the SK3W location.

[[image:SE9HQ-network-eng.png|800px]]

Important to note:

* For the server as well as the main clients, ''Server IP'' should be set to the server's VLAN IP address, '''not''' its LAN address.
* The '''server''' should check both "Act as network server" and "UDP network broadcast for multiple stations".
* The '''main clients''' should check both "Connect to network server" and "UDP network broadcast for multiple stations".
* The '''sub clients''' should check only "UDP networking for multiple stations".
* Interlock (which is UDP-based) over VLAN does not work reliably because of packet loss.
: Therefore, it is important to configure any interlock to '''only''' consider relevant operating positions,
: which all must be local. Use the possibility to only consider named stations for the interlock in the software 
: interlock set up. <code>Options|Networking|Software interlock</code> "Custom station ID(s)"
* For a large set-up with many stations connecting as clients to a central server you may overload the server if you also
: distribute spots via all client-server connections. In this case, check the "No spots via client/server" option
: on all stations and use '''local DX cluster connections''' via UDP at each location.
: '''Important:''' Limitations in Windows networking makes client/server networking unreliable beyond 10 station locations.
* Make sure to check <code>Options->Load contest at startup</code> to avoid opening the wrong log after a restart.
* '''Remote commands are not forwarded''' in the network but are executed in the station where they arrive.
: Thus, to clear all logs, disconnect networking on each main client, execute the remote command CLEARLOGNOW on each main client
: to clear the logs of all sub clients and do not reconnect until the server and all other main clients have done the same.

===Port forwarding Solution===

If you are less worried about competitors or government agencies listening in on your contest data, 
it is possible to route the traffic directly over the internet using port forwarding at the server.

'''Important security notice: This solution is not without risk. It offers no security or authentication. 
Any DXLog station running the same contest configuration, knowing the URL or IP address and IP port of the 
server can connect to the server station. There are no means to disconnect a station by force.'''

Also note the comment about '''remote commands''' in the section above.

With a port forwarding solution, the following must be observed:

* '''Server configuration'''
:* Only one of the stations should be configured as the '''server'''.
:* "Connect to network server" should not be checked on this station and
:: "UDP networking for multiple stations" should only be enabled if it is used to
:: communicate with a cluster client or other stations locally on the same LAN.
:: Either use a central cluster connection (uncheck "No spots via client/server")
:: or use one cluster connection per station location (check "No spots via client/server").
:: If one cluster connection per station location is used, make sure they
:: all use different SSID to prevent disconnects, such as E7HQ-1, E7HQ-2, etc.
:: This will ensure the cluster node regards all connections as having the same callsign
:: which is essential for e.g., correctly receiving own spots.
:* The PC acting as server must be configured for a fixed LAN IP address. This is done
:: either by manually configuring the networking settings in the PC to use a fixed
:: LAN IP address, or by setting up the router in the server's LAN to to always allocate
:: the same IP address to it.
:* The internet connection used by the server PC must ''either'' have a fixed public IP address ''or''
:: use dynamic DNS. Otherwise clients will not be able to reliable connect over the internet.
:* The server's TCP/IP port (e.g., <code>9888</code>) must be forwarded to the server by the server LAN's router.
:: Only TCP traffic should be forwarded. DXLog UDP traffic is not carried well over the internet.

:: [[image:serverconfig.png|600px]]
:: '''Example configuration for server for networking over internet'''

::[[image:portforwarding.png|600px]]
::'''Example of port forwarding UI in router'''

* '''All other stations'''
:* All other PC in the multi-station set up should be set up as clients.
:* Over the internet, "Server:" is either the static, public IP address of the server's internet
:: connection (e.g. <code>5.140.211.42</code>) or the dynamic DNS address (e.g. <code>hq.sm7iun.se</code>).
:: Clients connecting over the internet does not have to enable UDP networking and ''should not''
:: enable a server.
:* A client may connect via UDP if it is on the same LAN as the server ''or'' a "main client".
:: A "main client" is a client that connects to the server using the "Connect to network server" option in
:: the networking set up panel. A "main client" acts as a UDP gateway which means that if
:: several computers on a LAN are part of the same multi station set up but the server is located
:: elsewhere, only one computer in that LAN needs to connect as a client and the rest can use UDP.
:* Software interlock is UDP-based and can only reliably be used locally. Never over the internet.
:: If used, make sure the interlock is explicitly limited to local stations. See above for more details.

::[[image:clientconfig.png|600px]]
::'''Example configuration of client for networking over internet'''

* In a multi-station setting it is recommended to enable
: <code>Options|Networking|Block standard messages if no operator is logged on</code>
* Make sure <code>Options|Enable network</code> is checked.
* It is also a very good idea to check <code>Options|Load contest at startup</code> to reduce the
: risk of the wrong contest log file being loaded by any stations.

==Real time upload to Club Log Live Stream==

'''Important:''' Club Log truncates QSO time to minutes which means that if you mix real time upload 
with manual upload, make sure to check "QSO time in minutes" when creating ADIF export files.

The author of Club Log, Michael Wall, G7VJR, has developed a very powerful agent for real time uploads. 
It works with all the three major loggers, DXLog, N1MM Logger+, and Win-Test.

It can either be used as is, with a command line user interface, or with an optional user interface front end.

Information on how to download and configure it can be found [[https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads HERE]]

The Club Log Gateway can either listen to DXLog's native multi-station networking protocol or to N1MM style XML broadcast.

To use DXLog's networking protocol, make sure the same port (default 9888) is used in the gateway and DXLog 
and that UDP networking is enabled in DXLog. Do not enable QSO broadcast.

Although this works, it is recommended to use N1MM style broadcast since it contains information like logged on operator, etc.

To use this make sure the port (default 12060) is the same in N1MM port setting in the gateway and in the 
QSO broadcast port settings in DXLog's network configuration. Also make sure to se the DXLog port number 
in the gateway is not the same as that used in DXLog to avoid QSO duplication.

Also set:

<code>Options|Broadcast|QSOs</code> 
<code>Options|Broadcast|QSOs</code> 
<code>Options|Broadcast|Use N1MM QSO format</code> 
<code>Options|Broadcast|QSO time in minutes only</code>

'''Important:''' If you are going to also upload exported ADIF files to Club Log, it is important to also 
check "QSO time in minutes" in the ADIF export configuration to avoid creating virtual dupes, since Club 
Log does not know seconds.

==Diversity reception==

Diversity means receiving the same signal through two different receive chains, including antenna. 
With two antennas having different characteristics this can give substantial benefits in receiving 
fading and/or weak signals or separating calls in a large pile-up. Particularly on low bands.

DXLog supports diversity operation on a selected number of radio models.

For the supported radios, diversity operation can be toggled on and off using <code>[Ctrl][-]</code> or <code>[Ctrl][Keypad -]</code>.

If enabled via the radio's controls, DXLog will automatically detect diversity operation and enable 
the necessary mechanics. Diversity operation is indicated by a small DIV icon in the frequency 
counter box for the radio's band map.

'''Yaesu FTDX101D

Yaesu calls this feature "Sync" and it has a dedicated button up and left of the main VFO knob. 
Enabling this will make DXLog update both VFO with the same information when grabbing spots. 
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO. 
Since both VFO are kept on the same frequency, split operation is not supported.

'''ICOM IC-7851 and IC-7610

ICOM calls this feature "Tracking" and it can be enabled either via a menu entry or a long press on the "MAIN/SUB" button. 
Enabling this will make DXLog update both VFO with the same information when grabbing spots. 
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO. 
Since both VFO are kept on the same frequency, split operation is not supported.

'''Elecraft K3/K3S/K4

Elecraft calls this feature by its proper name. It is enabled by a long press on the "Sub" button. 
It should be noted that Elecraft's implementation where the main VFO controls both the main and 
sub receivers allows for split operation, i.e. transmitting on a different frequency using VFO B.

==UDP broadcast==

For interaction with other applications, DXLog can broadcast useful information as 
XML datagrams over UDP. 

There are five types of broadcast messages produced by DXLog:

* QSO information. Sent when logging.
* Radio information. Sent at changes as well as periodically.
* Antenna direction information. Sent when rotor control is invoked.
* Callsign look-up information
* Spots

QSO can be broadcasted in traditional DXLog format or in a more N1MM-like format.

Radio information can report SO2V as a single physical radio or as two physical radios, like N1MM.

There is an option to truncate the broadcasted QSO time to full minutes for better 
interoperability with some online services and software such as MSHV.

In addition, DXLog can also recognize QSY commands from Waterfall Bandmap and log QSO done as well as create 
local spots from decodes broadcasted by WSJT-X and its forks.

The broadcasting of QSO and radio related data is enabled using the <code>Options|Broadcast</code> submenu.

The broadcasting of spots is enabled by checking <code>Options|DX Cluster|Send spots to SmartSDR</code>.

[[image:radiobroadcastenable3.png]]

[[image:sendspotstosmartsdr.png]]

UDP broadcast parameters are configured in the <code>Options|Network configuration</code> panel. 
Please note that up to three ports can be specified for each broadcast, thereby supporting 
multiple receivers of the information.

[[image:Networksettingsbroadcast3.png]]

If you are writing a C# application to make use of these datagrams, there is a very nice online tool 
for creating an object from a sample XML datagram here https://xmltocsharp.azurewebsites.net/ 

In C# parsing is easily done using Linq. One example of XML parsing and deserialization using Linq 
can be found here https://github.com/bjornekelund/ICOMautomagic

===QSO information===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program
|-
| qsoid
| A unique string for this QSO. If this QSO is edited another contactinfo message will be sent with the same qsoid. Note that the qsoid is only unique within one instance of DXLog. If the computer is networked to others running DXLog the different computers may have a different qsoid for the same QSO.
|-
| contestname
| The name of the contest as it would be written to a Cabrillo file.
|-
| timestamp
| The UTC date and time of the QSO.
|-
| mycall
| The callsign of this station.
|-
| band
| The band on which the QSO was made. In MHz with period as decimal separator.
|-
| txfreq
| The frequency on which the QSO was made.
|-
| operator
| The callsign of the operator if the OPON command was used to set it, otherwise blank.
|-
| mode
| The mode used for the QSO.
|-
| call
| The callsign of the station worked.
|-
| countryprefix
| The DXCC country of the station worked.
|-
| wpxprefix
| The WPX prefix of the station worked.
|-
| snt
| The RST sent. This is always included whether or not the contest exchange contains an RST.
|-
| rcv
| The RST received. This is always included whether or not the contest exchange contains an RST.
|-
| nr
| The number sent if the exchange uses a serial number, otherwise the QSO number from this station.
|-
| exch1
| The first element in the contest exchange if any.
|-
| exch2
| The second element in the contest exchange if any.
|-
| exch3
| The third element in the contest exchange if any.
|-
| exch4
| The fourth element in the contest exchange if any.
|-
| xqso
| True if this QSO should not be counted towards the score.
|-
| invalid
| True if this QSO is invalid, for example a DX QSO in a domestic contest.
|-
| duplicate
| True if this QSO is a dupe (the station has previously been worked).
|-
| rule10broken
| True if this QSO breaks the 10 minute or similar rule. Note that a QSO may not break the 10 minute rule when it is logged but may later if another QSO is edited. This may not cause a broadcast.
|-
| azimuth
| The approximate direction of the station worked, in degrees.
|-
| distance
| The approximate distance of the station worked, in kilometers.
|-
| stationid
| The station ID of the station which made the QSO.
|-
| stationqso
| A unique QSO ID generated by the logging station. The combination of stationid and stationqso forms a unique identifier for the QSO.
|-
| stationtype
| The type of station - R for run, R1 for run 1 etc.
|-
| local
| True if this broadcast is due to this QSO being logged or edited on this computer.
|-
| runqso
| True if QSO logged in Run, false if S&P, and empty if unknown. '''Important:''' Only valid when local is True.
|-
| mult1
| The name of the multiplier if this station is a new multipllier, empty otherwise.
|-
| mult2
| The name of the multiplier if this station is a new multiplier, emtpy otherwise.
|-
| mult3
| The name of the multiplier if this station is a new multiplier, empty otherwise.
|-
| points
| The logged points for the QSO.
|-
| period
| The number of the operating period.
|-
| guid
| The GUID in hex format.
|-
| newqso
| True if a new QSO, False if this message is an update to an existing QSO.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<contactinfo>
<logger>DXLog v2.4.13</logger>
<qsoid>19</qsoid>
<contestname>ARRL-SS-CW</contestname>
<timestamp>2020-01-13 18:28:07</timestamp>
<mycall>SM7IUN</mycall>
<band>3.5</band>
<txfreq>352376</txfreq>
<operator></operator>
<mode>CW</mode>
<call>K4BAI</call>
<countryprefix>K</countryprefix>
<wpxprefix>K4</wpxprefix>
<snt>599</snt>
<rcv>599</rcv>
<nr>19</nr>
<exch1>076</exch1>
<exch2>B</exch2>
<exch3>54</exch3>
<exch4>GA</exch4>
<xqso>False</xqso>
<invalid>False</invalid>
<duplicate>False</duplicate>
<rule10broken>False</rule10broken>
<azimuth>225</azimuth>
<distance>1388</distance>
<stationid>STN1</stationid>
<stationqso>19</stationqso>
<stationtype>R1</stationtype>
<local>True</local>
<runqso>True</local>
<mult1>GA</mult1>
<mult2></mult2>
<mult3></mult3>
<points>3</points>
<period>1</period>
<guid>11223344556677889900aabbccddeeff</newqso>
<newqso>True</newqso>
</contactinfo>
</pre>

Alternative N1MM format

Note that the band name uses the computer's local number format so it may use either comma 
or period as decimal separator. The ID is a number rather than an alphanumeric string.

Also note that IsRunQSO is only valid when IsOriginal is True.

<pre><?xml version="1.0" encoding="utf-8"?>
<contactinfo>
<app>N1MM</app>
<contestname>CWOps</contestname>
<timestamp>2020-01-17 16:43:38</timestamp>
<mycall>SM7IUN</mycall>
<band>3.5</band>
<rxfreq>352519</rxfreq>
<txfreq>352519</txfreq>
<operator></operator>
<mode>CW</mode>
<call>K1XM</call>
<countryprefix>K</countryprefix>
<wpxprefix>K1</wpxprefix>
<stationprefix>K1XM</stationprefix>
<continent>NA</continent>
<snt>599</snt>
<sntnr>5</sntnr>
<rcv>599</rcv>
<misctext></misctext>
<ismultiplier1>1</ismultiplier1>
<ismultiplier2>0</ismultiplier2>
<ismultiplier3>0</ismultiplier3>
<points>l</points>
<radionr>l</radionr>
<run1run2>1<run1run2>
<IsOriginal>False</IsOriginal>
<NetBiosName>DESKTOP-23AB</NetBiosName>
<IsRunQSO>0</IsRunQSO>
<StationName>STATION_B</StationName>
<ID>23</ID>
<IsClaimedQso>true</IsClaimedQso>
</contactinfo>
</pre>

===Radio information===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| The name of the logging program.
|-
| logger
| The name and version of the logging program.
|-
| Station
| The ID of the station.
|-
| RadioNr
| The radio being described.
|-
| Freq
| The receiving frequency.
|-
| TXFreq
| The transmitting frequency
|-
| InactiveFreq
| The frequency of the VFO not receiving.
|-
| Mode
| The reported radio's mode.
|-
| OpCall
| The callsign of the operator if the OPON command was used to set it, otherwise blank.
|-
| mycall
| The callsign of the station.
|-
| IsRunning
| "True" if the station is running, "False" if search and pounce.
|-
| FocusEntry
| The Windows handle for the focused entry window.
|-
| Antenna
| Antenna number.
|-
| Rotors
| Rotators used by selected antenna (not currently used by DXLog).
|-
| FocusRadioNr
| The radio which has keyboard focus. In SO2V with "Report SO2V as two radios" checked, radio 2 is the sub/B VFO.
|-
| IsStereo
| True if headphones are listening to two radios.
|-
| IsSplit
| True if radio is set to split.
|-
| ActiveRadioNr
| The radio which is transmitting, if any.
|-
| Technique
| SO1R, SO2R, SO2R_ADV, or SO2V
|-
| StationType
| Station role: R, M, R1, R2, or R+.
|-
| isTransmitting
| True if a DXLog is transmitting. False if DXLog is not aware of transmission.
|-
| IFFrequency
| Optional element only used with Elecraft K3/K4. Contains the current IF frequency in Hz.
|-
|}

Important note: In SO2V the format differs from some other loggers and is:

: Only physical radio 1 is reported.
: <tt>Freq</tt> and <tt>TXFreq</tt> are the frequency of the currently focused VFO.
: <tt>InactiveFreq</tt> is the frequency of the currently unfocused VFO.
: <tt>ActiveRadio</tt> is always 1.
: <tt>FocusedRadioNr</tt> is 1 when the main/A VFO is focused, 2 otherwise.
: <tt>IsSplit</tt> is always false.

With the option "Report SO2V as two radios" checked, the reporting is similar to some other loggers and is:

: The two VFO are reported as two physical radios.
: <tt>Freq</tt> and <tt>TXFreq</tt> for radio 1 are the frequency of the main/A VFO.
: <tt>Freq</tt> and <tt>TXFreq</tt> for radio 2 are the frequency of the sub/B VFO.
: <tt>InactiveFreq</tt> is the frequency of the other VFO.
: <tt>ActiveRadio</tt> and <tt>FocusedRadioNr</tt> are 1 when the main/A VFO is focused, 2 otherwise.
: <tt>IsSplit</tt> is always false.

Example message:

<pre><?xml version = "1.0"?>
<RadioInfo>
<app>DXLog</app>
<logger>DXLog v2.4.13</logger>
<Station>STN1</Station>
<RadioNr>1</RadioNr>
<Freq>704000</Freq>
<TXFreq>704000</TXFreq>
<InactiveFreq>702500</InactiveFreq>
<Mode>CW</Mode>
<OpCall>K1XM</OpCall>
<mycall>HQ9X</mycall>
<IsRunning>False</IsRunning>
<FocusEntry>591124</FocusEntry>
<Antenna>1</Antenna>
<Rotors>ABC</Rotors>
<FocusRadioNr>1</FocusRadioNr>
<IsStereo>False</IsStereo>
<IsSplit>False</IsSplit>
<ActiveRadioNr>1</ActiveRadioNr>
<Technique>SO2R</Technique>
<StationType>R1</StationType>
<IsTransmitting>False</IsTransmitting>
<IFFrequency>8215000</IFFrequency>
</RadioInfo>
</pre>

===Antenna direction===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program.
|-
| station
| The ID of the station.
|-
| radio
| The radio associated with the rotator.
|-
| go
| True if the rotator should be turned.
|-
| stop
| True if the rotator should be stopped if it is turning.
|-
| azimuth
| The direction to turn the rotator if go is True.
|-
| frequency
| The transmit frequency of the specified radio.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<Rotator>
<logger>DXLog v2.4.13</logger>
<station>STN1</station>
<radio>2</radio>
<go>True</go>
<azimuth>252</azimuth>
<frequency>2800200</frequency>
</Rotator>

</pre>
<pre><?xml version="1.0" encoding="utf-8"?>
<Rotator>
<logger>DXLog v2.4.13</logger>
<station>STN1</station>
<radio>2</radio>
<stop>True</stop>
<frequency>2800200</frequency>
</Rotator>
</pre>

===Callsign lookup===

Sent either when callsign in entry row is changed or when space or tab is pressed.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program.
|-
| contestname
| The name of the contest.
|-
| mycall
| Station's call
|-
| band
| Current band
|-
| txfreq
| Transmitter frequency
|-
| operator
| The call sign of the logged in operator
|-
| mode
| Operating mode
|-
| call
| Call entered in the logging field
|-
| countryprefix
| DXCC entity prefix
|-
| wpxprefix
| WPX prefix
|-
| azimuth
| Short path antenna direction
|-
| distance
| Distance in km
|-
| stationid
| The ID of the station sending the datagram
|-
| stationtype
| The role of the station sending the datagram; R, R1, R2, M, or R+
|-
| period
| Contest period
|-
| reason
| Reason for transmission; SpaceOrTab or CallChanged
|-
|}

Example message:

<pre><?xml version = "1.0"?>
<lookupinfo>
<logger>DXLog v2.4.20</logger>
<contestname>DARC-WAEDC-CW</contestname>
<mycall>K1XM</mycall>
<band>20</band>
<txfreq>1400200</txfreq>
<operator></operator>
<mode>CW</mode>
<call>E7DX</call>
<countryprefix>E7</countryprefix>
<wpxprefix>E7</wpxprefix>
<azimuth>54</azimuth>
<distance>6824</distance>
<stationid></stationid>
<stationtype>R</stationtype>
<period>1</period>
<reason>SpaceOrTab</reason>
</lookupinfo>
</pre>

===Spot===

Sent for every incoming spot from the DX cluster that is valid for the current contest.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| Application sending the message.
|-
| StationName
| The station issuing the broadcast.
|-
| dxcall
| The callsign of the spotted station.
|-
| frequency
| Frequency in kHz with decimal sign of the PC's current locale. (sic)
|-
| spottercall
| The callsign of the spotter. Station name if locally spotted or result of a logging operation.
|-
| timestamp
| Spot time in format yyyy-MM-dd HH:mm:ss
|-
| action
| add or delete.
|-
| mode
| actual or guessed mode of the spot in capitals.
|-
| comment
| The comment section of the spot.
|-
| status
| Spot status. Valid values are "dupe", "double mult", "single mult", and "new qso".
|-
| statuslist
| Same as status
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<spot>
<app>DXLog.net</app>
<StationName>CONTEST-PC</StationName>
<dxcall>E7DX</dxcall>
<frequency>14022.3</frequency>
<spottercall>SM7IUN-#</spottercall>
<timestamp>2O23-07-15 14:29:37</timestamp>
<action>add</action>
<mode>CW</mode>
<comment>CW 31 DB 42 WPM CQ</comment>
<status>single mult</status>
<statuslist>single mult</statuslist>
</spot></pre>

===Broadcast listener===

DXLog also listens for commands over UDP.

Currently only one command is implemented, <code><radio_setfrequency></code>, which is a QSY command.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| Application sending the command
|-
| radionr
| The radio to be changed. In SO2V radio 2 means VFO B. Optional as of DXLog 2.5.20.
|-
| frequency
| Requested frequency. Both period and comma is accepted as decimal separator.
|-
| mousebutton
| Which mouse button was used to create message, if any. Optional.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<radio_setfrequency>
<app>WaterfallBandmap</app>
<radionr>1</radionr>
<frequency>21022.194</frequency>
<mousebutton>Left</mousebutton>
</radio_setfrequency>
</pre>

==SDR integration==

===HDSDR, OmniRig, and microHAM===

''Contributed by Ingo SM5AJV/SE5E''

Until DXLog offers SDR integration there are still ways to get a waterfall/spectrum display with DXLog.

I have integrated the free SDR software [http://www.hdsdr.de/ HDSDR] with DXLog using
[http://www.microham.com Microham Device Router], 
[http://dxatlas.com/OmniRig/ OmniRig]
and [https://www.autohotkey.com/ AutoHotkey].

As illustrated below I place the HDSDR window at the very top of the desktop with DXLog right below.

I share my transceiver's (an Elecraft K3) antenna with the SDR. The receiver antenna signal from my 
K3's RX-ANT OUT is connected to the input of a 3dB power splitter. The two outputs from the splitter 
are connected RX-ANT IN on the K3 and the SDR Receiver antenna input, respectively. On a K3 you 
need to enable the RX-antenna input to make this to work. An additional benefit with this method 
is that the SDR is protected during transmission. It is a widely used method and is e.g. described 
by Bob N6TV in this
[http://dxlog.net/sw/files/utilities/Adding%20an%20SDR%20to%20an%20SO2R%20Station.pdf presentation].

'''Screenshot of my desktop:

[[Image:Sdrdesktop.png|800px]]

Since both DXLog and HDSDR need to communicate with the radio, you need to "split" 
the CAT communication. microHAM's USB Device Router provides a second, independent, 
CAT port that can be used via HDSDR's omniRig interface.

'''"PORT" Tab on microHamRouter:

[[Image:Sdrmicrohamrouter.png|800px]]

'''OmniRig settings in HDSDR:

[[Image:Sdromnirig.png|200px]]

With this set up, the radio, DxLog, and HDSDR will be fully synchronized. For instance, you can 
click in the waterfall to make the radio QSY, and it is easy to quickly find a clean frequency.

To make the integration even better I use a small AutoHotkey script. The script pulls entry focus 
back to DxLog after clicking on the HDSDR waterfall and in DXLog it allows you to use hotkeys to 
control HDSDR. <code>[Ctrl][Alt]+</code> and <code>[Ctrl][Alt]-</code> zooms the waterfall/spectrum 
in and out, and <code>[Ctrl][Alt]C</code> centers it.

'''AutoHotkey script:

SetTitleMatchMode, 2
#InstallKeybdHook
#IfWinActive, HDSDR
{
F4:: return ; disable F4
~LButton Up::
sleep, 1
Winactivate, DXLog
return
}
#IfWinActive, DXLog
{
^!+:: ControlSend ,, ^{+}, HDSDR
^!-:: ControlSend ,, ^{-}, HDSDR
^!c:: ControlSend ,, {c}, HDSDR
}

The script can be downloaded [http://DXLog/sw/files/utilities/dxlog_hdsr.ahk here].

If you start two instances of HDSDR with two different SDR you can even have two waterfalls 
running at the same time.

I have not yet found a way to display cluster spots in the HDSDR spectrum panel. 
But I still find it very useful to check band activity and it allows me to easily find 
a new Run frequency on a crowded band.

===Waterfall Bandmap===

The free waterfall/spot display utility "Waterfall Bandmap" by Steve N2IC is supported by DXLog.

Waterfall Bandmap supports almost any SDR that produce I/Q output either via ExtIO.DLL or a 
sound card; SDRPlay, FunCubeProPlus, HackRF, SDR-IQ, RTLSDR, SoftRock, etc.

A zip file with an executable binary and a Microsoft word document with installation and 
configuration instructions can be found here: https://groups.io/g/waterfallbandmap/files

If you are not a member of the support forum group, you need to apply for membership to download. 
Membership is free.

[[Image:Waterfallbandmap.png]]

The SDR can be connected either to a separate receive antenna, an external receiver output on 
your transceiver or to an IF output, should your transceiver have one. If connected to an antenna, 
keep in mind that you may need protection from the transmitter such as a T/R relay or a passive level limiter.

Please refer to Waterfall Bandmap's documentation for setting it up with your SDR.

Waterfall Bandmap needs two information feeds over UDP: Radio information and spot information. 
Both are provided as UDP broadcast by DXLog.

The default port for both is 13063 and this needs to be set in DXLog's Network configuration panel. 
If Waterfall Bandmap runs on the same computer as DXLog, the broadcast address can be left at the default 127.0.0.1.

[[Image:Setbroadcastportsforwfbandmap.png]]

Clicking on the waterfall display can set the frequency of DXLog. (Left click sets VFO A, right click sets VFO B.) 
To enable this functionality, check the option <code>Options|Broadcast|Receive Broadcasts</code> 
Also make sure "UDP broadcast listener" includes port 13064 in the network settings panel.

The radio information feed needs to be enabled by checking the <code>Options|Broadcast|Radio information</code> option

[[Image:radiobroadcastenable2.png]]

and the spot feed needs to be enabled by checking the <code>Options|DX Cluster|Send spots to SmartSDR</code> option.

[[Image:Enablesendspotstosmartsdr.png]]

==Time synchronization==

In a multi-station setting, the time needs to be accurately synchronized across all networked PC.

Windows' built in time synchronization is very crude and for a PC with poor clock stability the 
inaccuracy of the clock may be up to a minute. Which of course is not acceptable for contesting.

DXLog has built in support for time synchronization as described in the [[Menu Options#Configure network|Configure network section]].

Due to Windows' security system, this however requires all except the PC running as time server to 
run DXLog with elevated permissions. There is unfortunately no way around this inconvenience.

An equally accurate and less intrusive method is to use a standalone time synchronization application on each networked PC. 
This will keep each PC's clock accurate within a fraction of a second.

Contrary to a solution built into a logger it also has the great benefit of being an "install and forget" solution.

A popular application is Dimension 4 by Thinking Man Software. It is free for personal use and 
can be downloaded here: https://dxlog.net/sw/files/utilities/d4time531.msi

It runs in the background and only shows up as a tiny icon in your system tray. 
You hover the mouse above the icon to check status and right-click to open and change settings.

:::[[image:dimension4tray.png|50px]]

After installation a brief configuration is required.

First of all, allow the application to disable Windows' time service and to modify your system clock.

For maximum accuracy, select a time server geographically close to your location. 
When in doubt, you can always add the global server "pool.ntp.org" to the list and use that. 

There are also national and continental pools of time servers. You can find them here https://www.ntppool.org.

[[image:dimension4b.png]]

Make sure the check boxes "Load Dimension 4 at startup", "Start minimized", "Hide when minimized", 
and "Display icon in tray" are all checked.

[[image:dimension4advanced.png]]

Click the Advanced button and also make sure the option "Use the selected server" is selected.

Make sure the application reports a successful connection to the selected time server. 
From here on, you can basically forget the application. 
It will silently start with your PC and always keep its time accurate.

==Disabling USB power management==

In the interest of saving energy, Windows habitually power down USB interfaces 
when it believes there is inactivity. Some USB-to-serial and USB audio devices 
respond poorly to being suspended or powered down so as a rule this "feature" should 
be disabled when used in a ham radio environment.

There are two places where this functionality needs to be disabled; the device driver 
and Windows' energy management.

To disable it for each USB interface and device, open Windows settings. (Click the Windows 
icon in the lower left corner and then chose the cogwheel.) Type ''device manager'' and
select the result.

[[image:devicemanager-c.png|none|frame]]

This opens up a new window, Windows' Device Manager.

[[image:devicemanager2b.png|none|frame]]

For '''every''' USB interface component (there may be many), COM-port, and audio device, 
and '''uncheck''' the option ''Allow the computer to turn this device off to save power''.

The devices you are looking for are in the categories: ''Ports (COM & LPT)'', 
''Sound, video and game controllers'', ''Universal serial bus controllers'',

Note that some devices may not have a ''Power Management'' tab.

[[image:usbdevicemanager.png|none|frame]]

The next step is to disable Windows ''Selective suspend'' feature for USB interfaces.

Go back to Windows Settings and type ''edit power'', click the appearing ''Edit power plan'' menu entry.

[[image:editpowerplan2.png|none|frame]]

This should open the window below, the plan editing panel.

[[image:editplansettings.png|none|frame]]

Click ''Change advanced power settings''. Scroll down to ''USB settings'' and make 
sure ''USB selective suspend setting'' is '''disabled''' for all situations.

[[image:Advancedsettings.png|none|frame]]

To prevent audio devices from becoming unreachable or going into sleep mode you should also 
disable exclusive access. While changing this, also make sure all audio enhancements are disabled.

You reach the detailed audio device settings by entering Windows settings, search for Control panel, 
and in the Control panel view, select Hardware and audio, and then Sound.

[[image:Audiodevice.png]]

Reboot your computer to make sure all settings are recognized by Windows.

==Interlock and inband operation==

In contest station terminology, the term ''Interlock'' refers to a technical solution preventing 
more than one station from using a shared resource, typically an antenna, at the same time.

The most common use for interlock is for inband operation. Inband operation means to have multiple 
transmitters on a single band, interleaving their transmissions. Sometimes on a split-second basis.

As long as you never have more than one transmitter active at any time, the majority of contests allow 
an unlimited number of transmitters and receivers on a single band for multi-operator categories. 
This fact is used by most big contest stations.

For an inband solution to be effective, each station must be able to receive while the 
other station transmits. This means it requires a separate, high performance receive antenna 
with very good isolation from the transmitter antenna. The most common way to 
achieve this is physical separation and geographic orientation to minimize the situations 
when they will radiate/listen in the direction of the other antenna.

For a station operating in the M/M, M/S, or M/2 category, inband operation can boost the points 
per hour performance significantly. It is also a lot more fun.

However, as with everything else, it comes at a cost. An efficient inband solution has:

* A high performance receive antenna for each operated band(s) with very good isolation from the transmitter antenna.
* A fail-safe antenna switching hardware.
* Interlock-capable keyers and/or station controllers.
* An interlock-capable contest logging software

A typical inband configuration can be seen in the illustration below.

[[image:inbandconcept-trx.jpg|800px]]

DXLog offers a software-based interlock which can be configured in a variety of ways, e.g. based on frequency 
band, operating mode, or station role. It supports an unlimited number of stations interlocking each other 
using a great variety of strategies.

The interlock relies on UDP networking and is overlaid on the communication for multi-station logging. 
UDP networking has the benefit of speed and low latency but is, unlike TCP, susceptible to packet loss. 
This means that a '''wired LAN''' is a necessity for any station using interlock. 
For the same reason, it is also not recommended to run interlock over e.g. VLAN/VPN link for 
geographically distributed stations.

A software interlock is not 100% reliable. Computer or software malfunction, networking issues such as packet 
loss, etc. can cause interlock to fail, even if only momentarily.

For this reason it is necessary to also accompany a software interlock with a fail-safe '''hardware''' interlock. 
Without hardware supported interlock you run the risk of not only violating contest rules but also cause serious equipment damage. 
Some contests, such as CQ WW, explicitly requires hardware interlock when using multiple stations on the same band.

There are many designs and even commercial products available for hardware interlock. 
One example of a simple but effective two station hardware interlock which also supports 
power amplifier sharing can be found [https://sm7iun.se/contest/inband/ HERE].

The purpose of this section is to describe steps of setting up a basic two station in-band solution with 
DXLog and microHAM keyers. The microHAM keyers are not mandatory but offers a much better user experience 
and removes the need for additional hardware.

'''Pro tip:''' Consider checking <code>Options|Networking|Allow other stations to abort sending</code> 
which will allow your partner station to interrupt your transmission with <code>[Shift][Esc]</code> in 
critical situations. Be careful though, the use of this function requires good judgment to avoid violence.

===Networking===

Open the networking configuration panel with <code>Options|Configure network</code> and make sure each 
station has a unique name and that only UDP networking is enabled.

Make sure the two stations use the same broadcast IP address and that it is in line with your LAN's 
configuration. Pressing the <tt>Default</tt> button is a good way to ensure this.

Make sure the menu option <code>Options|Enable network</code> has a checkmark.

[[image:inbandnetworkrun.png|left|frame]][[image:inbandnetworkinband.png|none|frame]] 

===DXLog Interlock configuration===

First of all, make sure that the <code>Options|Interface specific options|Prevent TX if another radio is on same band</code> 
is '''not''' enabled. This option completely prevents transmission if more than one networked station is set to the same band 
and the whole idea with inband is to have exactly that.

Next, activate software interlock on both stations using the menu option <code>Options|Networking|Software interlock</code> 
or by typing the commmand <tt>ILOCKON</tt>.

[[image:inbandinterlock2.png|none|frame]]

There are multiple options for configuring the interlock. In a simple set up with only two stations, the topmost 
option ''Same band from status list'' is a good choice. This option will prevent more than one station transmitting 
on the same band, regardless of mode.

In an environment with many stations (such as a multi-operator-multi-transmitter station) it is 
recommended to use the bottom option to only interlock with one or several named stations. 
This will reduce both LAN traffic and inband operation latency. This is particularly important when 
running parts of the DXLog network over high latency links such as VLAN/VPN or if some stations (albeit not 
part of the interlock cluster) are connected via Wi-Fi.

For more advanced scenarios you can also use interlock based on mode or station type (e.g. Run 1, Run 2, Mult, etc.).

The "status list" listing the networked DXLog stations is displayed in the ''Status Window'' which is opened 
with <code>Windows|Status window</code> or <code>[Alt][J]</code>.

[[image:inbandstatuslist2.png]]

DXLog also offers great flexibility when it comes to interlock strategy. The most straightforward and 
most commonly used is ''First one wins''. This is also typically the behavior of "unintelligent" 
hardware solutions when not assisted by software. With this strategy, the station starting to transmit 
first can not be interrupted and always gets to finish its transmission.

[[image:inbandinterlockoptions.png]]

With a ''Last one wins'' strategy, the transmitting station can be interrupted. A carte blanche permission 
to interrupt all transmissions by the other station may however be counterproductive in a real contest situation.

For this reason, DXLog offers additional control of which transmit actions can be interrupted and which can not. 
This is a powerful tool but requires both operators to be aware of it and may require 
practice before fully effective.

[[image:inbandstrategyexceptions.png]]

''F1'' through ''F7'', ''PLUS'' and ''INS'' refers to DXLog's standard messages. ''KEYB'' means a free text transmission 
from the keyboard using the <code>[Alt][K]</code> function and ''MAN'' means manual transmission using either paddle 
break-in or a footswitch.

For CW, DXLog recognizes paddle break in from a K1EL Winkey-compatible keyer as described in the [[Menu_Options#Winkey_Configuration|Winkey configuration section]].

Since DXLog recognizes a footswitch connected to a microHAM device, this is a recommended approach for phone. 
It is also possible to connect a footswitch to the DSR pin (pin 6) on a physical COM-port on the PC, but today 
few PC have such a port and it also requires additional circuitry.
Details on how to do this is available [[Additional_Information#Connecting_a_footswitch|HERE]].

===microHAM configuration===

Open the microHAM device configuration panel with <code>Options|microHAM device configuration</code>.

[[image:Mk2r-new9.png|none|frame]]

Check the option ''Enable TX lock/unlock''. This will do two things; it will enable DXLog to prevent 
transmission and and it will make DXLog aware of the microHAM device's PTT status. The latter is particularly 
important since it means DXLog will recognize PTT assertion not only by a footswitch connected to the 
microHAM device but also by the built-in Winkeyer (requires microHAM USB Device Router version 9.3.0 or later) 
'''Paddle-based break-in in an inband solution is currently unique for microHAM with DXLog.'''

'''Important:''' Making DXLog "PTT aware" means that care has to be taken in how PTT is set up. If you, for instance, 
enable DXLog PTT for the voice keyer, this will create a self-reinforcing feedback loop and PTT will thus never drop.

Check the option ''Dual radio device'' if you are using a u2R, MK2R, or MK2R+, otherwise, leave this unchecked.

Check the option ''Device without CAT interface'' if the device lacks a CAT interface (like the u2R) 
or if its CAT interface is not connected to the radio. This option will make sure the e.g. keying and 
audio routing is always set correctly in line with the operating mode (Voice, CW, or RTTY).

===Operating===

Inband operation requires a fair amount of training and it is a good idea to define and agree 
on general rules for operation, such as hand signals for challenging QSO, beforehand.

There are more than enough YouTube videos of inband operators yelling at each other.

The operating tactics may have to be adjusted during the contest. If Run is slow, 
doing S&P on the inband station can increase the points per minute significantly. 
However, if Run is strong, an overly active inband operator doing S&P, but not working 
multipliers, may actually reduce the station's points per minute significantly.

Real-time interlock status is shown in the ''Radio status'' window, which is opened with 
<code>Windows|Radio status</code>.

[[image:inbandblocking.png]] [[image:inbandblocked.png]]

For Phone contesting, you typically rely on footswitches for PTT and the option 
<code>Options|Networking|Show QSO status when blocking</code> makes the blocking 
station send a more helpful blocking cause than ''MAN''.

With this option enabled, the blocking station will instead send ''CQ'', ''QSO'', or ''EXCHANGE'' 
as blocking cause, determined by cursor location and entry field content at the locking station.

Further reading can be found in the [[Menu_Options#microHAM_device_configuration|microHAM device configuration]] and [[Menu_Options#Networking|Networking]] sections.

==Connecting a footswitch==

To free up both hands in Phone contesting, a footswitch PTT is a great help.

Also, to use interlock in Phone contesting, a footswitch is mandatory.

There are two basic ways to interface a footswitch with DXLog; via a microHAM device (which is the recommended solution) 
or directly connected to a physical serial port on the PC (which very few PC have today).

The connection of a footswitch to a microHAM device is very straightforward and by checking the ''Enable TX lock/unlock'' 
in the ''microHAM device configuration'' panel, it is recognized by DXLog.

Lacking a microHAM device, it is also possible to use the computer's DB9 RS-232 serial port connector, providing it has one.

The required steps to do this are:
* Connect a 10k resistor between DB9 pin 6 and pin 7.
* In the port's settings (<code>Options|Configure interfaces</code>) set DTR (pin 4) to ''Always On'' and RTS (pin 7) to ''Always Off'' for the port.
* Connect the footswitch between DB9 pins 4 and pin 6. '''Important:''' Neither pole on the footswitch must be connected to ground.
* In the radio's configuration panel, check ''use CAT PTT command on Phone'' and set ''Footswitch (pin 6)'' to ''PTT''

==Support for CC Cluster==

CC Cluster is today the main choice for contest use.

It offers a high quality, database-verified, flow of skimmer spots and a rapid 3-minute respotting period for skimmer spots.

It also publishes unique spots from less common locations which are valuable for DX chasers or as contest multipliers.

To make use of the display of own spot in the world map, make sure to issue the command '''<tt>SET/OWN</tt>''' to the cluster node. 
This setting is persistent and only needs to be done once.

A list of cluster nodes that runs CC Cluster can be found here: [https://www.dxcluster.info/telnet/index.php?software=CC%20Cluster CC Cluster nodes]

A description of the command line syntax can be found here: [http://bcdxc.org/ve7cc/ccc/CCC_Commands.htm CC Cluster command syntax]

A convenient software for setting up filters etc. can be found here [http://www.bcdxc.org/ve7cc/default.htm#prog CC User]

[[Image:Ccclustersspotflow.png]]

==Support for AR Cluster 6==

With the author tragically SK, AR Cluster is no longer under development but still available as an executable binary.

In its standard configuration, AR Cluster offers no consolidation of skimmer spots meaning a very high flow of spots 
that can become extreme during a major contest weekend.

With the advent of skimmers, the traffic on the DX Cluster has risen dramatically. Even though CW skimmers are generally 
quite reliable, the absolute number of busted spots can be quite high during a busy contest.

Jose CT1BOH has developed an algorithm for evaluating spot quality which is included in version 6 of AR Cluster. 
Today many cluster nodes runs this version and thereby offer this mechanic. 
A complete list can be found here: [http://www.dxcluster.info/telnet/index.php?software=AR-Cluster AR Cluster nodes]

To enable the functionality on a cluster node running AR Cluster 6, the command

<tt>'''SET DX EXTENSION SKIMMERQUALITY'''</tt>

needs to be issued to the cluster node. The easiest way to do this in DXLog is via <code>[Alt][T]</code>. 
This setting will be remembered at subsequent logins.

The quality of the spots is indicated by a character ("tag") in the last column of the comment field and, 
in some cases, a corrected callsign within parenthesis. This syntax is recognized by DXLog and can reduce the 
number of bad spots in your bandmap.

The CT1BOH skimmer quality algorithm is based on three parts:

; Validation : When a callsign is first spotted, it is tagged with "?" in the last column of the spot's comment field. If the callsign of an unverified spot closely resembles an already verified one on the same frequency, the verified callsign is provided within parenthesis in the spot's comment field. When two or more skimmers agree on the spot, it is considered verified and the tag becomes "V".

; Frequency : When a verified spot appears more than 0.35kHz off its verified frequency, the spot is tagged "Q" for QSY. Once verified, this becomes the new verified frequency and it is tagged "V".

; Probability : The algorithm checks uncertain spots for resemblance with already verified spots and spots at or near the same frequency. If the resemblance is high enough, the spot is considered busted "B" and the corrected callsign is provided within parenthesis in the spot's comment field.

Below you can see an example of the spot flow from W9PA-4 with skimmer quality enabled. 
The flow contains one unverified and one busted spot.

[[image:spotquality.png]]

DXLog's policy for spots with CT1BOH skimmer quality tags is the following:

: '''V''' - Accept spot.
: '''Q''' - Accept spot.
: '''?''' - Accept spot. Use corrected call when provided.
: '''B''' - Accept spot if corrected call provided. Else ignore.

DXLog recognizes the skimmer quality tags but consolidates them for consistency 
with other cluster nodes' quality tags and to minimize confusion when mixing spot flows. 
The legend is:

: '''?''' means a spot with ? This is an unreliable spot.
: '''P''' means a spot with Q or B with correction. This is a fairly reliable spot.
: '''V''' means a spot with V. This spot is considered validated.

This basic policy can be modified by using additional filters at the cluster node end. Some examples are:

: <tt>'''SET DX FILTER NOT SKIMBUSTED'''</tt> - Do not send busted spots at all
: <tt>'''SET DX FILTER NOT SKIMQSY'''</tt> - Do not send QSY spots
: <tt>'''SET DX FILTER SKIMVALID'''</tt> - Only send verified spots
: <tt>'''SET DX FILTER NOT SKIMUNKNOWN'''</tt> - Do not send unreliable spots
: <tt>'''SET DX FILTER SKIMMER'''</tt> - Do not send manual spots

You can also compose more complex filters such as:

: <tt>'''SET DX FILTER SKIMVALID OR SKIMBUSTED OR NOT SKIMMER'''</tt>

This can be a good filter for most contests. It will will only provide valid or busted skimmer spots together with manual spots. 
It is safe to receive busted spots since DXLog will ignore them if there is no corrected callsign included. 

For assisted operation in serious contesting you however need to allow also unknown spots since weak stations spotted 
only by one or a few skimmers may never reach validated status. You do this by adding <tt>'''OR SKIMUNKNOWN'''</tt> to the filter.

Both the bandmap and the DX cluster announcement windows have the option to display the spot quality tag. 
These windows will show two additional tags; L and C. L stands for local spot, created by yourself or one of your team members. 
C stands for corrected, i.e., a B or ? spot where a corrected call has been included in the spot's comment field.

The AR6 filtering syntax offers a lot of flexibility. Another example:

: <tt>'''SET DX FILTER (SKIMVALID OR NOT SKIMMER OR ((SKIMQSY OR SKIMUNKNOWN) AND (CTY <> K AND CONT <> EU )))'''</tt>

will provide only validated and human spots except if they are from outside the US and EU.

If you get lost in the filter settings you can always reset with : <tt>'''SET DX DEFAULT'''</tt>.

Some more guidance on how to work with filters on AR-Cluster nodes can be found in [http://dxlog.net/sw/files/utilities/AR_Cluster_v6_User_Manual.pdf this document].

==Support for DXSpider==

DXSpider is the most dominant DX cluster software but has historically not been a 
good choice for contesters. The reasons for this include: Long respotting time, lack 
of pass function for own spots, and suppression of spots from a single skimmer.

The good news is however that the author Dirk G1TLH has worked hard to address these 
aspects of the otherwise brilliant software.

From '''version 1.57 release 440''' the respotting time is now 3 minutes and there is a 
<tt>SET/SEEME</tt> command that passes all spots without consolidation of your own callsign.

So if your favorite cluster node is not running this version, ask the owner to upgrade asap.

Yet another reason for its popularity is its extreme resource-efficiency which allows it to run 
virtually any Linux capable hardware, including a $20 Raspberry Pi Zero.

A list of all DX cluster nodes running DX Spider can be found here: [https://www.dxcluster.info/telnet/index.php?software=DX%20Spider DX Spider cluster nodes]

[[image:dxspiderflow.png]]

DXLog recognizes the <tt>Q:#</tt> skimmer quality tag in the comment field and converts them into 
"CT1BOH-like" quality tags that can be displayed in DXLog's bandmap. The legend is:

: '''?''' means a spot with Q:1, i.e. heard by only one skimmer. This is an unreliable spot.
: '''P''' means a spot with Q:2, i.e. heard by only two skimmers. This is a fairly reliable spot.
: '''V''' means a spot with Q:3 or higher, i.e. heard by several skimmers. This spot is considered validated.

Since a DXSpider node currently needs to be specially configured by the owner to publish Q:1 spots, very few do this. 
Also, since DXSpider lacks busted call detection, the the quality of the spot flow will suffer if this is done.

A typical cluster line looks like this:

'''<tt><nowiki>DX de PY2MKU-# 14065.0 SM7IUN CW 29dB Q:9* Z:14,15,20 1922Z</nowiki></tt>'''

The Q parameter is the number of skimmers spotting the call. The trailing star means they do not quite agree 
on the frequency. A trailing plus means the station has been spotted for more than one hour. The Z parameter 
lists the CQ zones in which the callsign is spotted.

There is a wealth of information to be found on the [http://wiki.dxcluster.org/index.php/Main_Page DXSpider wiki].

==Support for N2WQ Cluster==

Introduced in late 2025, Rudy N2WQ has developed the first new DX cluster node software in decades.

The N2WQ-2 cluster has some unique features like a more advanced callsign validation than 
AR 6 and propagation estimation tags embedded in the spot comments. An example can be seen below.

[[image:n2wpspotflow.png]]

When you connect to dxc.n2wq.com port 8300 and you have set your 4-digit Maidenhead grid (SET GRID), there 
will be a single character just before the DX’s grid locator. This character is the path prediction glyph.

It is a crowdsourced, real-time estimate of how reliable the path is between you and the DX on that band right now, 
based on recent on-air propagation reports from RBN and PSKreporter. Its values and meaning are:

: > High: Strong path. If you can hear them, you should be able to work them.
: = Medium: Decent path. Workable with normal contest/DX technique.
: < Low: Weak path. Possible, but expect repeats, timing, and patience.
: - Unlikely: Marginal. Try only if it’s rare/needed, or you have a strong station advantage.

A missing glyph means insufficient data to estimate the path.

the glyph is mode-aware. A path that looks great for a very sensitive mode (FT8) can look 
more moderate for a less sensitive one (SSB).

You can filter spots by path reliability using the PASS/REJECT PATH command.

It is important to be aware that the glyph does not know:

: Your antenna gain/pattern, height, or takeoff angle
: Your transmit power and duty cycle constraints
: Your operating technique (timing, split discipline, pileup strategy)
: Short-lived phenomena the network has not yet “seen” such as sporadic E or aurora.

The cluster ingests upwards of 50,000 CW, FT, RTTY, and WSPR spots per minute. To compare different modes 
fairly, the system normalizes reports onto a common “FT8-equivalent” scale (so a CW SNR can be compared 
to an FT8 SNR).

Your grid and the DX grid are mapped into small geographic cells and the cluster calculates propagation 
at two levels:

: Fine (local): what’s happening close to your area (~180 miles).
:: On averages there are about 90,000 DE/DX pairs being tracked
: Coarse (regional): what’s happening in the broader region around
:: you (~480 miles). On average, there are about 30,000 DE/DX pairs.

If there isn’t enough local data, the system leans more on regional behavior. 
If there’s plenty of local data, it uses that more heavily.

Sometimes you can hear them better than they can hear you (or the reverse) due to noise 
floors, antennas, geography, or ionospheric effects. The system tracks both:

: Receive direction: DX to you (can you hear them?)
: Transmit direction: you to DX (can they hear you?)

It combines these into one “path reliability” estimate, weighting receive a bit more 
because if you can’t hear them, you can’t work them.

Propagation changes fast, so older reports get discounted using a half-life (data fades 
in influence over time). Typical behavior by band:

: Low bands (160/80m): slower changes (longer half-life)
: Mid bands (40–20m): medium pace
: High bands (15–6m): fast changes (shorter half-life)

In practice, this means glyphs can shift in minutes on 10m/6m, and more slowly on 80m/160m. 
Also, new openings take time to show up. A "insufficient" can simply mean “the path just opened 
and the cluster hasn’t collected enough recent reports yet.”

Your local noise floor heavily affects what you can receive, so the cluster lets you tell 
it what your noise environment is. This mainly tunes the receive-side expectation (DX to you).

Set it with SET NOISE SUBURBAN. Available profiles per ITU:

: QUIET: very low noise, rural/remote
: RURAL: mild noise
: SUBURBAN: typical neighborhood QRM
: URBAN: elevated noise, dense housing
: INDUSTRIAL: severe noise

If you don’t set it, the system may assume a quieter environment than you actually 
have, and your receive-side glyphs can look too optimistic.

Treat the glyph as a real-time probability hint that helps you spend your operating 
time where the odds are best. When you see > on a needed multiplier, move fast. 
When you see -, be intentional about whether it’s worth the time. 
And when you see a space, fall back to classic DX/contest instincts and your own ears.

The N2WQ cluster also offers spot quality tags between the DX grid and the time.

A quality (in terms of callsign reliability) tag can be V, P, S, C, or ? where V means validated, 
P highly likely, S less likely, C corrected, and ? unsure.

The propagation and quality tags can be displayed in the bandmaps and the DX cluster announcement window.

DXLog recognizes the skimmer quality tags but consolidates them before display for consistency 
with other cluster nodes' quality tags and to minimize confusion when mixing spot flows. 
The legend is:

: '''?''' means a spot with ? or S. This is an unreliable spot.
: '''P''' means a spot with P or C. This is a fairly reliable spot.
: '''V''' means a spot with V. This spot is considered verified.

==Interacting with WSJT-X==

Important: When in a DXpedition/multi-station setting, always use local host 127.0.0.1 as the 
broadcast address to prevent packets being picked up by other stations in the network. 
Also, enabling the creation of local spots from decodes may overwhelm DXLog.

DXLog can add QSO performed with WSJT-X to its log. Note that this functionality only works 
for contests with grid as the first and only exchange or for DXPedition type logs.

DXLog can also create local spots from WSJT-X decodes by checking 
<code>Options|Broadcast|Spot WSJT-X decodes</code>.

To enable logging of WSJT-X QSO, set up WSJT-X to broadcast information:

[[image:Wsjt-x-udp.png]]

[[image:Radiobroadcastenable3.png]]

Activate DXLog's UDP listener by checking <code>Options|Broadcast|Receive broadcasts</code> and set 
the same port number as in WSTJ-X in DXLog's network configuration panel.

[[image:Dxlog-udp.png]]

==Using Winkey FSK==

Winkey FSK is not natively supported by DXLog's digital mode engines MMVARI or MMTTY but 
Rafal EI6LA has developed a plugin for MMTTY that makes this possible.

You can find it [https://github.com/RafalLukawiecki/WinKeyerMMTY here].

==Interfacing with LogHX==

Christian F8GHE has prepared a guide on how to do this.

You can find it [http://dxlog.net/sw/files/utilities/DXLOG-LogHX_UDP-config_v2.pdf here].

==Self-spotting==

More and more contests allow spotting your own station on the DX cluster.

DXLog supports this, even when operating unassisted, as long as you connect to the cluster.

DXLog has three mechanics for self-spotting.

DXLog blocks self spotting unless specifically allowed in the contest rules. 
Should you find that DXLog incorrectly allows or blocks self-spotting, please make 
the development team aware via the support reflector.

* The <tt>$SPOTME</tt> macro command. This macro will create a cluster spot of the station's
: call at the earliest 15 seconds after being invoked the first time on a new frequency.
: Thereafter it will spot as frequent as allowed by the contest. If the contest rules do not
: specify a minimum period, 10 minutes will be used.

* Checking the menu option <code>Tools|Data entry|Run F1 message self-spots when permitted</code>.
: Works exactly like the <tt>$SPOTME</tt> macro command but is triggered by sending the
: Run F1 message which happens when pressing <code>[Enter]</code> with an empty entry line
: in Run, pressing <code>[F1]</code> in Run, or with Auto-CQ.

* Clicking the menu item <code>Commands|Self-spot</code> or pressing its shortcut key <code>[Ctrl][S]</code>.
: This will immediately create a spot of the station's call but no more often than
: every two seconds to avoid accidental multiple spots.

==DXpedition use==

DXLog is a popular choice for top tier dxpeditions. Below we have collected advice based on experience 
on how to best use DXLog in a dxpedition setting.

* Use client/server networking between stations. Never use UDP over Wi-Fi or WAN links.
* Use the "Minimal data" option in ADIF export to save on satellite link cost.
* For Club Log real time upload, use [https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads Club Log's upload app]
* Club Log truncate QSO time to minutes so to avoid creating dupes when mixing manual and real time upload to Club Log, check ''QSO time in minutes'' when doing ADIF export.
* Use the "Minimal data" option in ADIF export to save on satellite link cost.
* Follow [[Additional_Information#Interacting_with_WSJT-X|the instructions]] to log QSO made with WSJT-X and MSHV.
* Check <code>Options|Broadcast|Spot WSJT-X decodes</code> to make decoded calls appear in e.g., DX cluster announcements.
* You can extend the number of digits in the QSO count with <code>Options|Log|QSO number digits</code>

==Beacon spots on DX cluster==

Although propagation measurements based on FT8 communications has reduced the 
value of beacons, there are still hundreds of them in operation.

Identifying with CW, they are typically reported on reported on the DX cluster.

When beacon spots are received by DXLog, they are always displayed in the bandmap. 
In DXLog, beacon spots are recognized by having a trailing <tt>/B</tt>.

The DX cluster announcement window never shows or counts beacon spots.

Beacon spots can be enabled and disabled in the cluster node.

For CC Cluster, the commands are <tt>SET/BEACON</tt> and <tt>UNSET/BEACON</tt>.

For DXSpider, command is part of the <tt>SET/SKIMMER</tt> command where <tt>SET/SKIMMER</tt> 
or e.g., <tt>SET/SKIMMER CW BCN FT RTTY</tt> will pass beacon spots and <tt>UNSET/SKIMMER</tt> 
or any <tt>SET/SKIMMER</tt> listing modes but not BCN will block them.

AR 6 cluster nodes always pass beacon spots when skimmer spots are enabled. They cannot be disabled.

==Using Piper text-to-speech synthesis==

James M0DST has prepared 7 sample scripts that can be mapped to F keys.

James' comments on the scripts are:

This is just an extended proof of concept. Feel free to play using your own scripts. 
There is a lot of code duplication across the scripts. I may simplify some of this in the future. 
I tried base classes, but the current script engine would need some rework to support that. 
Repeat isn't supported. You will need to press the key manually. 
Multiple op voices are not supported currently. You could hack this in with little effort. 
There is no documentation at present. This feature is experimental whilst I decide how I want 
to move it forward (if at all). If you want to adjust the speed, you can do it per script. 
See SpeakingRate in the F2 script. Lower number is faster.

You can visit https://rhasspy.github.io/piper-samples/ to hear the voices. Set the model in the script.

Any comments or thoughts on anything related to this should be sent to me directly or on the list.

I really suggest training your own voice. I haven't done it yet, but I will when I have time. 
Using common amateur radio phrases in the training data will help teach it to sound more like a ham.

If you improve the scripts, please send them to me and I will update the files behind this link. 
Once everything is stable and formalized I will pass the links to Bjorn for the website, and we 
will add some real documentation.

Experimental scripts:
[https://drive.google.com/file/d/1EhfOpxsL57yuf-1WorASnGf-SBsmfqu7/view?usp=drive_link F1]
[https://drive.google.com/file/d/1MgviBec7HCXIOJZtDZXl0qXlrU-TwMoD/view?usp=drive_link F2]
[https://drive.google.com/file/d/1yAgY5E-KdOcmToXMJQ2lRNhjBIQrJIb9/view?usp=drive_link F3]
[https://drive.google.com/file/d/1-ftWUhFlc4-quwGPIVmNujQ4q-J5E3EZ/view?usp=drive_link F4]
[https://drive.google.com/file/d/1h3C_kLl9C4CEH6kATGAZbfDkfY6KlgqB/view?usp=drive_link F5]
[https://drive.google.com/file/d/1e4tAHz-_dU92RybaFeSuLCd0V7Gk_lWy/view?usp=drive_link F6]
[https://drive.google.com/file/d/1UGxgOpqOjOzl7yFTjrVaml9m5o8gBq5y/view?usp=drive_link F7]

Additional Information

2026-04-09T17:35:22Z

Sm7iun: /* Support for DXSpider */

==Using alternative configurations==

Window positions, coloring and general look and feel is saved in each log file but all other settings such as 
radio control, keying, and networking is saved in a common, contest-independent configuration file.

By default, the configuration file name is <tt>DXLog.net.config</tt> and it is located in the <tt>%appdata%\DXLog.net</tt> configuration folder.

This folder is also reachable via the <code>File|Open configuration folder</code> menu item.

[[image:configfolder.png]]

DXLog can be made to use an alternative configuration file with the command line option <tt>-cfg=<filename></tt>.

A convenient way to use this option is to create a separate Windows desktop shortcut including the command line option 
and give it a meaningful name.

[[image:Desktopshortcut.png]]

The command line option is simply added to the end of the Target text box in the shortcut's properties. 
Double-clicking the icon will start DXLog with the alternative configuration which will also be remembered between sessions. 
In the picture below the target of the shortcut is

[[image:Desktopshortcutconfig.png]]

'''Important:''' If you want to use an alternative configuration, do not just modify the desktop shortcut created at installation 
since this shortcut will be deleted when you upgrade DXLog. Instead make a copy, rename, and add the command line option. 
You should keep the command line option outside the apostrophes, like this

<tt>"C:\Program Files (x86)\DXLog.net\DXLog.net.exe" -cfg=SO2R.config</tt>

==Using a number server==

For contests involving serial numbers you need to secure that the sent number and the (slightly later) 
logged serial numbers are the same. In a straightforward SO1R or SO2V scenario, serial numbers are simply 
chronological but in more complex station configurations such as Multi-single or Multi-2 with inband, and 
advanced SO2R, QSO can be interleaved and requires a central source source of serial numbers together 
with a mechanic to protect an already sent serial number from re-use by another radio.

In DXLog this is achieved with a central number server. A number server can be used either 
by a single instance of DXLog (for SO2R) or by multiple stations on the same LAN.

The use of a number server involves three, natural, steps:

* Activating the server on a single station
* Making sure all stations use it
* Verifying functionality, making sure serial numbers are correctly reserved

The number server is activated in the <code>Options|Configure network</code> panel, described [[Menu_Options#Configure_network|HERE]].

[[image:startnumberserver.png]]

Since the server uses a networking socket, <code>Options|Networking</code> must be enabled '''also''' when 
using a single computer in SO2R. In the case of multiple stations, UDP networking or Client-Server 
networking must also be enabled to transfer the numbers over the LAN. For SO2R, this is however not 
necessary. When using Client-Server networking, a client cannot be number server.

There must only be one number server in a local network and all stations using it must have 
<code>Options|Networking|Use number server</code> checked like in the picture below.

'''Important:''' The number client/server functionality is not very robust. 
If you have stations joining/leaving your network or being rebooted, it is 
best to restart DXLog on all stations to guarantee correct function.

[[image:usenumberserver.png]]

The option <code>Block logging if serial number reservation is unsuccessful</code> can be used as an extra precaution 
but is not necessary in SO2R since the communication with the number server does not leave the computer.

There are three methods for reserving a number from the server:

* Checking <code>Tools|Data entry|Space key reserves serial number</code> and using the space key to reserve serial numbers. This is typically used on phone or when operating "old school" with F-keys.
* Checking <code>Tools|Data entry|Insert and F2 messages reserve serial number</code> and letting DXLog automatically reserve a serial number right before $SERIAL sends it. This is the preferred and most straightforward way for CW and digital.
* Adding the $RESERVENR macro to messages like illustrated below. 

These methods can of course also be combined. 

The $RESERVENR macro is "smart" and will only reserve a serial number if the callsign entry field is not empty and a 
serial number is not already reserved. The same goes for the menu items.

[[image:reservemessages.PNG]]

The sign of a serial number being reserved is that it turns red. It then stays reserved (and red) until the 
QSO is logged or the entry line is cleared with <code>[Alt][W]</code>.

An option that can prove useful is <code>Tools|Data entry|Cancel serial number reservation only if callsign field is empty</code>. 
In the case that you send the exchange and realize you got the other station's callsign call completely wrong, a reflex can be to hit 
<code>[Alt][W]</code> and start typing. If this is your habit, this option will prevent you from releasing the 
already sent serial number, thereby avoiding you the trouble to send a new one to the other station.

[[image:reservednumber.png]]

==Networking over internet==

When, for instance, activating a special event callsign it is possible to network multiple DXLog stations over the internet.

'''Pro tip:''' Consider displaying the callsign, message ID, Message text, etc. fields in the ''Network status'' 
window when operating a distributed station. Also, learn to use the gab <code>[Alt][G]</code> and <code>[Alt][J]</code> function.

===VLAN/VPN Solution===

The most secure way for remote networking is to rely on a VLAN (virtual LAN) software. There are several available such as:

ZeroTier https://www.zerotier.com/ 
FreeLan http://www.freelan.org/ 
Player.me https://player.me/ 
OpenVPN https://openvpn.net/

Each VLAN solutions have their own particular set up which is covered in their respective documentations. 
With a VLAN solution, all DXLog configurations are the same as when operating in a regular LAN however with a few exceptions.

One weakness with connections over the internet (a.k.a. WAN), including VLAN solutions, is that they are prone to packet loss. 
Packet loss is disastrous to DXLog's (or any logger's) "standard" UDP networking.

It is therefore essential to use '''only client/server networking over a VLAN'''. 
'''This also means you should never use interlock over an internet connection unless you use a zero packet loss VPN tunnel.'''

ZeroTier is particularly popular since it is free.

Since DXLog is able to mix TCP (client/server) and UDP (peer-to-peer) networking, a distributed station set up should be configured to rely on TCP 
for the wide-area network and UDP for the local network at each station location. Below you will find the station 
set up for the Swedish HQ station SE9HQ in the 2019 IARU HF Championship. The DXLog.net.DXC cluster client was run 
on SK3W-A which distributed spots to all stations over the network. Inband interlock was also used at the SK3W location.

[[image:SE9HQ-network-eng.png|800px]]

Important to note:

* For the server as well as the main clients, ''Server IP'' should be set to the server's VLAN IP address, '''not''' its LAN address.
* The '''server''' should check both "Act as network server" and "UDP network broadcast for multiple stations".
* The '''main clients''' should check both "Connect to network server" and "UDP network broadcast for multiple stations".
* The '''sub clients''' should check only "UDP networking for multiple stations".
* Interlock (which is UDP-based) over VLAN does not work reliably because of packet loss.
: Therefore, it is important to configure any interlock to '''only''' consider relevant operating positions,
: which all must be local. Use the possibility to only consider named stations for the interlock in the software 
: interlock set up. <code>Options|Networking|Software interlock</code> "Custom station ID(s)"
* For a large set-up with many stations connecting as clients to a central server you may overload the server if you also
: distribute spots via all client-server connections. In this case, check the "No spots via client/server" option
: on all stations and use '''local DX cluster connections''' via UDP at each location.
: '''Important:''' Limitations in Windows networking makes client/server networking unreliable beyond 10 station locations.
* Make sure to check <code>Options->Load contest at startup</code> to avoid opening the wrong log after a restart.
* '''Remote commands are not forwarded''' in the network but are executed in the station where they arrive.
: Thus, to clear all logs, disconnect networking on each main client, execute the remote command CLEARLOGNOW on each main client
: to clear the logs of all sub clients and do not reconnect until the server and all other main clients have done the same.

===Port forwarding Solution===

If you are less worried about competitors or government agencies listening in on your contest data, 
it is possible to route the traffic directly over the internet using port forwarding at the server.

'''Important security notice: This solution is not without risk. It offers no security or authentication. 
Any DXLog station running the same contest configuration, knowing the URL or IP address and IP port of the 
server can connect to the server station. There are no means to disconnect a station by force.'''

Also note the comment about '''remote commands''' in the section above.

With a port forwarding solution, the following must be observed:

* '''Server configuration'''
:* Only one of the stations should be configured as the '''server'''.
:* "Connect to network server" should not be checked on this station and
:: "UDP networking for multiple stations" should only be enabled if it is used to
:: communicate with a cluster client or other stations locally on the same LAN.
:: Either use a central cluster connection (uncheck "No spots via client/server")
:: or use one cluster connection per station location (check "No spots via client/server").
:: If one cluster connection per station location is used, make sure they
:: all use different SSID to prevent disconnects, such as E7HQ-1, E7HQ-2, etc.
:: This will ensure the cluster node regards all connections as having the same callsign
:: which is essential for e.g., correctly receiving own spots.
:* The PC acting as server must be configured for a fixed LAN IP address. This is done
:: either by manually configuring the networking settings in the PC to use a fixed
:: LAN IP address, or by setting up the router in the server's LAN to to always allocate
:: the same IP address to it.
:* The internet connection used by the server PC must ''either'' have a fixed public IP address ''or''
:: use dynamic DNS. Otherwise clients will not be able to reliable connect over the internet.
:* The server's TCP/IP port (e.g., <code>9888</code>) must be forwarded to the server by the server LAN's router.
:: Only TCP traffic should be forwarded. DXLog UDP traffic is not carried well over the internet.

:: [[image:serverconfig.png|600px]]
:: '''Example configuration for server for networking over internet'''

::[[image:portforwarding.png|600px]]
::'''Example of port forwarding UI in router'''

* '''All other stations'''
:* All other PC in the multi-station set up should be set up as clients.
:* Over the internet, "Server:" is either the static, public IP address of the server's internet
:: connection (e.g. <code>5.140.211.42</code>) or the dynamic DNS address (e.g. <code>hq.sm7iun.se</code>).
:: Clients connecting over the internet does not have to enable UDP networking and ''should not''
:: enable a server.
:* A client may connect via UDP if it is on the same LAN as the server ''or'' a "main client".
:: A "main client" is a client that connects to the server using the "Connect to network server" option in
:: the networking set up panel. A "main client" acts as a UDP gateway which means that if
:: several computers on a LAN are part of the same multi station set up but the server is located
:: elsewhere, only one computer in that LAN needs to connect as a client and the rest can use UDP.
:* Software interlock is UDP-based and can only reliably be used locally. Never over the internet.
:: If used, make sure the interlock is explicitly limited to local stations. See above for more details.

::[[image:clientconfig.png|600px]]
::'''Example configuration of client for networking over internet'''

* In a multi-station setting it is recommended to enable
: <code>Options|Networking|Block standard messages if no operator is logged on</code>
* Make sure <code>Options|Enable network</code> is checked.
* It is also a very good idea to check <code>Options|Load contest at startup</code> to reduce the
: risk of the wrong contest log file being loaded by any stations.

==Real time upload to Club Log Live Stream==

'''Important:''' Club Log truncates QSO time to minutes which means that if you mix real time upload 
with manual upload, make sure to check "QSO time in minutes" when creating ADIF export files.

The author of Club Log, Michael Wall, G7VJR, has developed a very powerful agent for real time uploads. 
It works with all the three major loggers, DXLog, N1MM Logger+, and Win-Test.

It can either be used as is, with a command line user interface, or with an optional user interface front end.

Information on how to download and configure it can be found [[https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads HERE]]

The Club Log Gateway can either listen to DXLog's native multi-station networking protocol or to N1MM style XML broadcast.

To use DXLog's networking protocol, make sure the same port (default 9888) is used in the gateway and DXLog 
and that UDP networking is enabled in DXLog. Do not enable QSO broadcast.

Although this works, it is recommended to use N1MM style broadcast since it contains information like logged on operator, etc.

To use this make sure the port (default 12060) is the same in N1MM port setting in the gateway and in the 
QSO broadcast port settings in DXLog's network configuration. Also make sure to se the DXLog port number 
in the gateway is not the same as that used in DXLog to avoid QSO duplication.

Also set:

<code>Options|Broadcast|QSOs</code> 
<code>Options|Broadcast|QSOs</code> 
<code>Options|Broadcast|Use N1MM QSO format</code> 
<code>Options|Broadcast|QSO time in minutes only</code>

'''Important:''' If you are going to also upload exported ADIF files to Club Log, it is important to also 
check "QSO time in minutes" in the ADIF export configuration to avoid creating virtual dupes, since Club 
Log does not know seconds.

==Diversity reception==

Diversity means receiving the same signal through two different receive chains, including antenna. 
With two antennas having different characteristics this can give substantial benefits in receiving 
fading and/or weak signals or separating calls in a large pile-up. Particularly on low bands.

DXLog supports diversity operation on a selected number of radio models.

For the supported radios, diversity operation can be toggled on and off using <code>[Ctrl][-]</code> or <code>[Ctrl][Keypad -]</code>.

If enabled via the radio's controls, DXLog will automatically detect diversity operation and enable 
the necessary mechanics. Diversity operation is indicated by a small DIV icon in the frequency 
counter box for the radio's band map.

'''Yaesu FTDX101D

Yaesu calls this feature "Sync" and it has a dedicated button up and left of the main VFO knob. 
Enabling this will make DXLog update both VFO with the same information when grabbing spots. 
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO. 
Since both VFO are kept on the same frequency, split operation is not supported.

'''ICOM IC-7851 and IC-7610

ICOM calls this feature "Tracking" and it can be enabled either via a menu entry or a long press on the "MAIN/SUB" button. 
Enabling this will make DXLog update both VFO with the same information when grabbing spots. 
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO. 
Since both VFO are kept on the same frequency, split operation is not supported.

'''Elecraft K3/K3S/K4

Elecraft calls this feature by its proper name. It is enabled by a long press on the "Sub" button. 
It should be noted that Elecraft's implementation where the main VFO controls both the main and 
sub receivers allows for split operation, i.e. transmitting on a different frequency using VFO B.

==UDP broadcast==

For interaction with other applications, DXLog can broadcast useful information as 
XML datagrams over UDP. 

There are five types of broadcast messages produced by DXLog:

* QSO information. Sent when logging.
* Radio information. Sent at changes as well as periodically.
* Antenna direction information. Sent when rotor control is invoked.
* Callsign look-up information
* Spots

QSO can be broadcasted in traditional DXLog format or in a more N1MM-like format.

Radio information can report SO2V as a single physical radio or as two physical radios, like N1MM.

There is an option to truncate the broadcasted QSO time to full minutes for better 
interoperability with some online services and software such as MSHV.

In addition, DXLog can also recognize QSY commands from Waterfall Bandmap and log QSO done as well as create 
local spots from decodes broadcasted by WSJT-X and its forks.

The broadcasting of QSO and radio related data is enabled using the <code>Options|Broadcast</code> submenu.

The broadcasting of spots is enabled by checking <code>Options|DX Cluster|Send spots to SmartSDR</code>.

[[image:radiobroadcastenable3.png]]

[[image:sendspotstosmartsdr.png]]

UDP broadcast parameters are configured in the <code>Options|Network configuration</code> panel. 
Please note that up to three ports can be specified for each broadcast, thereby supporting 
multiple receivers of the information.

[[image:Networksettingsbroadcast3.png]]

If you are writing a C# application to make use of these datagrams, there is a very nice online tool 
for creating an object from a sample XML datagram here https://xmltocsharp.azurewebsites.net/ 

In C# parsing is easily done using Linq. One example of XML parsing and deserialization using Linq 
can be found here https://github.com/bjornekelund/ICOMautomagic

===QSO information===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program
|-
| qsoid
| A unique string for this QSO. If this QSO is edited another contactinfo message will be sent with the same qsoid. Note that the qsoid is only unique within one instance of DXLog. If the computer is networked to others running DXLog the different computers may have a different qsoid for the same QSO.
|-
| contestname
| The name of the contest as it would be written to a Cabrillo file.
|-
| timestamp
| The UTC date and time of the QSO.
|-
| mycall
| The callsign of this station.
|-
| band
| The band on which the QSO was made. In MHz with period as decimal separator.
|-
| txfreq
| The frequency on which the QSO was made.
|-
| operator
| The callsign of the operator if the OPON command was used to set it, otherwise blank.
|-
| mode
| The mode used for the QSO.
|-
| call
| The callsign of the station worked.
|-
| countryprefix
| The DXCC country of the station worked.
|-
| wpxprefix
| The WPX prefix of the station worked.
|-
| snt
| The RST sent. This is always included whether or not the contest exchange contains an RST.
|-
| rcv
| The RST received. This is always included whether or not the contest exchange contains an RST.
|-
| nr
| The number sent if the exchange uses a serial number, otherwise the QSO number from this station.
|-
| exch1
| The first element in the contest exchange if any.
|-
| exch2
| The second element in the contest exchange if any.
|-
| exch3
| The third element in the contest exchange if any.
|-
| exch4
| The fourth element in the contest exchange if any.
|-
| xqso
| True if this QSO should not be counted towards the score.
|-
| invalid
| True if this QSO is invalid, for example a DX QSO in a domestic contest.
|-
| duplicate
| True if this QSO is a dupe (the station has previously been worked).
|-
| rule10broken
| True if this QSO breaks the 10 minute or similar rule. Note that a QSO may not break the 10 minute rule when it is logged but may later if another QSO is edited. This may not cause a broadcast.
|-
| azimuth
| The approximate direction of the station worked, in degrees.
|-
| distance
| The approximate distance of the station worked, in kilometers.
|-
| stationid
| The station ID of the station which made the QSO.
|-
| stationqso
| A unique QSO ID generated by the logging station. The combination of stationid and stationqso forms a unique identifier for the QSO.
|-
| stationtype
| The type of station - R for run, R1 for run 1 etc.
|-
| local
| True if this broadcast is due to this QSO being logged or edited on this computer.
|-
| runqso
| True if QSO logged in Run, false if S&P, and empty if unknown. '''Important:''' Only valid when local is True.
|-
| mult1
| The name of the multiplier if this station is a new multipllier, empty otherwise.
|-
| mult2
| The name of the multiplier if this station is a new multiplier, emtpy otherwise.
|-
| mult3
| The name of the multiplier if this station is a new multiplier, empty otherwise.
|-
| points
| The logged points for the QSO.
|-
| period
| The number of the operating period.
|-
| guid
| The GUID in hex format.
|-
| newqso
| True if a new QSO, False if this message is an update to an existing QSO.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<contactinfo>
<logger>DXLog v2.4.13</logger>
<qsoid>19</qsoid>
<contestname>ARRL-SS-CW</contestname>
<timestamp>2020-01-13 18:28:07</timestamp>
<mycall>SM7IUN</mycall>
<band>3.5</band>
<txfreq>352376</txfreq>
<operator></operator>
<mode>CW</mode>
<call>K4BAI</call>
<countryprefix>K</countryprefix>
<wpxprefix>K4</wpxprefix>
<snt>599</snt>
<rcv>599</rcv>
<nr>19</nr>
<exch1>076</exch1>
<exch2>B</exch2>
<exch3>54</exch3>
<exch4>GA</exch4>
<xqso>False</xqso>
<invalid>False</invalid>
<duplicate>False</duplicate>
<rule10broken>False</rule10broken>
<azimuth>225</azimuth>
<distance>1388</distance>
<stationid>STN1</stationid>
<stationqso>19</stationqso>
<stationtype>R1</stationtype>
<local>True</local>
<runqso>True</local>
<mult1>GA</mult1>
<mult2></mult2>
<mult3></mult3>
<points>3</points>
<period>1</period>
<guid>11223344556677889900aabbccddeeff</newqso>
<newqso>True</newqso>
</contactinfo>
</pre>

Alternative N1MM format

Note that the band name uses the computer's local number format so it may use either comma 
or period as decimal separator. The ID is a number rather than an alphanumeric string.

Also note that IsRunQSO is only valid when IsOriginal is True.

<pre><?xml version="1.0" encoding="utf-8"?>
<contactinfo>
<app>N1MM</app>
<contestname>CWOps</contestname>
<timestamp>2020-01-17 16:43:38</timestamp>
<mycall>SM7IUN</mycall>
<band>3.5</band>
<rxfreq>352519</rxfreq>
<txfreq>352519</txfreq>
<operator></operator>
<mode>CW</mode>
<call>K1XM</call>
<countryprefix>K</countryprefix>
<wpxprefix>K1</wpxprefix>
<stationprefix>K1XM</stationprefix>
<continent>NA</continent>
<snt>599</snt>
<sntnr>5</sntnr>
<rcv>599</rcv>
<misctext></misctext>
<ismultiplier1>1</ismultiplier1>
<ismultiplier2>0</ismultiplier2>
<ismultiplier3>0</ismultiplier3>
<points>l</points>
<radionr>l</radionr>
<run1run2>1<run1run2>
<IsOriginal>False</IsOriginal>
<NetBiosName>DESKTOP-23AB</NetBiosName>
<IsRunQSO>0</IsRunQSO>
<StationName>STATION_B</StationName>
<ID>23</ID>
<IsClaimedQso>true</IsClaimedQso>
</contactinfo>
</pre>

===Radio information===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| The name of the logging program.
|-
| logger
| The name and version of the logging program.
|-
| Station
| The ID of the station.
|-
| RadioNr
| The radio being described.
|-
| Freq
| The receiving frequency.
|-
| TXFreq
| The transmitting frequency
|-
| InactiveFreq
| The frequency of the VFO not receiving.
|-
| Mode
| The reported radio's mode.
|-
| OpCall
| The callsign of the operator if the OPON command was used to set it, otherwise blank.
|-
| mycall
| The callsign of the station.
|-
| IsRunning
| "True" if the station is running, "False" if search and pounce.
|-
| FocusEntry
| The Windows handle for the focused entry window.
|-
| Antenna
| Antenna number.
|-
| Rotors
| Rotators used by selected antenna (not currently used by DXLog).
|-
| FocusRadioNr
| The radio which has keyboard focus. In SO2V with "Report SO2V as two radios" checked, radio 2 is the sub/B VFO.
|-
| IsStereo
| True if headphones are listening to two radios.
|-
| IsSplit
| True if radio is set to split.
|-
| ActiveRadioNr
| The radio which is transmitting, if any.
|-
| Technique
| SO1R, SO2R, SO2R_ADV, or SO2V
|-
| StationType
| Station role: R, M, R1, R2, or R+.
|-
| isTransmitting
| True if a DXLog is transmitting. False if DXLog is not aware of transmission.
|-
| IFFrequency
| Optional element only used with Elecraft K3/K4. Contains the current IF frequency in Hz.
|-
|}

Important note: In SO2V the format differs from some other loggers and is:

: Only physical radio 1 is reported.
: <tt>Freq</tt> and <tt>TXFreq</tt> are the frequency of the currently focused VFO.
: <tt>InactiveFreq</tt> is the frequency of the currently unfocused VFO.
: <tt>ActiveRadio</tt> is always 1.
: <tt>FocusedRadioNr</tt> is 1 when the main/A VFO is focused, 2 otherwise.
: <tt>IsSplit</tt> is always false.

With the option "Report SO2V as two radios" checked, the reporting is similar to some other loggers and is:

: The two VFO are reported as two physical radios.
: <tt>Freq</tt> and <tt>TXFreq</tt> for radio 1 are the frequency of the main/A VFO.
: <tt>Freq</tt> and <tt>TXFreq</tt> for radio 2 are the frequency of the sub/B VFO.
: <tt>InactiveFreq</tt> is the frequency of the other VFO.
: <tt>ActiveRadio</tt> and <tt>FocusedRadioNr</tt> are 1 when the main/A VFO is focused, 2 otherwise.
: <tt>IsSplit</tt> is always false.

Example message:

<pre><?xml version = "1.0"?>
<RadioInfo>
<app>DXLog</app>
<logger>DXLog v2.4.13</logger>
<Station>STN1</Station>
<RadioNr>1</RadioNr>
<Freq>704000</Freq>
<TXFreq>704000</TXFreq>
<InactiveFreq>702500</InactiveFreq>
<Mode>CW</Mode>
<OpCall>K1XM</OpCall>
<mycall>HQ9X</mycall>
<IsRunning>False</IsRunning>
<FocusEntry>591124</FocusEntry>
<Antenna>1</Antenna>
<Rotors>ABC</Rotors>
<FocusRadioNr>1</FocusRadioNr>
<IsStereo>False</IsStereo>
<IsSplit>False</IsSplit>
<ActiveRadioNr>1</ActiveRadioNr>
<Technique>SO2R</Technique>
<StationType>R1</StationType>
<IsTransmitting>False</IsTransmitting>
<IFFrequency>8215000</IFFrequency>
</RadioInfo>
</pre>

===Antenna direction===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program.
|-
| station
| The ID of the station.
|-
| radio
| The radio associated with the rotator.
|-
| go
| True if the rotator should be turned.
|-
| stop
| True if the rotator should be stopped if it is turning.
|-
| azimuth
| The direction to turn the rotator if go is True.
|-
| frequency
| The transmit frequency of the specified radio.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<Rotator>
<logger>DXLog v2.4.13</logger>
<station>STN1</station>
<radio>2</radio>
<go>True</go>
<azimuth>252</azimuth>
<frequency>2800200</frequency>
</Rotator>

</pre>
<pre><?xml version="1.0" encoding="utf-8"?>
<Rotator>
<logger>DXLog v2.4.13</logger>
<station>STN1</station>
<radio>2</radio>
<stop>True</stop>
<frequency>2800200</frequency>
</Rotator>
</pre>

===Callsign lookup===

Sent either when callsign in entry row is changed or when space or tab is pressed.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program.
|-
| contestname
| The name of the contest.
|-
| mycall
| Station's call
|-
| band
| Current band
|-
| txfreq
| Transmitter frequency
|-
| operator
| The call sign of the logged in operator
|-
| mode
| Operating mode
|-
| call
| Call entered in the logging field
|-
| countryprefix
| DXCC entity prefix
|-
| wpxprefix
| WPX prefix
|-
| azimuth
| Short path antenna direction
|-
| distance
| Distance in km
|-
| stationid
| The ID of the station sending the datagram
|-
| stationtype
| The role of the station sending the datagram; R, R1, R2, M, or R+
|-
| period
| Contest period
|-
| reason
| Reason for transmission; SpaceOrTab or CallChanged
|-
|}

Example message:

<pre><?xml version = "1.0"?>
<lookupinfo>
<logger>DXLog v2.4.20</logger>
<contestname>DARC-WAEDC-CW</contestname>
<mycall>K1XM</mycall>
<band>20</band>
<txfreq>1400200</txfreq>
<operator></operator>
<mode>CW</mode>
<call>E7DX</call>
<countryprefix>E7</countryprefix>
<wpxprefix>E7</wpxprefix>
<azimuth>54</azimuth>
<distance>6824</distance>
<stationid></stationid>
<stationtype>R</stationtype>
<period>1</period>
<reason>SpaceOrTab</reason>
</lookupinfo>
</pre>

===Spot===

Sent for every incoming spot from the DX cluster that is valid for the current contest.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| Application sending the message.
|-
| StationName
| The station issuing the broadcast.
|-
| dxcall
| The callsign of the spotted station.
|-
| frequency
| Frequency in kHz with decimal sign of the PC's current locale. (sic)
|-
| spottercall
| The callsign of the spotter. Station name if locally spotted or result of a logging operation.
|-
| timestamp
| Spot time in format yyyy-MM-dd HH:mm:ss
|-
| action
| add or delete.
|-
| mode
| actual or guessed mode of the spot in capitals.
|-
| comment
| The comment section of the spot.
|-
| status
| Spot status. Valid values are "dupe", "double mult", "single mult", and "new qso".
|-
| statuslist
| Same as status
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<spot>
<app>DXLog.net</app>
<StationName>CONTEST-PC</StationName>
<dxcall>E7DX</dxcall>
<frequency>14022.3</frequency>
<spottercall>SM7IUN-#</spottercall>
<timestamp>2O23-07-15 14:29:37</timestamp>
<action>add</action>
<mode>CW</mode>
<comment>CW 31 DB 42 WPM CQ</comment>
<status>single mult</status>
<statuslist>single mult</statuslist>
</spot></pre>

===Broadcast listener===

DXLog also listens for commands over UDP.

Currently only one command is implemented, <code><radio_setfrequency></code>, which is a QSY command.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| Application sending the command
|-
| radionr
| The radio to be changed. In SO2V radio 2 means VFO B. Optional as of DXLog 2.5.20.
|-
| frequency
| Requested frequency. Both period and comma is accepted as decimal separator.
|-
| mousebutton
| Which mouse button was used to create message, if any. Optional.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<radio_setfrequency>
<app>WaterfallBandmap</app>
<radionr>1</radionr>
<frequency>21022.194</frequency>
<mousebutton>Left</mousebutton>
</radio_setfrequency>
</pre>

==SDR integration==

===HDSDR, OmniRig, and microHAM===

''Contributed by Ingo SM5AJV/SE5E''

Until DXLog offers SDR integration there are still ways to get a waterfall/spectrum display with DXLog.

I have integrated the free SDR software [http://www.hdsdr.de/ HDSDR] with DXLog using
[http://www.microham.com Microham Device Router], 
[http://dxatlas.com/OmniRig/ OmniRig]
and [https://www.autohotkey.com/ AutoHotkey].

As illustrated below I place the HDSDR window at the very top of the desktop with DXLog right below.

I share my transceiver's (an Elecraft K3) antenna with the SDR. The receiver antenna signal from my 
K3's RX-ANT OUT is connected to the input of a 3dB power splitter. The two outputs from the splitter 
are connected RX-ANT IN on the K3 and the SDR Receiver antenna input, respectively. On a K3 you 
need to enable the RX-antenna input to make this to work. An additional benefit with this method 
is that the SDR is protected during transmission. It is a widely used method and is e.g. described 
by Bob N6TV in this
[http://dxlog.net/sw/files/utilities/Adding%20an%20SDR%20to%20an%20SO2R%20Station.pdf presentation].

'''Screenshot of my desktop:

[[Image:Sdrdesktop.png|800px]]

Since both DXLog and HDSDR need to communicate with the radio, you need to "split" 
the CAT communication. microHAM's USB Device Router provides a second, independent, 
CAT port that can be used via HDSDR's omniRig interface.

'''"PORT" Tab on microHamRouter:

[[Image:Sdrmicrohamrouter.png|800px]]

'''OmniRig settings in HDSDR:

[[Image:Sdromnirig.png|200px]]

With this set up, the radio, DxLog, and HDSDR will be fully synchronized. For instance, you can 
click in the waterfall to make the radio QSY, and it is easy to quickly find a clean frequency.

To make the integration even better I use a small AutoHotkey script. The script pulls entry focus 
back to DxLog after clicking on the HDSDR waterfall and in DXLog it allows you to use hotkeys to 
control HDSDR. <code>[Ctrl][Alt]+</code> and <code>[Ctrl][Alt]-</code> zooms the waterfall/spectrum 
in and out, and <code>[Ctrl][Alt]C</code> centers it.

'''AutoHotkey script:

SetTitleMatchMode, 2
#InstallKeybdHook
#IfWinActive, HDSDR
{
F4:: return ; disable F4
~LButton Up::
sleep, 1
Winactivate, DXLog
return
}
#IfWinActive, DXLog
{
^!+:: ControlSend ,, ^{+}, HDSDR
^!-:: ControlSend ,, ^{-}, HDSDR
^!c:: ControlSend ,, {c}, HDSDR
}

The script can be downloaded [http://DXLog/sw/files/utilities/dxlog_hdsr.ahk here].

If you start two instances of HDSDR with two different SDR you can even have two waterfalls 
running at the same time.

I have not yet found a way to display cluster spots in the HDSDR spectrum panel. 
But I still find it very useful to check band activity and it allows me to easily find 
a new Run frequency on a crowded band.

===Waterfall Bandmap===

The free waterfall/spot display utility "Waterfall Bandmap" by Steve N2IC is supported by DXLog.

Waterfall Bandmap supports almost any SDR that produce I/Q output either via ExtIO.DLL or a 
sound card; SDRPlay, FunCubeProPlus, HackRF, SDR-IQ, RTLSDR, SoftRock, etc.

A zip file with an executable binary and a Microsoft word document with installation and 
configuration instructions can be found here: https://groups.io/g/waterfallbandmap/files

If you are not a member of the support forum group, you need to apply for membership to download. 
Membership is free.

[[Image:Waterfallbandmap.png]]

The SDR can be connected either to a separate receive antenna, an external receiver output on 
your transceiver or to an IF output, should your transceiver have one. If connected to an antenna, 
keep in mind that you may need protection from the transmitter such as a T/R relay or a passive level limiter.

Please refer to Waterfall Bandmap's documentation for setting it up with your SDR.

Waterfall Bandmap needs two information feeds over UDP: Radio information and spot information. 
Both are provided as UDP broadcast by DXLog.

The default port for both is 13063 and this needs to be set in DXLog's Network configuration panel. 
If Waterfall Bandmap runs on the same computer as DXLog, the broadcast address can be left at the default 127.0.0.1.

[[Image:Setbroadcastportsforwfbandmap.png]]

Clicking on the waterfall display can set the frequency of DXLog. (Left click sets VFO A, right click sets VFO B.) 
To enable this functionality, check the option <code>Options|Broadcast|Receive Broadcasts</code> 
Also make sure "UDP broadcast listener" includes port 13064 in the network settings panel.

The radio information feed needs to be enabled by checking the <code>Options|Broadcast|Radio information</code> option

[[Image:radiobroadcastenable2.png]]

and the spot feed needs to be enabled by checking the <code>Options|DX Cluster|Send spots to SmartSDR</code> option.

[[Image:Enablesendspotstosmartsdr.png]]

==Time synchronization==

In a multi-station setting, the time needs to be accurately synchronized across all networked PC.

Windows' built in time synchronization is very crude and for a PC with poor clock stability the 
inaccuracy of the clock may be up to a minute. Which of course is not acceptable for contesting.

DXLog has built in support for time synchronization as described in the [[Menu Options#Configure network|Configure network section]].

Due to Windows' security system, this however requires all except the PC running as time server to 
run DXLog with elevated permissions. There is unfortunately no way around this inconvenience.

An equally accurate and less intrusive method is to use a standalone time synchronization application on each networked PC. 
This will keep each PC's clock accurate within a fraction of a second.

Contrary to a solution built into a logger it also has the great benefit of being an "install and forget" solution.

A popular application is Dimension 4 by Thinking Man Software. It is free for personal use and 
can be downloaded here: https://dxlog.net/sw/files/utilities/d4time531.msi

It runs in the background and only shows up as a tiny icon in your system tray. 
You hover the mouse above the icon to check status and right-click to open and change settings.

:::[[image:dimension4tray.png|50px]]

After installation a brief configuration is required.

First of all, allow the application to disable Windows' time service and to modify your system clock.

For maximum accuracy, select a time server geographically close to your location. 
When in doubt, you can always add the global server "pool.ntp.org" to the list and use that. 

There are also national and continental pools of time servers. You can find them here https://www.ntppool.org.

[[image:dimension4b.png]]

Make sure the check boxes "Load Dimension 4 at startup", "Start minimized", "Hide when minimized", 
and "Display icon in tray" are all checked.

[[image:dimension4advanced.png]]

Click the Advanced button and also make sure the option "Use the selected server" is selected.

Make sure the application reports a successful connection to the selected time server. 
From here on, you can basically forget the application. 
It will silently start with your PC and always keep its time accurate.

==Disabling USB power management==

In the interest of saving energy, Windows habitually power down USB interfaces 
when it believes there is inactivity. Some USB-to-serial and USB audio devices 
respond poorly to being suspended or powered down so as a rule this "feature" should 
be disabled when used in a ham radio environment.

There are two places where this functionality needs to be disabled; the device driver 
and Windows' energy management.

To disable it for each USB interface and device, open Windows settings. (Click the Windows 
icon in the lower left corner and then chose the cogwheel.) Type ''device manager'' and
select the result.

[[image:devicemanager-c.png|none|frame]]

This opens up a new window, Windows' Device Manager.

[[image:devicemanager2b.png|none|frame]]

For '''every''' USB interface component (there may be many), COM-port, and audio device, 
and '''uncheck''' the option ''Allow the computer to turn this device off to save power''.

The devices you are looking for are in the categories: ''Ports (COM & LPT)'', 
''Sound, video and game controllers'', ''Universal serial bus controllers'',

Note that some devices may not have a ''Power Management'' tab.

[[image:usbdevicemanager.png|none|frame]]

The next step is to disable Windows ''Selective suspend'' feature for USB interfaces.

Go back to Windows Settings and type ''edit power'', click the appearing ''Edit power plan'' menu entry.

[[image:editpowerplan2.png|none|frame]]

This should open the window below, the plan editing panel.

[[image:editplansettings.png|none|frame]]

Click ''Change advanced power settings''. Scroll down to ''USB settings'' and make 
sure ''USB selective suspend setting'' is '''disabled''' for all situations.

[[image:Advancedsettings.png|none|frame]]

To prevent audio devices from becoming unreachable or going into sleep mode you should also 
disable exclusive access. While changing this, also make sure all audio enhancements are disabled.

You reach the detailed audio device settings by entering Windows settings, search for Control panel, 
and in the Control panel view, select Hardware and audio, and then Sound.

[[image:Audiodevice.png]]

Reboot your computer to make sure all settings are recognized by Windows.

==Interlock and inband operation==

In contest station terminology, the term ''Interlock'' refers to a technical solution preventing 
more than one station from using a shared resource, typically an antenna, at the same time.

The most common use for interlock is for inband operation. Inband operation means to have multiple 
transmitters on a single band, interleaving their transmissions. Sometimes on a split-second basis.

As long as you never have more than one transmitter active at any time, the majority of contests allow 
an unlimited number of transmitters and receivers on a single band for multi-operator categories. 
This fact is used by most big contest stations.

For an inband solution to be effective, each station must be able to receive while the 
other station transmits. This means it requires a separate, high performance receive antenna 
with very good isolation from the transmitter antenna. The most common way to 
achieve this is physical separation and geographic orientation to minimize the situations 
when they will radiate/listen in the direction of the other antenna.

For a station operating in the M/M, M/S, or M/2 category, inband operation can boost the points 
per hour performance significantly. It is also a lot more fun.

However, as with everything else, it comes at a cost. An efficient inband solution has:

* A high performance receive antenna for each operated band(s) with very good isolation from the transmitter antenna.
* A fail-safe antenna switching hardware.
* Interlock-capable keyers and/or station controllers.
* An interlock-capable contest logging software

A typical inband configuration can be seen in the illustration below.

[[image:inbandconcept-trx.jpg|800px]]

DXLog offers a software-based interlock which can be configured in a variety of ways, e.g. based on frequency 
band, operating mode, or station role. It supports an unlimited number of stations interlocking each other 
using a great variety of strategies.

The interlock relies on UDP networking and is overlaid on the communication for multi-station logging. 
UDP networking has the benefit of speed and low latency but is, unlike TCP, susceptible to packet loss. 
This means that a '''wired LAN''' is a necessity for any station using interlock. 
For the same reason, it is also not recommended to run interlock over e.g. VLAN/VPN link for 
geographically distributed stations.

A software interlock is not 100% reliable. Computer or software malfunction, networking issues such as packet 
loss, etc. can cause interlock to fail, even if only momentarily.

For this reason it is necessary to also accompany a software interlock with a fail-safe '''hardware''' interlock. 
Without hardware supported interlock you run the risk of not only violating contest rules but also cause serious equipment damage. 
Some contests, such as CQ WW, explicitly requires hardware interlock when using multiple stations on the same band.

There are many designs and even commercial products available for hardware interlock. 
One example of a simple but effective two station hardware interlock which also supports 
power amplifier sharing can be found [https://sm7iun.se/contest/inband/ HERE].

The purpose of this section is to describe steps of setting up a basic two station in-band solution with 
DXLog and microHAM keyers. The microHAM keyers are not mandatory but offers a much better user experience 
and removes the need for additional hardware.

'''Pro tip:''' Consider checking <code>Options|Networking|Allow other stations to abort sending</code> 
which will allow your partner station to interrupt your transmission with <code>[Shift][Esc]</code> in 
critical situations. Be careful though, the use of this function requires good judgment to avoid violence.

===Networking===

Open the networking configuration panel with <code>Options|Configure network</code> and make sure each 
station has a unique name and that only UDP networking is enabled.

Make sure the two stations use the same broadcast IP address and that it is in line with your LAN's 
configuration. Pressing the <tt>Default</tt> button is a good way to ensure this.

Make sure the menu option <code>Options|Enable network</code> has a checkmark.

[[image:inbandnetworkrun.png|left|frame]][[image:inbandnetworkinband.png|none|frame]] 

===DXLog Interlock configuration===

First of all, make sure that the <code>Options|Interface specific options|Prevent TX if another radio is on same band</code> 
is '''not''' enabled. This option completely prevents transmission if more than one networked station is set to the same band 
and the whole idea with inband is to have exactly that.

Next, activate software interlock on both stations using the menu option <code>Options|Networking|Software interlock</code> 
or by typing the commmand <tt>ILOCKON</tt>.

[[image:inbandinterlock2.png|none|frame]]

There are multiple options for configuring the interlock. In a simple set up with only two stations, the topmost 
option ''Same band from status list'' is a good choice. This option will prevent more than one station transmitting 
on the same band, regardless of mode.

In an environment with many stations (such as a multi-operator-multi-transmitter station) it is 
recommended to use the bottom option to only interlock with one or several named stations. 
This will reduce both LAN traffic and inband operation latency. This is particularly important when 
running parts of the DXLog network over high latency links such as VLAN/VPN or if some stations (albeit not 
part of the interlock cluster) are connected via Wi-Fi.

For more advanced scenarios you can also use interlock based on mode or station type (e.g. Run 1, Run 2, Mult, etc.).

The "status list" listing the networked DXLog stations is displayed in the ''Status Window'' which is opened 
with <code>Windows|Status window</code> or <code>[Alt][J]</code>.

[[image:inbandstatuslist2.png]]

DXLog also offers great flexibility when it comes to interlock strategy. The most straightforward and 
most commonly used is ''First one wins''. This is also typically the behavior of "unintelligent" 
hardware solutions when not assisted by software. With this strategy, the station starting to transmit 
first can not be interrupted and always gets to finish its transmission.

[[image:inbandinterlockoptions.png]]

With a ''Last one wins'' strategy, the transmitting station can be interrupted. A carte blanche permission 
to interrupt all transmissions by the other station may however be counterproductive in a real contest situation.

For this reason, DXLog offers additional control of which transmit actions can be interrupted and which can not. 
This is a powerful tool but requires both operators to be aware of it and may require 
practice before fully effective.

[[image:inbandstrategyexceptions.png]]

''F1'' through ''F7'', ''PLUS'' and ''INS'' refers to DXLog's standard messages. ''KEYB'' means a free text transmission 
from the keyboard using the <code>[Alt][K]</code> function and ''MAN'' means manual transmission using either paddle 
break-in or a footswitch.

For CW, DXLog recognizes paddle break in from a K1EL Winkey-compatible keyer as described in the [[Menu_Options#Winkey_Configuration|Winkey configuration section]].

Since DXLog recognizes a footswitch connected to a microHAM device, this is a recommended approach for phone. 
It is also possible to connect a footswitch to the DSR pin (pin 6) on a physical COM-port on the PC, but today 
few PC have such a port and it also requires additional circuitry.
Details on how to do this is available [[Additional_Information#Connecting_a_footswitch|HERE]].

===microHAM configuration===

Open the microHAM device configuration panel with <code>Options|microHAM device configuration</code>.

[[image:Mk2r-new9.png|none|frame]]

Check the option ''Enable TX lock/unlock''. This will do two things; it will enable DXLog to prevent 
transmission and and it will make DXLog aware of the microHAM device's PTT status. The latter is particularly 
important since it means DXLog will recognize PTT assertion not only by a footswitch connected to the 
microHAM device but also by the built-in Winkeyer (requires microHAM USB Device Router version 9.3.0 or later) 
'''Paddle-based break-in in an inband solution is currently unique for microHAM with DXLog.'''

'''Important:''' Making DXLog "PTT aware" means that care has to be taken in how PTT is set up. If you, for instance, 
enable DXLog PTT for the voice keyer, this will create a self-reinforcing feedback loop and PTT will thus never drop.

Check the option ''Dual radio device'' if you are using a u2R, MK2R, or MK2R+, otherwise, leave this unchecked.

Check the option ''Device without CAT interface'' if the device lacks a CAT interface (like the u2R) 
or if its CAT interface is not connected to the radio. This option will make sure the e.g. keying and 
audio routing is always set correctly in line with the operating mode (Voice, CW, or RTTY).

===Operating===

Inband operation requires a fair amount of training and it is a good idea to define and agree 
on general rules for operation, such as hand signals for challenging QSO, beforehand.

There are more than enough YouTube videos of inband operators yelling at each other.

The operating tactics may have to be adjusted during the contest. If Run is slow, 
doing S&P on the inband station can increase the points per minute significantly. 
However, if Run is strong, an overly active inband operator doing S&P, but not working 
multipliers, may actually reduce the station's points per minute significantly.

Real-time interlock status is shown in the ''Radio status'' window, which is opened with 
<code>Windows|Radio status</code>.

[[image:inbandblocking.png]] [[image:inbandblocked.png]]

For Phone contesting, you typically rely on footswitches for PTT and the option 
<code>Options|Networking|Show QSO status when blocking</code> makes the blocking 
station send a more helpful blocking cause than ''MAN''.

With this option enabled, the blocking station will instead send ''CQ'', ''QSO'', or ''EXCHANGE'' 
as blocking cause, determined by cursor location and entry field content at the locking station.

Further reading can be found in the [[Menu_Options#microHAM_device_configuration|microHAM device configuration]] and [[Menu_Options#Networking|Networking]] sections.

==Connecting a footswitch==

To free up both hands in Phone contesting, a footswitch PTT is a great help.

Also, to use interlock in Phone contesting, a footswitch is mandatory.

There are two basic ways to interface a footswitch with DXLog; via a microHAM device (which is the recommended solution) 
or directly connected to a physical serial port on the PC (which very few PC have today).

The connection of a footswitch to a microHAM device is very straightforward and by checking the ''Enable TX lock/unlock'' 
in the ''microHAM device configuration'' panel, it is recognized by DXLog.

Lacking a microHAM device, it is also possible to use the computer's DB9 RS-232 serial port connector, providing it has one.

The required steps to do this are:
* Connect a 10k resistor between DB9 pin 6 and pin 7.
* In the port's settings (<code>Options|Configure interfaces</code>) set DTR (pin 4) to ''Always On'' and RTS (pin 7) to ''Always Off'' for the port.
* Connect the footswitch between DB9 pins 4 and pin 6. '''Important:''' Neither pole on the footswitch must be connected to ground.
* In the radio's configuration panel, check ''use CAT PTT command on Phone'' and set ''Footswitch (pin 6)'' to ''PTT''

==Support for CC Cluster==

CC Cluster is today the main choice for contest use.

It offers a high quality, database-verified, flow of skimmer spots and a rapid 3-minute respotting period for skimmer spots.

It also publishes unique spots from less common locations which are valuable for DX chasers or as contest multipliers.

To make use of the display of own spot in the world map, make sure to issue the command '''<tt>SET/OWN</tt>''' to the cluster node. 
This setting is persistent and only needs to be done once.

A list of cluster nodes that runs CC Cluster can be found here: [https://www.dxcluster.info/telnet/index.php?software=CC%20Cluster CC Cluster nodes]

A description of the command line syntax can be found here: [http://bcdxc.org/ve7cc/ccc/CCC_Commands.htm CC Cluster command syntax]

A convenient software for setting up filters etc. can be found here [http://www.bcdxc.org/ve7cc/default.htm#prog CC User]

[[Image:Ccclustersspotflow.png]]

==Support for AR Cluster 6==

With the author tragically SK, AR Cluster is no longer under development but still available as an executable binary.

In its standard configuration, AR Cluster offers no consolidation of skimmer spots meaning a very high flow of spots 
that can become extreme during a major contest weekend.

With the advent of skimmers, the traffic on the DX Cluster has risen dramatically. Even though CW skimmers are generally 
quite reliable, the absolute number of busted spots can be quite high during a busy contest.

Jose CT1BOH has developed an algorithm for evaluating spot quality which is included in version 6 of AR Cluster. 
Today many cluster nodes runs this version and thereby offer this mechanic. 
A complete list can be found here: [http://www.dxcluster.info/telnet/index.php?software=AR-Cluster AR Cluster nodes]

To enable the functionality on a cluster node running AR Cluster 6, the command

<tt>'''SET DX EXTENSION SKIMMERQUALITY'''</tt>

needs to be issued to the cluster node. The easiest way to do this in DXLog is via <code>[Alt][T]</code>. 
This setting will be remembered at subsequent logins.

The quality of the spots is indicated by a character ("tag") in the last column of the comment field and, 
in some cases, a corrected callsign within parenthesis. This syntax is recognized by DXLog and can reduce the 
number of bad spots in your bandmap.

The CT1BOH skimmer quality algorithm is based on three parts:

; Validation : When a callsign is first spotted, it is tagged with "?" in the last column of the spot's comment field. If the callsign of an unverified spot closely resembles an already verified one on the same frequency, the verified callsign is provided within parenthesis in the spot's comment field. When two or more skimmers agree on the spot, it is considered verified and the tag becomes "V".

; Frequency : When a verified spot appears more than 0.35kHz off its verified frequency, the spot is tagged "Q" for QSY. Once verified, this becomes the new verified frequency and it is tagged "V".

; Probability : The algorithm checks uncertain spots for resemblance with already verified spots and spots at or near the same frequency. If the resemblance is high enough, the spot is considered busted "B" and the corrected callsign is provided within parenthesis in the spot's comment field.

Below you can see an example of the spot flow from W9PA-4 with skimmer quality enabled. 
The flow contains one unverified and one busted spot.

[[image:spotquality.png]]

DXLog's policy for spots with CT1BOH skimmer quality tags is the following:

: '''V''' - Accept spot.
: '''Q''' - Accept spot.
: '''?''' - Accept spot. Use corrected call when provided.
: '''B''' - Accept spot if corrected call provided. Else ignore.

DXLog recognizes the skimmer quality tags but consolidates them for consistency 
with other cluster nodes' quality tags and to minimize confusion when mixing spot flows. 
The legend is:

: '''?''' means a spot with ? This is an unreliable spot.
: '''P''' means a spot with Q or B with correction. This is a fairly reliable spot.
: '''V''' means a spot with V. This spot is considered validated.

This basic policy can be modified by using additional filters at the cluster node end. Some examples are:

: <tt>'''SET DX FILTER NOT SKIMBUSTED'''</tt> - Do not send busted spots at all
: <tt>'''SET DX FILTER NOT SKIMQSY'''</tt> - Do not send QSY spots
: <tt>'''SET DX FILTER SKIMVALID'''</tt> - Only send verified spots
: <tt>'''SET DX FILTER NOT SKIMUNKNOWN'''</tt> - Do not send unreliable spots
: <tt>'''SET DX FILTER SKIMMER'''</tt> - Do not send manual spots

You can also compose more complex filters such as:

: <tt>'''SET DX FILTER SKIMVALID OR SKIMBUSTED OR NOT SKIMMER'''</tt>

This can be a good filter for most contests. It will will only provide valid or busted skimmer spots together with manual spots. 
It is safe to receive busted spots since DXLog will ignore them if there is no corrected callsign included. 

For assisted operation in serious contesting you however need to allow also unknown spots since weak stations spotted 
only by one or a few skimmers may never reach validated status. You do this by adding <tt>'''OR SKIMUNKNOWN'''</tt> to the filter.

Both the bandmap and the DX cluster announcement windows have the option to display the spot quality tag. 
These windows will show two additional tags; L and C. L stands for local spot, created by yourself or one of your team members. 
C stands for corrected, i.e., a B or ? spot where a corrected call has been included in the spot's comment field.

The AR6 filtering syntax offers a lot of flexibility. Another example:

: <tt>'''SET DX FILTER (SKIMVALID OR NOT SKIMMER OR ((SKIMQSY OR SKIMUNKNOWN) AND (CTY <> K AND CONT <> EU )))'''</tt>

will provide only validated and human spots except if they are from outside the US and EU.

If you get lost in the filter settings you can always reset with : <tt>'''SET DX DEFAULT'''</tt>.

Some more guidance on how to work with filters on AR-Cluster nodes can be found in [http://dxlog.net/sw/files/utilities/AR_Cluster_v6_User_Manual.pdf this document].

==Support for DXSpider==

DXSpider is the most dominant DX cluster software but has historically not been a 
good choice for contesters. The reasons for this include: Long respotting time, lack 
of pass function for own spots, and suppression of spots from a single skimmer.

The good news is however that the author Dirk G1TLH has worked hard to address these 
aspects of the otherwise brilliant software.

From '''version 1.57 release 440''' the respotting time is now 3 minutes and there is a 
<tt>SET/SEEME</tt> command that passes all spots without consolidation of your own callsign.

So if your favorite cluster node is not running this version, ask the owner to upgrade asap.

Yet another reason for its popularity is its extreme resource-efficiency which allows it to run 
virtually any Linux capable hardware, including a $20 Raspberry Pi Zero.

A list of all DX cluster nodes running DX Spider can be found here: [https://www.dxcluster.info/telnet/index.php?software=DX%20Spider DX Spider cluster nodes]

[[image:dxspiderflow.png]]

DXLog recognizes the <tt>Q:#</tt> skimmer quality tag in the comment field and converts them into 
"CT1BOH-like" quality tags that can be displayed in DXLog's bandmap. The legend is:

: '''?''' means a spot with Q:1, i.e. heard by only one skimmer. This is an unreliable spot.
: '''P''' means a spot with Q:2, i.e. heard by only two skimmers. This is a fairly reliable spot.
: '''V''' means a spot with Q:3 or higher, i.e. heard by several skimmers. This spot is considered validated.

Since a DXSpider node currently needs to be specially configured by the owner to publish Q:1 spots, very few do this. 
Also, since DXSpider lacks busted call detection, the the quality of the spot flow will suffer if this is done.

A typical cluster line looks like this:

<tt><nowiki>DX de PY2MKU-# 14065.0 SM7IUN CW 29dB Q:9* Z:14,15,20 1922Z</nowiki></tt>

The Q parameter is the number of skimmers spotting the call. The trailing star means they do not quite agree 
on the frequency. A trailing plus means the station has been spotted for more than one hour. The Z parameter 
lists the CQ zones in which the callsign is spotted.

There is a wealth of information to be found on the [http://wiki.dxcluster.org/index.php/Main_Page DXSpider wiki].

==Support for N2WQ Cluster==

Introduced in late 2025, Rudy N2WQ has developed the first new DX cluster node software in decades.

The N2WQ-2 cluster has some unique features like a more advanced callsign validation than 
AR 6 and propagation estimation tags embedded in the spot comments. An example can be seen below.

[[image:n2wpspotflow.png]]

When you connect to dxc.n2wq.com port 8300 and you have set your 4-digit Maidenhead grid (SET GRID), there 
will be a single character just before the DX’s grid locator. This character is the path prediction glyph.

It is a crowdsourced, real-time estimate of how reliable the path is between you and the DX on that band right now, 
based on recent on-air propagation reports from RBN and PSKreporter. Its values and meaning are:

: > High: Strong path. If you can hear them, you should be able to work them.
: = Medium: Decent path. Workable with normal contest/DX technique.
: < Low: Weak path. Possible, but expect repeats, timing, and patience.
: - Unlikely: Marginal. Try only if it’s rare/needed, or you have a strong station advantage.

A missing glyph means insufficient data to estimate the path.

the glyph is mode-aware. A path that looks great for a very sensitive mode (FT8) can look 
more moderate for a less sensitive one (SSB).

You can filter spots by path reliability using the PASS/REJECT PATH command.

It is important to be aware that the glyph does not know:

: Your antenna gain/pattern, height, or takeoff angle
: Your transmit power and duty cycle constraints
: Your operating technique (timing, split discipline, pileup strategy)
: Short-lived phenomena the network has not yet “seen” such as sporadic E or aurora.

The cluster ingests upwards of 50,000 CW, FT, RTTY, and WSPR spots per minute. To compare different modes 
fairly, the system normalizes reports onto a common “FT8-equivalent” scale (so a CW SNR can be compared 
to an FT8 SNR).

Your grid and the DX grid are mapped into small geographic cells and the cluster calculates propagation 
at two levels:

: Fine (local): what’s happening close to your area (~180 miles).
:: On averages there are about 90,000 DE/DX pairs being tracked
: Coarse (regional): what’s happening in the broader region around
:: you (~480 miles). On average, there are about 30,000 DE/DX pairs.

If there isn’t enough local data, the system leans more on regional behavior. 
If there’s plenty of local data, it uses that more heavily.

Sometimes you can hear them better than they can hear you (or the reverse) due to noise 
floors, antennas, geography, or ionospheric effects. The system tracks both:

: Receive direction: DX to you (can you hear them?)
: Transmit direction: you to DX (can they hear you?)

It combines these into one “path reliability” estimate, weighting receive a bit more 
because if you can’t hear them, you can’t work them.

Propagation changes fast, so older reports get discounted using a half-life (data fades 
in influence over time). Typical behavior by band:

: Low bands (160/80m): slower changes (longer half-life)
: Mid bands (40–20m): medium pace
: High bands (15–6m): fast changes (shorter half-life)

In practice, this means glyphs can shift in minutes on 10m/6m, and more slowly on 80m/160m. 
Also, new openings take time to show up. A "insufficient" can simply mean “the path just opened 
and the cluster hasn’t collected enough recent reports yet.”

Your local noise floor heavily affects what you can receive, so the cluster lets you tell 
it what your noise environment is. This mainly tunes the receive-side expectation (DX to you).

Set it with SET NOISE SUBURBAN. Available profiles per ITU:

: QUIET: very low noise, rural/remote
: RURAL: mild noise
: SUBURBAN: typical neighborhood QRM
: URBAN: elevated noise, dense housing
: INDUSTRIAL: severe noise

If you don’t set it, the system may assume a quieter environment than you actually 
have, and your receive-side glyphs can look too optimistic.

Treat the glyph as a real-time probability hint that helps you spend your operating 
time where the odds are best. When you see > on a needed multiplier, move fast. 
When you see -, be intentional about whether it’s worth the time. 
And when you see a space, fall back to classic DX/contest instincts and your own ears.

The N2WQ cluster also offers spot quality tags between the DX grid and the time.

A quality (in terms of callsign reliability) tag can be V, P, S, C, or ? where V means validated, 
P highly likely, S less likely, C corrected, and ? unsure.

The propagation and quality tags can be displayed in the bandmaps and the DX cluster announcement window.

DXLog recognizes the skimmer quality tags but consolidates them before display for consistency 
with other cluster nodes' quality tags and to minimize confusion when mixing spot flows. 
The legend is:

: '''?''' means a spot with ? or S. This is an unreliable spot.
: '''P''' means a spot with P or C. This is a fairly reliable spot.
: '''V''' means a spot with V. This spot is considered verified.

==Interacting with WSJT-X==

Important: When in a DXpedition/multi-station setting, always use local host 127.0.0.1 as the 
broadcast address to prevent packets being picked up by other stations in the network. 
Also, enabling the creation of local spots from decodes may overwhelm DXLog.

DXLog can add QSO performed with WSJT-X to its log. Note that this functionality only works 
for contests with grid as the first and only exchange or for DXPedition type logs.

DXLog can also create local spots from WSJT-X decodes by checking 
<code>Options|Broadcast|Spot WSJT-X decodes</code>.

To enable logging of WSJT-X QSO, set up WSJT-X to broadcast information:

[[image:Wsjt-x-udp.png]]

[[image:Radiobroadcastenable3.png]]

Activate DXLog's UDP listener by checking <code>Options|Broadcast|Receive broadcasts</code> and set 
the same port number as in WSTJ-X in DXLog's network configuration panel.

[[image:Dxlog-udp.png]]

==Using Winkey FSK==

Winkey FSK is not natively supported by DXLog's digital mode engines MMVARI or MMTTY but 
Rafal EI6LA has developed a plugin for MMTTY that makes this possible.

You can find it [https://github.com/RafalLukawiecki/WinKeyerMMTY here].

==Interfacing with LogHX==

Christian F8GHE has prepared a guide on how to do this.

You can find it [http://dxlog.net/sw/files/utilities/DXLOG-LogHX_UDP-config_v2.pdf here].

==Self-spotting==

More and more contests allow spotting your own station on the DX cluster.

DXLog supports this, even when operating unassisted, as long as you connect to the cluster.

DXLog has three mechanics for self-spotting.

DXLog blocks self spotting unless specifically allowed in the contest rules. 
Should you find that DXLog incorrectly allows or blocks self-spotting, please make 
the development team aware via the support reflector.

* The <tt>$SPOTME</tt> macro command. This macro will create a cluster spot of the station's
: call at the earliest 15 seconds after being invoked the first time on a new frequency.
: Thereafter it will spot as frequent as allowed by the contest. If the contest rules do not
: specify a minimum period, 10 minutes will be used.

* Checking the menu option <code>Tools|Data entry|Run F1 message self-spots when permitted</code>.
: Works exactly like the <tt>$SPOTME</tt> macro command but is triggered by sending the
: Run F1 message which happens when pressing <code>[Enter]</code> with an empty entry line
: in Run, pressing <code>[F1]</code> in Run, or with Auto-CQ.

* Clicking the menu item <code>Commands|Self-spot</code> or pressing its shortcut key <code>[Ctrl][S]</code>.
: This will immediately create a spot of the station's call but no more often than
: every two seconds to avoid accidental multiple spots.

==DXpedition use==

DXLog is a popular choice for top tier dxpeditions. Below we have collected advice based on experience 
on how to best use DXLog in a dxpedition setting.

* Use client/server networking between stations. Never use UDP over Wi-Fi or WAN links.
* Use the "Minimal data" option in ADIF export to save on satellite link cost.
* For Club Log real time upload, use [https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads Club Log's upload app]
* Club Log truncate QSO time to minutes so to avoid creating dupes when mixing manual and real time upload to Club Log, check ''QSO time in minutes'' when doing ADIF export.
* Use the "Minimal data" option in ADIF export to save on satellite link cost.
* Follow [[Additional_Information#Interacting_with_WSJT-X|the instructions]] to log QSO made with WSJT-X and MSHV.
* Check <code>Options|Broadcast|Spot WSJT-X decodes</code> to make decoded calls appear in e.g., DX cluster announcements.
* You can extend the number of digits in the QSO count with <code>Options|Log|QSO number digits</code>

==Beacon spots on DX cluster==

Although propagation measurements based on FT8 communications has reduced the 
value of beacons, there are still hundreds of them in operation.

Identifying with CW, they are typically reported on reported on the DX cluster.

When beacon spots are received by DXLog, they are always displayed in the bandmap. 
In DXLog, beacon spots are recognized by having a trailing <tt>/B</tt>.

The DX cluster announcement window never shows or counts beacon spots.

Beacon spots can be enabled and disabled in the cluster node.

For CC Cluster, the commands are <tt>SET/BEACON</tt> and <tt>UNSET/BEACON</tt>.

For DXSpider, command is part of the <tt>SET/SKIMMER</tt> command where <tt>SET/SKIMMER</tt> 
or e.g., <tt>SET/SKIMMER CW BCN FT RTTY</tt> will pass beacon spots and <tt>UNSET/SKIMMER</tt> 
or any <tt>SET/SKIMMER</tt> listing modes but not BCN will block them.

AR 6 cluster nodes always pass beacon spots when skimmer spots are enabled. They cannot be disabled.

==Using Piper text-to-speech synthesis==

James M0DST has prepared 7 sample scripts that can be mapped to F keys.

James' comments on the scripts are:

This is just an extended proof of concept. Feel free to play using your own scripts. 
There is a lot of code duplication across the scripts. I may simplify some of this in the future. 
I tried base classes, but the current script engine would need some rework to support that. 
Repeat isn't supported. You will need to press the key manually. 
Multiple op voices are not supported currently. You could hack this in with little effort. 
There is no documentation at present. This feature is experimental whilst I decide how I want 
to move it forward (if at all). If you want to adjust the speed, you can do it per script. 
See SpeakingRate in the F2 script. Lower number is faster.

You can visit https://rhasspy.github.io/piper-samples/ to hear the voices. Set the model in the script.

Any comments or thoughts on anything related to this should be sent to me directly or on the list.

I really suggest training your own voice. I haven't done it yet, but I will when I have time. 
Using common amateur radio phrases in the training data will help teach it to sound more like a ham.

If you improve the scripts, please send them to me and I will update the files behind this link. 
Once everything is stable and formalized I will pass the links to Bjorn for the website, and we 
will add some real documentation.

Experimental scripts:
[https://drive.google.com/file/d/1EhfOpxsL57yuf-1WorASnGf-SBsmfqu7/view?usp=drive_link F1]
[https://drive.google.com/file/d/1MgviBec7HCXIOJZtDZXl0qXlrU-TwMoD/view?usp=drive_link F2]
[https://drive.google.com/file/d/1yAgY5E-KdOcmToXMJQ2lRNhjBIQrJIb9/view?usp=drive_link F3]
[https://drive.google.com/file/d/1-ftWUhFlc4-quwGPIVmNujQ4q-J5E3EZ/view?usp=drive_link F4]
[https://drive.google.com/file/d/1h3C_kLl9C4CEH6kATGAZbfDkfY6KlgqB/view?usp=drive_link F5]
[https://drive.google.com/file/d/1e4tAHz-_dU92RybaFeSuLCd0V7Gk_lWy/view?usp=drive_link F6]
[https://drive.google.com/file/d/1UGxgOpqOjOzl7yFTjrVaml9m5o8gBq5y/view?usp=drive_link F7]

Additional Information

2026-04-09T17:34:45Z

Sm7iun: /* Support for DXSpider */

==Using alternative configurations==

Window positions, coloring and general look and feel is saved in each log file but all other settings such as 
radio control, keying, and networking is saved in a common, contest-independent configuration file.

By default, the configuration file name is <tt>DXLog.net.config</tt> and it is located in the <tt>%appdata%\DXLog.net</tt> configuration folder.

This folder is also reachable via the <code>File|Open configuration folder</code> menu item.

[[image:configfolder.png]]

DXLog can be made to use an alternative configuration file with the command line option <tt>-cfg=<filename></tt>.

A convenient way to use this option is to create a separate Windows desktop shortcut including the command line option 
and give it a meaningful name.

[[image:Desktopshortcut.png]]

The command line option is simply added to the end of the Target text box in the shortcut's properties. 
Double-clicking the icon will start DXLog with the alternative configuration which will also be remembered between sessions. 
In the picture below the target of the shortcut is

[[image:Desktopshortcutconfig.png]]

'''Important:''' If you want to use an alternative configuration, do not just modify the desktop shortcut created at installation 
since this shortcut will be deleted when you upgrade DXLog. Instead make a copy, rename, and add the command line option. 
You should keep the command line option outside the apostrophes, like this

<tt>"C:\Program Files (x86)\DXLog.net\DXLog.net.exe" -cfg=SO2R.config</tt>

==Using a number server==

For contests involving serial numbers you need to secure that the sent number and the (slightly later) 
logged serial numbers are the same. In a straightforward SO1R or SO2V scenario, serial numbers are simply 
chronological but in more complex station configurations such as Multi-single or Multi-2 with inband, and 
advanced SO2R, QSO can be interleaved and requires a central source source of serial numbers together 
with a mechanic to protect an already sent serial number from re-use by another radio.

In DXLog this is achieved with a central number server. A number server can be used either 
by a single instance of DXLog (for SO2R) or by multiple stations on the same LAN.

The use of a number server involves three, natural, steps:

* Activating the server on a single station
* Making sure all stations use it
* Verifying functionality, making sure serial numbers are correctly reserved

The number server is activated in the <code>Options|Configure network</code> panel, described [[Menu_Options#Configure_network|HERE]].

[[image:startnumberserver.png]]

Since the server uses a networking socket, <code>Options|Networking</code> must be enabled '''also''' when 
using a single computer in SO2R. In the case of multiple stations, UDP networking or Client-Server 
networking must also be enabled to transfer the numbers over the LAN. For SO2R, this is however not 
necessary. When using Client-Server networking, a client cannot be number server.

There must only be one number server in a local network and all stations using it must have 
<code>Options|Networking|Use number server</code> checked like in the picture below.

'''Important:''' The number client/server functionality is not very robust. 
If you have stations joining/leaving your network or being rebooted, it is 
best to restart DXLog on all stations to guarantee correct function.

[[image:usenumberserver.png]]

The option <code>Block logging if serial number reservation is unsuccessful</code> can be used as an extra precaution 
but is not necessary in SO2R since the communication with the number server does not leave the computer.

There are three methods for reserving a number from the server:

* Checking <code>Tools|Data entry|Space key reserves serial number</code> and using the space key to reserve serial numbers. This is typically used on phone or when operating "old school" with F-keys.
* Checking <code>Tools|Data entry|Insert and F2 messages reserve serial number</code> and letting DXLog automatically reserve a serial number right before $SERIAL sends it. This is the preferred and most straightforward way for CW and digital.
* Adding the $RESERVENR macro to messages like illustrated below. 

These methods can of course also be combined. 

The $RESERVENR macro is "smart" and will only reserve a serial number if the callsign entry field is not empty and a 
serial number is not already reserved. The same goes for the menu items.

[[image:reservemessages.PNG]]

The sign of a serial number being reserved is that it turns red. It then stays reserved (and red) until the 
QSO is logged or the entry line is cleared with <code>[Alt][W]</code>.

An option that can prove useful is <code>Tools|Data entry|Cancel serial number reservation only if callsign field is empty</code>. 
In the case that you send the exchange and realize you got the other station's callsign call completely wrong, a reflex can be to hit 
<code>[Alt][W]</code> and start typing. If this is your habit, this option will prevent you from releasing the 
already sent serial number, thereby avoiding you the trouble to send a new one to the other station.

[[image:reservednumber.png]]

==Networking over internet==

When, for instance, activating a special event callsign it is possible to network multiple DXLog stations over the internet.

'''Pro tip:''' Consider displaying the callsign, message ID, Message text, etc. fields in the ''Network status'' 
window when operating a distributed station. Also, learn to use the gab <code>[Alt][G]</code> and <code>[Alt][J]</code> function.

===VLAN/VPN Solution===

The most secure way for remote networking is to rely on a VLAN (virtual LAN) software. There are several available such as:

ZeroTier https://www.zerotier.com/ 
FreeLan http://www.freelan.org/ 
Player.me https://player.me/ 
OpenVPN https://openvpn.net/

Each VLAN solutions have their own particular set up which is covered in their respective documentations. 
With a VLAN solution, all DXLog configurations are the same as when operating in a regular LAN however with a few exceptions.

One weakness with connections over the internet (a.k.a. WAN), including VLAN solutions, is that they are prone to packet loss. 
Packet loss is disastrous to DXLog's (or any logger's) "standard" UDP networking.

It is therefore essential to use '''only client/server networking over a VLAN'''. 
'''This also means you should never use interlock over an internet connection unless you use a zero packet loss VPN tunnel.'''

ZeroTier is particularly popular since it is free.

Since DXLog is able to mix TCP (client/server) and UDP (peer-to-peer) networking, a distributed station set up should be configured to rely on TCP 
for the wide-area network and UDP for the local network at each station location. Below you will find the station 
set up for the Swedish HQ station SE9HQ in the 2019 IARU HF Championship. The DXLog.net.DXC cluster client was run 
on SK3W-A which distributed spots to all stations over the network. Inband interlock was also used at the SK3W location.

[[image:SE9HQ-network-eng.png|800px]]

Important to note:

* For the server as well as the main clients, ''Server IP'' should be set to the server's VLAN IP address, '''not''' its LAN address.
* The '''server''' should check both "Act as network server" and "UDP network broadcast for multiple stations".
* The '''main clients''' should check both "Connect to network server" and "UDP network broadcast for multiple stations".
* The '''sub clients''' should check only "UDP networking for multiple stations".
* Interlock (which is UDP-based) over VLAN does not work reliably because of packet loss.
: Therefore, it is important to configure any interlock to '''only''' consider relevant operating positions,
: which all must be local. Use the possibility to only consider named stations for the interlock in the software 
: interlock set up. <code>Options|Networking|Software interlock</code> "Custom station ID(s)"
* For a large set-up with many stations connecting as clients to a central server you may overload the server if you also
: distribute spots via all client-server connections. In this case, check the "No spots via client/server" option
: on all stations and use '''local DX cluster connections''' via UDP at each location.
: '''Important:''' Limitations in Windows networking makes client/server networking unreliable beyond 10 station locations.
* Make sure to check <code>Options->Load contest at startup</code> to avoid opening the wrong log after a restart.
* '''Remote commands are not forwarded''' in the network but are executed in the station where they arrive.
: Thus, to clear all logs, disconnect networking on each main client, execute the remote command CLEARLOGNOW on each main client
: to clear the logs of all sub clients and do not reconnect until the server and all other main clients have done the same.

===Port forwarding Solution===

If you are less worried about competitors or government agencies listening in on your contest data, 
it is possible to route the traffic directly over the internet using port forwarding at the server.

'''Important security notice: This solution is not without risk. It offers no security or authentication. 
Any DXLog station running the same contest configuration, knowing the URL or IP address and IP port of the 
server can connect to the server station. There are no means to disconnect a station by force.'''

Also note the comment about '''remote commands''' in the section above.

With a port forwarding solution, the following must be observed:

* '''Server configuration'''
:* Only one of the stations should be configured as the '''server'''.
:* "Connect to network server" should not be checked on this station and
:: "UDP networking for multiple stations" should only be enabled if it is used to
:: communicate with a cluster client or other stations locally on the same LAN.
:: Either use a central cluster connection (uncheck "No spots via client/server")
:: or use one cluster connection per station location (check "No spots via client/server").
:: If one cluster connection per station location is used, make sure they
:: all use different SSID to prevent disconnects, such as E7HQ-1, E7HQ-2, etc.
:: This will ensure the cluster node regards all connections as having the same callsign
:: which is essential for e.g., correctly receiving own spots.
:* The PC acting as server must be configured for a fixed LAN IP address. This is done
:: either by manually configuring the networking settings in the PC to use a fixed
:: LAN IP address, or by setting up the router in the server's LAN to to always allocate
:: the same IP address to it.
:* The internet connection used by the server PC must ''either'' have a fixed public IP address ''or''
:: use dynamic DNS. Otherwise clients will not be able to reliable connect over the internet.
:* The server's TCP/IP port (e.g., <code>9888</code>) must be forwarded to the server by the server LAN's router.
:: Only TCP traffic should be forwarded. DXLog UDP traffic is not carried well over the internet.

:: [[image:serverconfig.png|600px]]
:: '''Example configuration for server for networking over internet'''

::[[image:portforwarding.png|600px]]
::'''Example of port forwarding UI in router'''

* '''All other stations'''
:* All other PC in the multi-station set up should be set up as clients.
:* Over the internet, "Server:" is either the static, public IP address of the server's internet
:: connection (e.g. <code>5.140.211.42</code>) or the dynamic DNS address (e.g. <code>hq.sm7iun.se</code>).
:: Clients connecting over the internet does not have to enable UDP networking and ''should not''
:: enable a server.
:* A client may connect via UDP if it is on the same LAN as the server ''or'' a "main client".
:: A "main client" is a client that connects to the server using the "Connect to network server" option in
:: the networking set up panel. A "main client" acts as a UDP gateway which means that if
:: several computers on a LAN are part of the same multi station set up but the server is located
:: elsewhere, only one computer in that LAN needs to connect as a client and the rest can use UDP.
:* Software interlock is UDP-based and can only reliably be used locally. Never over the internet.
:: If used, make sure the interlock is explicitly limited to local stations. See above for more details.

::[[image:clientconfig.png|600px]]
::'''Example configuration of client for networking over internet'''

* In a multi-station setting it is recommended to enable
: <code>Options|Networking|Block standard messages if no operator is logged on</code>
* Make sure <code>Options|Enable network</code> is checked.
* It is also a very good idea to check <code>Options|Load contest at startup</code> to reduce the
: risk of the wrong contest log file being loaded by any stations.

==Real time upload to Club Log Live Stream==

'''Important:''' Club Log truncates QSO time to minutes which means that if you mix real time upload 
with manual upload, make sure to check "QSO time in minutes" when creating ADIF export files.

The author of Club Log, Michael Wall, G7VJR, has developed a very powerful agent for real time uploads. 
It works with all the three major loggers, DXLog, N1MM Logger+, and Win-Test.

It can either be used as is, with a command line user interface, or with an optional user interface front end.

Information on how to download and configure it can be found [[https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads HERE]]

The Club Log Gateway can either listen to DXLog's native multi-station networking protocol or to N1MM style XML broadcast.

To use DXLog's networking protocol, make sure the same port (default 9888) is used in the gateway and DXLog 
and that UDP networking is enabled in DXLog. Do not enable QSO broadcast.

Although this works, it is recommended to use N1MM style broadcast since it contains information like logged on operator, etc.

To use this make sure the port (default 12060) is the same in N1MM port setting in the gateway and in the 
QSO broadcast port settings in DXLog's network configuration. Also make sure to se the DXLog port number 
in the gateway is not the same as that used in DXLog to avoid QSO duplication.

Also set:

<code>Options|Broadcast|QSOs</code> 
<code>Options|Broadcast|QSOs</code> 
<code>Options|Broadcast|Use N1MM QSO format</code> 
<code>Options|Broadcast|QSO time in minutes only</code>

'''Important:''' If you are going to also upload exported ADIF files to Club Log, it is important to also 
check "QSO time in minutes" in the ADIF export configuration to avoid creating virtual dupes, since Club 
Log does not know seconds.

==Diversity reception==

Diversity means receiving the same signal through two different receive chains, including antenna. 
With two antennas having different characteristics this can give substantial benefits in receiving 
fading and/or weak signals or separating calls in a large pile-up. Particularly on low bands.

DXLog supports diversity operation on a selected number of radio models.

For the supported radios, diversity operation can be toggled on and off using <code>[Ctrl][-]</code> or <code>[Ctrl][Keypad -]</code>.

If enabled via the radio's controls, DXLog will automatically detect diversity operation and enable 
the necessary mechanics. Diversity operation is indicated by a small DIV icon in the frequency 
counter box for the radio's band map.

'''Yaesu FTDX101D

Yaesu calls this feature "Sync" and it has a dedicated button up and left of the main VFO knob. 
Enabling this will make DXLog update both VFO with the same information when grabbing spots. 
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO. 
Since both VFO are kept on the same frequency, split operation is not supported.

'''ICOM IC-7851 and IC-7610

ICOM calls this feature "Tracking" and it can be enabled either via a menu entry or a long press on the "MAIN/SUB" button. 
Enabling this will make DXLog update both VFO with the same information when grabbing spots. 
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO. 
Since both VFO are kept on the same frequency, split operation is not supported.

'''Elecraft K3/K3S/K4

Elecraft calls this feature by its proper name. It is enabled by a long press on the "Sub" button. 
It should be noted that Elecraft's implementation where the main VFO controls both the main and 
sub receivers allows for split operation, i.e. transmitting on a different frequency using VFO B.

==UDP broadcast==

For interaction with other applications, DXLog can broadcast useful information as 
XML datagrams over UDP. 

There are five types of broadcast messages produced by DXLog:

* QSO information. Sent when logging.
* Radio information. Sent at changes as well as periodically.
* Antenna direction information. Sent when rotor control is invoked.
* Callsign look-up information
* Spots

QSO can be broadcasted in traditional DXLog format or in a more N1MM-like format.

Radio information can report SO2V as a single physical radio or as two physical radios, like N1MM.

There is an option to truncate the broadcasted QSO time to full minutes for better 
interoperability with some online services and software such as MSHV.

In addition, DXLog can also recognize QSY commands from Waterfall Bandmap and log QSO done as well as create 
local spots from decodes broadcasted by WSJT-X and its forks.

The broadcasting of QSO and radio related data is enabled using the <code>Options|Broadcast</code> submenu.

The broadcasting of spots is enabled by checking <code>Options|DX Cluster|Send spots to SmartSDR</code>.

[[image:radiobroadcastenable3.png]]

[[image:sendspotstosmartsdr.png]]

UDP broadcast parameters are configured in the <code>Options|Network configuration</code> panel. 
Please note that up to three ports can be specified for each broadcast, thereby supporting 
multiple receivers of the information.

[[image:Networksettingsbroadcast3.png]]

If you are writing a C# application to make use of these datagrams, there is a very nice online tool 
for creating an object from a sample XML datagram here https://xmltocsharp.azurewebsites.net/ 

In C# parsing is easily done using Linq. One example of XML parsing and deserialization using Linq 
can be found here https://github.com/bjornekelund/ICOMautomagic

===QSO information===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program
|-
| qsoid
| A unique string for this QSO. If this QSO is edited another contactinfo message will be sent with the same qsoid. Note that the qsoid is only unique within one instance of DXLog. If the computer is networked to others running DXLog the different computers may have a different qsoid for the same QSO.
|-
| contestname
| The name of the contest as it would be written to a Cabrillo file.
|-
| timestamp
| The UTC date and time of the QSO.
|-
| mycall
| The callsign of this station.
|-
| band
| The band on which the QSO was made. In MHz with period as decimal separator.
|-
| txfreq
| The frequency on which the QSO was made.
|-
| operator
| The callsign of the operator if the OPON command was used to set it, otherwise blank.
|-
| mode
| The mode used for the QSO.
|-
| call
| The callsign of the station worked.
|-
| countryprefix
| The DXCC country of the station worked.
|-
| wpxprefix
| The WPX prefix of the station worked.
|-
| snt
| The RST sent. This is always included whether or not the contest exchange contains an RST.
|-
| rcv
| The RST received. This is always included whether or not the contest exchange contains an RST.
|-
| nr
| The number sent if the exchange uses a serial number, otherwise the QSO number from this station.
|-
| exch1
| The first element in the contest exchange if any.
|-
| exch2
| The second element in the contest exchange if any.
|-
| exch3
| The third element in the contest exchange if any.
|-
| exch4
| The fourth element in the contest exchange if any.
|-
| xqso
| True if this QSO should not be counted towards the score.
|-
| invalid
| True if this QSO is invalid, for example a DX QSO in a domestic contest.
|-
| duplicate
| True if this QSO is a dupe (the station has previously been worked).
|-
| rule10broken
| True if this QSO breaks the 10 minute or similar rule. Note that a QSO may not break the 10 minute rule when it is logged but may later if another QSO is edited. This may not cause a broadcast.
|-
| azimuth
| The approximate direction of the station worked, in degrees.
|-
| distance
| The approximate distance of the station worked, in kilometers.
|-
| stationid
| The station ID of the station which made the QSO.
|-
| stationqso
| A unique QSO ID generated by the logging station. The combination of stationid and stationqso forms a unique identifier for the QSO.
|-
| stationtype
| The type of station - R for run, R1 for run 1 etc.
|-
| local
| True if this broadcast is due to this QSO being logged or edited on this computer.
|-
| runqso
| True if QSO logged in Run, false if S&P, and empty if unknown. '''Important:''' Only valid when local is True.
|-
| mult1
| The name of the multiplier if this station is a new multipllier, empty otherwise.
|-
| mult2
| The name of the multiplier if this station is a new multiplier, emtpy otherwise.
|-
| mult3
| The name of the multiplier if this station is a new multiplier, empty otherwise.
|-
| points
| The logged points for the QSO.
|-
| period
| The number of the operating period.
|-
| guid
| The GUID in hex format.
|-
| newqso
| True if a new QSO, False if this message is an update to an existing QSO.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<contactinfo>
<logger>DXLog v2.4.13</logger>
<qsoid>19</qsoid>
<contestname>ARRL-SS-CW</contestname>
<timestamp>2020-01-13 18:28:07</timestamp>
<mycall>SM7IUN</mycall>
<band>3.5</band>
<txfreq>352376</txfreq>
<operator></operator>
<mode>CW</mode>
<call>K4BAI</call>
<countryprefix>K</countryprefix>
<wpxprefix>K4</wpxprefix>
<snt>599</snt>
<rcv>599</rcv>
<nr>19</nr>
<exch1>076</exch1>
<exch2>B</exch2>
<exch3>54</exch3>
<exch4>GA</exch4>
<xqso>False</xqso>
<invalid>False</invalid>
<duplicate>False</duplicate>
<rule10broken>False</rule10broken>
<azimuth>225</azimuth>
<distance>1388</distance>
<stationid>STN1</stationid>
<stationqso>19</stationqso>
<stationtype>R1</stationtype>
<local>True</local>
<runqso>True</local>
<mult1>GA</mult1>
<mult2></mult2>
<mult3></mult3>
<points>3</points>
<period>1</period>
<guid>11223344556677889900aabbccddeeff</newqso>
<newqso>True</newqso>
</contactinfo>
</pre>

Alternative N1MM format

Note that the band name uses the computer's local number format so it may use either comma 
or period as decimal separator. The ID is a number rather than an alphanumeric string.

Also note that IsRunQSO is only valid when IsOriginal is True.

<pre><?xml version="1.0" encoding="utf-8"?>
<contactinfo>
<app>N1MM</app>
<contestname>CWOps</contestname>
<timestamp>2020-01-17 16:43:38</timestamp>
<mycall>SM7IUN</mycall>
<band>3.5</band>
<rxfreq>352519</rxfreq>
<txfreq>352519</txfreq>
<operator></operator>
<mode>CW</mode>
<call>K1XM</call>
<countryprefix>K</countryprefix>
<wpxprefix>K1</wpxprefix>
<stationprefix>K1XM</stationprefix>
<continent>NA</continent>
<snt>599</snt>
<sntnr>5</sntnr>
<rcv>599</rcv>
<misctext></misctext>
<ismultiplier1>1</ismultiplier1>
<ismultiplier2>0</ismultiplier2>
<ismultiplier3>0</ismultiplier3>
<points>l</points>
<radionr>l</radionr>
<run1run2>1<run1run2>
<IsOriginal>False</IsOriginal>
<NetBiosName>DESKTOP-23AB</NetBiosName>
<IsRunQSO>0</IsRunQSO>
<StationName>STATION_B</StationName>
<ID>23</ID>
<IsClaimedQso>true</IsClaimedQso>
</contactinfo>
</pre>

===Radio information===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| The name of the logging program.
|-
| logger
| The name and version of the logging program.
|-
| Station
| The ID of the station.
|-
| RadioNr
| The radio being described.
|-
| Freq
| The receiving frequency.
|-
| TXFreq
| The transmitting frequency
|-
| InactiveFreq
| The frequency of the VFO not receiving.
|-
| Mode
| The reported radio's mode.
|-
| OpCall
| The callsign of the operator if the OPON command was used to set it, otherwise blank.
|-
| mycall
| The callsign of the station.
|-
| IsRunning
| "True" if the station is running, "False" if search and pounce.
|-
| FocusEntry
| The Windows handle for the focused entry window.
|-
| Antenna
| Antenna number.
|-
| Rotors
| Rotators used by selected antenna (not currently used by DXLog).
|-
| FocusRadioNr
| The radio which has keyboard focus. In SO2V with "Report SO2V as two radios" checked, radio 2 is the sub/B VFO.
|-
| IsStereo
| True if headphones are listening to two radios.
|-
| IsSplit
| True if radio is set to split.
|-
| ActiveRadioNr
| The radio which is transmitting, if any.
|-
| Technique
| SO1R, SO2R, SO2R_ADV, or SO2V
|-
| StationType
| Station role: R, M, R1, R2, or R+.
|-
| isTransmitting
| True if a DXLog is transmitting. False if DXLog is not aware of transmission.
|-
| IFFrequency
| Optional element only used with Elecraft K3/K4. Contains the current IF frequency in Hz.
|-
|}

Important note: In SO2V the format differs from some other loggers and is:

: Only physical radio 1 is reported.
: <tt>Freq</tt> and <tt>TXFreq</tt> are the frequency of the currently focused VFO.
: <tt>InactiveFreq</tt> is the frequency of the currently unfocused VFO.
: <tt>ActiveRadio</tt> is always 1.
: <tt>FocusedRadioNr</tt> is 1 when the main/A VFO is focused, 2 otherwise.
: <tt>IsSplit</tt> is always false.

With the option "Report SO2V as two radios" checked, the reporting is similar to some other loggers and is:

: The two VFO are reported as two physical radios.
: <tt>Freq</tt> and <tt>TXFreq</tt> for radio 1 are the frequency of the main/A VFO.
: <tt>Freq</tt> and <tt>TXFreq</tt> for radio 2 are the frequency of the sub/B VFO.
: <tt>InactiveFreq</tt> is the frequency of the other VFO.
: <tt>ActiveRadio</tt> and <tt>FocusedRadioNr</tt> are 1 when the main/A VFO is focused, 2 otherwise.
: <tt>IsSplit</tt> is always false.

Example message:

<pre><?xml version = "1.0"?>
<RadioInfo>
<app>DXLog</app>
<logger>DXLog v2.4.13</logger>
<Station>STN1</Station>
<RadioNr>1</RadioNr>
<Freq>704000</Freq>
<TXFreq>704000</TXFreq>
<InactiveFreq>702500</InactiveFreq>
<Mode>CW</Mode>
<OpCall>K1XM</OpCall>
<mycall>HQ9X</mycall>
<IsRunning>False</IsRunning>
<FocusEntry>591124</FocusEntry>
<Antenna>1</Antenna>
<Rotors>ABC</Rotors>
<FocusRadioNr>1</FocusRadioNr>
<IsStereo>False</IsStereo>
<IsSplit>False</IsSplit>
<ActiveRadioNr>1</ActiveRadioNr>
<Technique>SO2R</Technique>
<StationType>R1</StationType>
<IsTransmitting>False</IsTransmitting>
<IFFrequency>8215000</IFFrequency>
</RadioInfo>
</pre>

===Antenna direction===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program.
|-
| station
| The ID of the station.
|-
| radio
| The radio associated with the rotator.
|-
| go
| True if the rotator should be turned.
|-
| stop
| True if the rotator should be stopped if it is turning.
|-
| azimuth
| The direction to turn the rotator if go is True.
|-
| frequency
| The transmit frequency of the specified radio.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<Rotator>
<logger>DXLog v2.4.13</logger>
<station>STN1</station>
<radio>2</radio>
<go>True</go>
<azimuth>252</azimuth>
<frequency>2800200</frequency>
</Rotator>

</pre>
<pre><?xml version="1.0" encoding="utf-8"?>
<Rotator>
<logger>DXLog v2.4.13</logger>
<station>STN1</station>
<radio>2</radio>
<stop>True</stop>
<frequency>2800200</frequency>
</Rotator>
</pre>

===Callsign lookup===

Sent either when callsign in entry row is changed or when space or tab is pressed.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program.
|-
| contestname
| The name of the contest.
|-
| mycall
| Station's call
|-
| band
| Current band
|-
| txfreq
| Transmitter frequency
|-
| operator
| The call sign of the logged in operator
|-
| mode
| Operating mode
|-
| call
| Call entered in the logging field
|-
| countryprefix
| DXCC entity prefix
|-
| wpxprefix
| WPX prefix
|-
| azimuth
| Short path antenna direction
|-
| distance
| Distance in km
|-
| stationid
| The ID of the station sending the datagram
|-
| stationtype
| The role of the station sending the datagram; R, R1, R2, M, or R+
|-
| period
| Contest period
|-
| reason
| Reason for transmission; SpaceOrTab or CallChanged
|-
|}

Example message:

<pre><?xml version = "1.0"?>
<lookupinfo>
<logger>DXLog v2.4.20</logger>
<contestname>DARC-WAEDC-CW</contestname>
<mycall>K1XM</mycall>
<band>20</band>
<txfreq>1400200</txfreq>
<operator></operator>
<mode>CW</mode>
<call>E7DX</call>
<countryprefix>E7</countryprefix>
<wpxprefix>E7</wpxprefix>
<azimuth>54</azimuth>
<distance>6824</distance>
<stationid></stationid>
<stationtype>R</stationtype>
<period>1</period>
<reason>SpaceOrTab</reason>
</lookupinfo>
</pre>

===Spot===

Sent for every incoming spot from the DX cluster that is valid for the current contest.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| Application sending the message.
|-
| StationName
| The station issuing the broadcast.
|-
| dxcall
| The callsign of the spotted station.
|-
| frequency
| Frequency in kHz with decimal sign of the PC's current locale. (sic)
|-
| spottercall
| The callsign of the spotter. Station name if locally spotted or result of a logging operation.
|-
| timestamp
| Spot time in format yyyy-MM-dd HH:mm:ss
|-
| action
| add or delete.
|-
| mode
| actual or guessed mode of the spot in capitals.
|-
| comment
| The comment section of the spot.
|-
| status
| Spot status. Valid values are "dupe", "double mult", "single mult", and "new qso".
|-
| statuslist
| Same as status
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<spot>
<app>DXLog.net</app>
<StationName>CONTEST-PC</StationName>
<dxcall>E7DX</dxcall>
<frequency>14022.3</frequency>
<spottercall>SM7IUN-#</spottercall>
<timestamp>2O23-07-15 14:29:37</timestamp>
<action>add</action>
<mode>CW</mode>
<comment>CW 31 DB 42 WPM CQ</comment>
<status>single mult</status>
<statuslist>single mult</statuslist>
</spot></pre>

===Broadcast listener===

DXLog also listens for commands over UDP.

Currently only one command is implemented, <code><radio_setfrequency></code>, which is a QSY command.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| Application sending the command
|-
| radionr
| The radio to be changed. In SO2V radio 2 means VFO B. Optional as of DXLog 2.5.20.
|-
| frequency
| Requested frequency. Both period and comma is accepted as decimal separator.
|-
| mousebutton
| Which mouse button was used to create message, if any. Optional.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<radio_setfrequency>
<app>WaterfallBandmap</app>
<radionr>1</radionr>
<frequency>21022.194</frequency>
<mousebutton>Left</mousebutton>
</radio_setfrequency>
</pre>

==SDR integration==

===HDSDR, OmniRig, and microHAM===

''Contributed by Ingo SM5AJV/SE5E''

Until DXLog offers SDR integration there are still ways to get a waterfall/spectrum display with DXLog.

I have integrated the free SDR software [http://www.hdsdr.de/ HDSDR] with DXLog using
[http://www.microham.com Microham Device Router], 
[http://dxatlas.com/OmniRig/ OmniRig]
and [https://www.autohotkey.com/ AutoHotkey].

As illustrated below I place the HDSDR window at the very top of the desktop with DXLog right below.

I share my transceiver's (an Elecraft K3) antenna with the SDR. The receiver antenna signal from my 
K3's RX-ANT OUT is connected to the input of a 3dB power splitter. The two outputs from the splitter 
are connected RX-ANT IN on the K3 and the SDR Receiver antenna input, respectively. On a K3 you 
need to enable the RX-antenna input to make this to work. An additional benefit with this method 
is that the SDR is protected during transmission. It is a widely used method and is e.g. described 
by Bob N6TV in this
[http://dxlog.net/sw/files/utilities/Adding%20an%20SDR%20to%20an%20SO2R%20Station.pdf presentation].

'''Screenshot of my desktop:

[[Image:Sdrdesktop.png|800px]]

Since both DXLog and HDSDR need to communicate with the radio, you need to "split" 
the CAT communication. microHAM's USB Device Router provides a second, independent, 
CAT port that can be used via HDSDR's omniRig interface.

'''"PORT" Tab on microHamRouter:

[[Image:Sdrmicrohamrouter.png|800px]]

'''OmniRig settings in HDSDR:

[[Image:Sdromnirig.png|200px]]

With this set up, the radio, DxLog, and HDSDR will be fully synchronized. For instance, you can 
click in the waterfall to make the radio QSY, and it is easy to quickly find a clean frequency.

To make the integration even better I use a small AutoHotkey script. The script pulls entry focus 
back to DxLog after clicking on the HDSDR waterfall and in DXLog it allows you to use hotkeys to 
control HDSDR. <code>[Ctrl][Alt]+</code> and <code>[Ctrl][Alt]-</code> zooms the waterfall/spectrum 
in and out, and <code>[Ctrl][Alt]C</code> centers it.

'''AutoHotkey script:

SetTitleMatchMode, 2
#InstallKeybdHook
#IfWinActive, HDSDR
{
F4:: return ; disable F4
~LButton Up::
sleep, 1
Winactivate, DXLog
return
}
#IfWinActive, DXLog
{
^!+:: ControlSend ,, ^{+}, HDSDR
^!-:: ControlSend ,, ^{-}, HDSDR
^!c:: ControlSend ,, {c}, HDSDR
}

The script can be downloaded [http://DXLog/sw/files/utilities/dxlog_hdsr.ahk here].

If you start two instances of HDSDR with two different SDR you can even have two waterfalls 
running at the same time.

I have not yet found a way to display cluster spots in the HDSDR spectrum panel. 
But I still find it very useful to check band activity and it allows me to easily find 
a new Run frequency on a crowded band.

===Waterfall Bandmap===

The free waterfall/spot display utility "Waterfall Bandmap" by Steve N2IC is supported by DXLog.

Waterfall Bandmap supports almost any SDR that produce I/Q output either via ExtIO.DLL or a 
sound card; SDRPlay, FunCubeProPlus, HackRF, SDR-IQ, RTLSDR, SoftRock, etc.

A zip file with an executable binary and a Microsoft word document with installation and 
configuration instructions can be found here: https://groups.io/g/waterfallbandmap/files

If you are not a member of the support forum group, you need to apply for membership to download. 
Membership is free.

[[Image:Waterfallbandmap.png]]

The SDR can be connected either to a separate receive antenna, an external receiver output on 
your transceiver or to an IF output, should your transceiver have one. If connected to an antenna, 
keep in mind that you may need protection from the transmitter such as a T/R relay or a passive level limiter.

Please refer to Waterfall Bandmap's documentation for setting it up with your SDR.

Waterfall Bandmap needs two information feeds over UDP: Radio information and spot information. 
Both are provided as UDP broadcast by DXLog.

The default port for both is 13063 and this needs to be set in DXLog's Network configuration panel. 
If Waterfall Bandmap runs on the same computer as DXLog, the broadcast address can be left at the default 127.0.0.1.

[[Image:Setbroadcastportsforwfbandmap.png]]

Clicking on the waterfall display can set the frequency of DXLog. (Left click sets VFO A, right click sets VFO B.) 
To enable this functionality, check the option <code>Options|Broadcast|Receive Broadcasts</code> 
Also make sure "UDP broadcast listener" includes port 13064 in the network settings panel.

The radio information feed needs to be enabled by checking the <code>Options|Broadcast|Radio information</code> option

[[Image:radiobroadcastenable2.png]]

and the spot feed needs to be enabled by checking the <code>Options|DX Cluster|Send spots to SmartSDR</code> option.

[[Image:Enablesendspotstosmartsdr.png]]

==Time synchronization==

In a multi-station setting, the time needs to be accurately synchronized across all networked PC.

Windows' built in time synchronization is very crude and for a PC with poor clock stability the 
inaccuracy of the clock may be up to a minute. Which of course is not acceptable for contesting.

DXLog has built in support for time synchronization as described in the [[Menu Options#Configure network|Configure network section]].

Due to Windows' security system, this however requires all except the PC running as time server to 
run DXLog with elevated permissions. There is unfortunately no way around this inconvenience.

An equally accurate and less intrusive method is to use a standalone time synchronization application on each networked PC. 
This will keep each PC's clock accurate within a fraction of a second.

Contrary to a solution built into a logger it also has the great benefit of being an "install and forget" solution.

A popular application is Dimension 4 by Thinking Man Software. It is free for personal use and 
can be downloaded here: https://dxlog.net/sw/files/utilities/d4time531.msi

It runs in the background and only shows up as a tiny icon in your system tray. 
You hover the mouse above the icon to check status and right-click to open and change settings.

:::[[image:dimension4tray.png|50px]]

After installation a brief configuration is required.

First of all, allow the application to disable Windows' time service and to modify your system clock.

For maximum accuracy, select a time server geographically close to your location. 
When in doubt, you can always add the global server "pool.ntp.org" to the list and use that. 

There are also national and continental pools of time servers. You can find them here https://www.ntppool.org.

[[image:dimension4b.png]]

Make sure the check boxes "Load Dimension 4 at startup", "Start minimized", "Hide when minimized", 
and "Display icon in tray" are all checked.

[[image:dimension4advanced.png]]

Click the Advanced button and also make sure the option "Use the selected server" is selected.

Make sure the application reports a successful connection to the selected time server. 
From here on, you can basically forget the application. 
It will silently start with your PC and always keep its time accurate.

==Disabling USB power management==

In the interest of saving energy, Windows habitually power down USB interfaces 
when it believes there is inactivity. Some USB-to-serial and USB audio devices 
respond poorly to being suspended or powered down so as a rule this "feature" should 
be disabled when used in a ham radio environment.

There are two places where this functionality needs to be disabled; the device driver 
and Windows' energy management.

To disable it for each USB interface and device, open Windows settings. (Click the Windows 
icon in the lower left corner and then chose the cogwheel.) Type ''device manager'' and
select the result.

[[image:devicemanager-c.png|none|frame]]

This opens up a new window, Windows' Device Manager.

[[image:devicemanager2b.png|none|frame]]

For '''every''' USB interface component (there may be many), COM-port, and audio device, 
and '''uncheck''' the option ''Allow the computer to turn this device off to save power''.

The devices you are looking for are in the categories: ''Ports (COM & LPT)'', 
''Sound, video and game controllers'', ''Universal serial bus controllers'',

Note that some devices may not have a ''Power Management'' tab.

[[image:usbdevicemanager.png|none|frame]]

The next step is to disable Windows ''Selective suspend'' feature for USB interfaces.

Go back to Windows Settings and type ''edit power'', click the appearing ''Edit power plan'' menu entry.

[[image:editpowerplan2.png|none|frame]]

This should open the window below, the plan editing panel.

[[image:editplansettings.png|none|frame]]

Click ''Change advanced power settings''. Scroll down to ''USB settings'' and make 
sure ''USB selective suspend setting'' is '''disabled''' for all situations.

[[image:Advancedsettings.png|none|frame]]

To prevent audio devices from becoming unreachable or going into sleep mode you should also 
disable exclusive access. While changing this, also make sure all audio enhancements are disabled.

You reach the detailed audio device settings by entering Windows settings, search for Control panel, 
and in the Control panel view, select Hardware and audio, and then Sound.

[[image:Audiodevice.png]]

Reboot your computer to make sure all settings are recognized by Windows.

==Interlock and inband operation==

In contest station terminology, the term ''Interlock'' refers to a technical solution preventing 
more than one station from using a shared resource, typically an antenna, at the same time.

The most common use for interlock is for inband operation. Inband operation means to have multiple 
transmitters on a single band, interleaving their transmissions. Sometimes on a split-second basis.

As long as you never have more than one transmitter active at any time, the majority of contests allow 
an unlimited number of transmitters and receivers on a single band for multi-operator categories. 
This fact is used by most big contest stations.

For an inband solution to be effective, each station must be able to receive while the 
other station transmits. This means it requires a separate, high performance receive antenna 
with very good isolation from the transmitter antenna. The most common way to 
achieve this is physical separation and geographic orientation to minimize the situations 
when they will radiate/listen in the direction of the other antenna.

For a station operating in the M/M, M/S, or M/2 category, inband operation can boost the points 
per hour performance significantly. It is also a lot more fun.

However, as with everything else, it comes at a cost. An efficient inband solution has:

* A high performance receive antenna for each operated band(s) with very good isolation from the transmitter antenna.
* A fail-safe antenna switching hardware.
* Interlock-capable keyers and/or station controllers.
* An interlock-capable contest logging software

A typical inband configuration can be seen in the illustration below.

[[image:inbandconcept-trx.jpg|800px]]

DXLog offers a software-based interlock which can be configured in a variety of ways, e.g. based on frequency 
band, operating mode, or station role. It supports an unlimited number of stations interlocking each other 
using a great variety of strategies.

The interlock relies on UDP networking and is overlaid on the communication for multi-station logging. 
UDP networking has the benefit of speed and low latency but is, unlike TCP, susceptible to packet loss. 
This means that a '''wired LAN''' is a necessity for any station using interlock. 
For the same reason, it is also not recommended to run interlock over e.g. VLAN/VPN link for 
geographically distributed stations.

A software interlock is not 100% reliable. Computer or software malfunction, networking issues such as packet 
loss, etc. can cause interlock to fail, even if only momentarily.

For this reason it is necessary to also accompany a software interlock with a fail-safe '''hardware''' interlock. 
Without hardware supported interlock you run the risk of not only violating contest rules but also cause serious equipment damage. 
Some contests, such as CQ WW, explicitly requires hardware interlock when using multiple stations on the same band.

There are many designs and even commercial products available for hardware interlock. 
One example of a simple but effective two station hardware interlock which also supports 
power amplifier sharing can be found [https://sm7iun.se/contest/inband/ HERE].

The purpose of this section is to describe steps of setting up a basic two station in-band solution with 
DXLog and microHAM keyers. The microHAM keyers are not mandatory but offers a much better user experience 
and removes the need for additional hardware.

'''Pro tip:''' Consider checking <code>Options|Networking|Allow other stations to abort sending</code> 
which will allow your partner station to interrupt your transmission with <code>[Shift][Esc]</code> in 
critical situations. Be careful though, the use of this function requires good judgment to avoid violence.

===Networking===

Open the networking configuration panel with <code>Options|Configure network</code> and make sure each 
station has a unique name and that only UDP networking is enabled.

Make sure the two stations use the same broadcast IP address and that it is in line with your LAN's 
configuration. Pressing the <tt>Default</tt> button is a good way to ensure this.

Make sure the menu option <code>Options|Enable network</code> has a checkmark.

[[image:inbandnetworkrun.png|left|frame]][[image:inbandnetworkinband.png|none|frame]] 

===DXLog Interlock configuration===

First of all, make sure that the <code>Options|Interface specific options|Prevent TX if another radio is on same band</code> 
is '''not''' enabled. This option completely prevents transmission if more than one networked station is set to the same band 
and the whole idea with inband is to have exactly that.

Next, activate software interlock on both stations using the menu option <code>Options|Networking|Software interlock</code> 
or by typing the commmand <tt>ILOCKON</tt>.

[[image:inbandinterlock2.png|none|frame]]

There are multiple options for configuring the interlock. In a simple set up with only two stations, the topmost 
option ''Same band from status list'' is a good choice. This option will prevent more than one station transmitting 
on the same band, regardless of mode.

In an environment with many stations (such as a multi-operator-multi-transmitter station) it is 
recommended to use the bottom option to only interlock with one or several named stations. 
This will reduce both LAN traffic and inband operation latency. This is particularly important when 
running parts of the DXLog network over high latency links such as VLAN/VPN or if some stations (albeit not 
part of the interlock cluster) are connected via Wi-Fi.

For more advanced scenarios you can also use interlock based on mode or station type (e.g. Run 1, Run 2, Mult, etc.).

The "status list" listing the networked DXLog stations is displayed in the ''Status Window'' which is opened 
with <code>Windows|Status window</code> or <code>[Alt][J]</code>.

[[image:inbandstatuslist2.png]]

DXLog also offers great flexibility when it comes to interlock strategy. The most straightforward and 
most commonly used is ''First one wins''. This is also typically the behavior of "unintelligent" 
hardware solutions when not assisted by software. With this strategy, the station starting to transmit 
first can not be interrupted and always gets to finish its transmission.

[[image:inbandinterlockoptions.png]]

With a ''Last one wins'' strategy, the transmitting station can be interrupted. A carte blanche permission 
to interrupt all transmissions by the other station may however be counterproductive in a real contest situation.

For this reason, DXLog offers additional control of which transmit actions can be interrupted and which can not. 
This is a powerful tool but requires both operators to be aware of it and may require 
practice before fully effective.

[[image:inbandstrategyexceptions.png]]

''F1'' through ''F7'', ''PLUS'' and ''INS'' refers to DXLog's standard messages. ''KEYB'' means a free text transmission 
from the keyboard using the <code>[Alt][K]</code> function and ''MAN'' means manual transmission using either paddle 
break-in or a footswitch.

For CW, DXLog recognizes paddle break in from a K1EL Winkey-compatible keyer as described in the [[Menu_Options#Winkey_Configuration|Winkey configuration section]].

Since DXLog recognizes a footswitch connected to a microHAM device, this is a recommended approach for phone. 
It is also possible to connect a footswitch to the DSR pin (pin 6) on a physical COM-port on the PC, but today 
few PC have such a port and it also requires additional circuitry.
Details on how to do this is available [[Additional_Information#Connecting_a_footswitch|HERE]].

===microHAM configuration===

Open the microHAM device configuration panel with <code>Options|microHAM device configuration</code>.

[[image:Mk2r-new9.png|none|frame]]

Check the option ''Enable TX lock/unlock''. This will do two things; it will enable DXLog to prevent 
transmission and and it will make DXLog aware of the microHAM device's PTT status. The latter is particularly 
important since it means DXLog will recognize PTT assertion not only by a footswitch connected to the 
microHAM device but also by the built-in Winkeyer (requires microHAM USB Device Router version 9.3.0 or later) 
'''Paddle-based break-in in an inband solution is currently unique for microHAM with DXLog.'''

'''Important:''' Making DXLog "PTT aware" means that care has to be taken in how PTT is set up. If you, for instance, 
enable DXLog PTT for the voice keyer, this will create a self-reinforcing feedback loop and PTT will thus never drop.

Check the option ''Dual radio device'' if you are using a u2R, MK2R, or MK2R+, otherwise, leave this unchecked.

Check the option ''Device without CAT interface'' if the device lacks a CAT interface (like the u2R) 
or if its CAT interface is not connected to the radio. This option will make sure the e.g. keying and 
audio routing is always set correctly in line with the operating mode (Voice, CW, or RTTY).

===Operating===

Inband operation requires a fair amount of training and it is a good idea to define and agree 
on general rules for operation, such as hand signals for challenging QSO, beforehand.

There are more than enough YouTube videos of inband operators yelling at each other.

The operating tactics may have to be adjusted during the contest. If Run is slow, 
doing S&P on the inband station can increase the points per minute significantly. 
However, if Run is strong, an overly active inband operator doing S&P, but not working 
multipliers, may actually reduce the station's points per minute significantly.

Real-time interlock status is shown in the ''Radio status'' window, which is opened with 
<code>Windows|Radio status</code>.

[[image:inbandblocking.png]] [[image:inbandblocked.png]]

For Phone contesting, you typically rely on footswitches for PTT and the option 
<code>Options|Networking|Show QSO status when blocking</code> makes the blocking 
station send a more helpful blocking cause than ''MAN''.

With this option enabled, the blocking station will instead send ''CQ'', ''QSO'', or ''EXCHANGE'' 
as blocking cause, determined by cursor location and entry field content at the locking station.

Further reading can be found in the [[Menu_Options#microHAM_device_configuration|microHAM device configuration]] and [[Menu_Options#Networking|Networking]] sections.

==Connecting a footswitch==

To free up both hands in Phone contesting, a footswitch PTT is a great help.

Also, to use interlock in Phone contesting, a footswitch is mandatory.

There are two basic ways to interface a footswitch with DXLog; via a microHAM device (which is the recommended solution) 
or directly connected to a physical serial port on the PC (which very few PC have today).

The connection of a footswitch to a microHAM device is very straightforward and by checking the ''Enable TX lock/unlock'' 
in the ''microHAM device configuration'' panel, it is recognized by DXLog.

Lacking a microHAM device, it is also possible to use the computer's DB9 RS-232 serial port connector, providing it has one.

The required steps to do this are:
* Connect a 10k resistor between DB9 pin 6 and pin 7.
* In the port's settings (<code>Options|Configure interfaces</code>) set DTR (pin 4) to ''Always On'' and RTS (pin 7) to ''Always Off'' for the port.
* Connect the footswitch between DB9 pins 4 and pin 6. '''Important:''' Neither pole on the footswitch must be connected to ground.
* In the radio's configuration panel, check ''use CAT PTT command on Phone'' and set ''Footswitch (pin 6)'' to ''PTT''

==Support for CC Cluster==

CC Cluster is today the main choice for contest use.

It offers a high quality, database-verified, flow of skimmer spots and a rapid 3-minute respotting period for skimmer spots.

It also publishes unique spots from less common locations which are valuable for DX chasers or as contest multipliers.

To make use of the display of own spot in the world map, make sure to issue the command '''<tt>SET/OWN</tt>''' to the cluster node. 
This setting is persistent and only needs to be done once.

A list of cluster nodes that runs CC Cluster can be found here: [https://www.dxcluster.info/telnet/index.php?software=CC%20Cluster CC Cluster nodes]

A description of the command line syntax can be found here: [http://bcdxc.org/ve7cc/ccc/CCC_Commands.htm CC Cluster command syntax]

A convenient software for setting up filters etc. can be found here [http://www.bcdxc.org/ve7cc/default.htm#prog CC User]

[[Image:Ccclustersspotflow.png]]

==Support for AR Cluster 6==

With the author tragically SK, AR Cluster is no longer under development but still available as an executable binary.

In its standard configuration, AR Cluster offers no consolidation of skimmer spots meaning a very high flow of spots 
that can become extreme during a major contest weekend.

With the advent of skimmers, the traffic on the DX Cluster has risen dramatically. Even though CW skimmers are generally 
quite reliable, the absolute number of busted spots can be quite high during a busy contest.

Jose CT1BOH has developed an algorithm for evaluating spot quality which is included in version 6 of AR Cluster. 
Today many cluster nodes runs this version and thereby offer this mechanic. 
A complete list can be found here: [http://www.dxcluster.info/telnet/index.php?software=AR-Cluster AR Cluster nodes]

To enable the functionality on a cluster node running AR Cluster 6, the command

<tt>'''SET DX EXTENSION SKIMMERQUALITY'''</tt>

needs to be issued to the cluster node. The easiest way to do this in DXLog is via <code>[Alt][T]</code>. 
This setting will be remembered at subsequent logins.

The quality of the spots is indicated by a character ("tag") in the last column of the comment field and, 
in some cases, a corrected callsign within parenthesis. This syntax is recognized by DXLog and can reduce the 
number of bad spots in your bandmap.

The CT1BOH skimmer quality algorithm is based on three parts:

; Validation : When a callsign is first spotted, it is tagged with "?" in the last column of the spot's comment field. If the callsign of an unverified spot closely resembles an already verified one on the same frequency, the verified callsign is provided within parenthesis in the spot's comment field. When two or more skimmers agree on the spot, it is considered verified and the tag becomes "V".

; Frequency : When a verified spot appears more than 0.35kHz off its verified frequency, the spot is tagged "Q" for QSY. Once verified, this becomes the new verified frequency and it is tagged "V".

; Probability : The algorithm checks uncertain spots for resemblance with already verified spots and spots at or near the same frequency. If the resemblance is high enough, the spot is considered busted "B" and the corrected callsign is provided within parenthesis in the spot's comment field.

Below you can see an example of the spot flow from W9PA-4 with skimmer quality enabled. 
The flow contains one unverified and one busted spot.

[[image:spotquality.png]]

DXLog's policy for spots with CT1BOH skimmer quality tags is the following:

: '''V''' - Accept spot.
: '''Q''' - Accept spot.
: '''?''' - Accept spot. Use corrected call when provided.
: '''B''' - Accept spot if corrected call provided. Else ignore.

DXLog recognizes the skimmer quality tags but consolidates them for consistency 
with other cluster nodes' quality tags and to minimize confusion when mixing spot flows. 
The legend is:

: '''?''' means a spot with ? This is an unreliable spot.
: '''P''' means a spot with Q or B with correction. This is a fairly reliable spot.
: '''V''' means a spot with V. This spot is considered validated.

This basic policy can be modified by using additional filters at the cluster node end. Some examples are:

: <tt>'''SET DX FILTER NOT SKIMBUSTED'''</tt> - Do not send busted spots at all
: <tt>'''SET DX FILTER NOT SKIMQSY'''</tt> - Do not send QSY spots
: <tt>'''SET DX FILTER SKIMVALID'''</tt> - Only send verified spots
: <tt>'''SET DX FILTER NOT SKIMUNKNOWN'''</tt> - Do not send unreliable spots
: <tt>'''SET DX FILTER SKIMMER'''</tt> - Do not send manual spots

You can also compose more complex filters such as:

: <tt>'''SET DX FILTER SKIMVALID OR SKIMBUSTED OR NOT SKIMMER'''</tt>

This can be a good filter for most contests. It will will only provide valid or busted skimmer spots together with manual spots. 
It is safe to receive busted spots since DXLog will ignore them if there is no corrected callsign included. 

For assisted operation in serious contesting you however need to allow also unknown spots since weak stations spotted 
only by one or a few skimmers may never reach validated status. You do this by adding <tt>'''OR SKIMUNKNOWN'''</tt> to the filter.

Both the bandmap and the DX cluster announcement windows have the option to display the spot quality tag. 
These windows will show two additional tags; L and C. L stands for local spot, created by yourself or one of your team members. 
C stands for corrected, i.e., a B or ? spot where a corrected call has been included in the spot's comment field.

The AR6 filtering syntax offers a lot of flexibility. Another example:

: <tt>'''SET DX FILTER (SKIMVALID OR NOT SKIMMER OR ((SKIMQSY OR SKIMUNKNOWN) AND (CTY <> K AND CONT <> EU )))'''</tt>

will provide only validated and human spots except if they are from outside the US and EU.

If you get lost in the filter settings you can always reset with : <tt>'''SET DX DEFAULT'''</tt>.

Some more guidance on how to work with filters on AR-Cluster nodes can be found in [http://dxlog.net/sw/files/utilities/AR_Cluster_v6_User_Manual.pdf this document].

==Support for DXSpider==

DXSpider is the most dominant DX cluster software but has historically not been a 
good choice for contesters. The reasons for this include: Long respotting time, lack 
of pass function for own spots, and suppression of spots from a single skimmer.

The good news is however that the author Dirk G1TLH has worked hard to address these 
aspects of the otherwise brilliant software.

From '''version 1.57 release 440''' the respotting time is now 3 minutes and there is a 
<tt>SET/SEEME</tt> command that passes all spots without consolidation of your own callsign.

So if your favorite cluster node is not running this version, ask the owner to upgrade asap.

Yet another reason for its popularity is its extreme resource-efficiency which allows it to run 
virtually any Linux capable hardware, including a $20 Raspberry Pi Zero.

A list of all DX cluster nodes running DX Spider can be found here: [https://www.dxcluster.info/telnet/index.php?software=DX%20Spider DX Spider cluster nodes]

[[image:dxspiderflow.png]]

DXLog recognizes the <tt>Q:#</tt> skimmer quality tag in the comment field and converts them into 
"CT1BOH-like" quality tags that can be displayed in DXLog's bandmap. The legend is:

: '''?''' means a spot with Q:1, i.e. heard by only one skimmer. This is an unreliable spot.
: '''P''' means a spot with Q:2, i.e. heard by only two skimmers. This is a fairly reliable spot.
: '''V''' means a spot with Q:3 or higher, i.e. heard by several skimmers. This spot is considered validated.

Since a DXSpider node currently needs to be specially configured by the owner to publish Q:1 spots, very few do this. 
Also, since DXSpider lacks busted call detection, the the quality of the spot flow will suffer if this is done.

A typical cluster line looks like this:

<tt><nowiki>DX de PY2MKU-# 14065.0 SM7IUN CW 29dB Q:9* Z:14,15,20 1922Z</nowiki></tt>

The Q parameter is the number of skimmers spotting the call. The trailing star means they do not quite agree 
on the frequency. A trailing plus means the station has been spotted for more than one hour. The Z parameter 
lists the CQ zones in which the callsign is spotted.

There is a wealth of information to be found on the [http://wiki.dxcluster.org/index.php/Main_Page DXSpider wiki].

==Support for N2WQ Cluster==

Introduced in late 2025, Rudy N2WQ has developed the first new DX cluster node software in decades.

The N2WQ-2 cluster has some unique features like a more advanced callsign validation than 
AR 6 and propagation estimation tags embedded in the spot comments. An example can be seen below.

[[image:n2wpspotflow.png]]

When you connect to dxc.n2wq.com port 8300 and you have set your 4-digit Maidenhead grid (SET GRID), there 
will be a single character just before the DX’s grid locator. This character is the path prediction glyph.

It is a crowdsourced, real-time estimate of how reliable the path is between you and the DX on that band right now, 
based on recent on-air propagation reports from RBN and PSKreporter. Its values and meaning are:

: > High: Strong path. If you can hear them, you should be able to work them.
: = Medium: Decent path. Workable with normal contest/DX technique.
: < Low: Weak path. Possible, but expect repeats, timing, and patience.
: - Unlikely: Marginal. Try only if it’s rare/needed, or you have a strong station advantage.

A missing glyph means insufficient data to estimate the path.

the glyph is mode-aware. A path that looks great for a very sensitive mode (FT8) can look 
more moderate for a less sensitive one (SSB).

You can filter spots by path reliability using the PASS/REJECT PATH command.

It is important to be aware that the glyph does not know:

: Your antenna gain/pattern, height, or takeoff angle
: Your transmit power and duty cycle constraints
: Your operating technique (timing, split discipline, pileup strategy)
: Short-lived phenomena the network has not yet “seen” such as sporadic E or aurora.

The cluster ingests upwards of 50,000 CW, FT, RTTY, and WSPR spots per minute. To compare different modes 
fairly, the system normalizes reports onto a common “FT8-equivalent” scale (so a CW SNR can be compared 
to an FT8 SNR).

Your grid and the DX grid are mapped into small geographic cells and the cluster calculates propagation 
at two levels:

: Fine (local): what’s happening close to your area (~180 miles).
:: On averages there are about 90,000 DE/DX pairs being tracked
: Coarse (regional): what’s happening in the broader region around
:: you (~480 miles). On average, there are about 30,000 DE/DX pairs.

If there isn’t enough local data, the system leans more on regional behavior. 
If there’s plenty of local data, it uses that more heavily.

Sometimes you can hear them better than they can hear you (or the reverse) due to noise 
floors, antennas, geography, or ionospheric effects. The system tracks both:

: Receive direction: DX to you (can you hear them?)
: Transmit direction: you to DX (can they hear you?)

It combines these into one “path reliability” estimate, weighting receive a bit more 
because if you can’t hear them, you can’t work them.

Propagation changes fast, so older reports get discounted using a half-life (data fades 
in influence over time). Typical behavior by band:

: Low bands (160/80m): slower changes (longer half-life)
: Mid bands (40–20m): medium pace
: High bands (15–6m): fast changes (shorter half-life)

In practice, this means glyphs can shift in minutes on 10m/6m, and more slowly on 80m/160m. 
Also, new openings take time to show up. A "insufficient" can simply mean “the path just opened 
and the cluster hasn’t collected enough recent reports yet.”

Your local noise floor heavily affects what you can receive, so the cluster lets you tell 
it what your noise environment is. This mainly tunes the receive-side expectation (DX to you).

Set it with SET NOISE SUBURBAN. Available profiles per ITU:

: QUIET: very low noise, rural/remote
: RURAL: mild noise
: SUBURBAN: typical neighborhood QRM
: URBAN: elevated noise, dense housing
: INDUSTRIAL: severe noise

If you don’t set it, the system may assume a quieter environment than you actually 
have, and your receive-side glyphs can look too optimistic.

Treat the glyph as a real-time probability hint that helps you spend your operating 
time where the odds are best. When you see > on a needed multiplier, move fast. 
When you see -, be intentional about whether it’s worth the time. 
And when you see a space, fall back to classic DX/contest instincts and your own ears.

The N2WQ cluster also offers spot quality tags between the DX grid and the time.

A quality (in terms of callsign reliability) tag can be V, P, S, C, or ? where V means validated, 
P highly likely, S less likely, C corrected, and ? unsure.

The propagation and quality tags can be displayed in the bandmaps and the DX cluster announcement window.

DXLog recognizes the skimmer quality tags but consolidates them before display for consistency 
with other cluster nodes' quality tags and to minimize confusion when mixing spot flows. 
The legend is:

: '''?''' means a spot with ? or S. This is an unreliable spot.
: '''P''' means a spot with P or C. This is a fairly reliable spot.
: '''V''' means a spot with V. This spot is considered verified.

==Interacting with WSJT-X==

Important: When in a DXpedition/multi-station setting, always use local host 127.0.0.1 as the 
broadcast address to prevent packets being picked up by other stations in the network. 
Also, enabling the creation of local spots from decodes may overwhelm DXLog.

DXLog can add QSO performed with WSJT-X to its log. Note that this functionality only works 
for contests with grid as the first and only exchange or for DXPedition type logs.

DXLog can also create local spots from WSJT-X decodes by checking 
<code>Options|Broadcast|Spot WSJT-X decodes</code>.

To enable logging of WSJT-X QSO, set up WSJT-X to broadcast information:

[[image:Wsjt-x-udp.png]]

[[image:Radiobroadcastenable3.png]]

Activate DXLog's UDP listener by checking <code>Options|Broadcast|Receive broadcasts</code> and set 
the same port number as in WSTJ-X in DXLog's network configuration panel.

[[image:Dxlog-udp.png]]

==Using Winkey FSK==

Winkey FSK is not natively supported by DXLog's digital mode engines MMVARI or MMTTY but 
Rafal EI6LA has developed a plugin for MMTTY that makes this possible.

You can find it [https://github.com/RafalLukawiecki/WinKeyerMMTY here].

==Interfacing with LogHX==

Christian F8GHE has prepared a guide on how to do this.

You can find it [http://dxlog.net/sw/files/utilities/DXLOG-LogHX_UDP-config_v2.pdf here].

==Self-spotting==

More and more contests allow spotting your own station on the DX cluster.

DXLog supports this, even when operating unassisted, as long as you connect to the cluster.

DXLog has three mechanics for self-spotting.

DXLog blocks self spotting unless specifically allowed in the contest rules. 
Should you find that DXLog incorrectly allows or blocks self-spotting, please make 
the development team aware via the support reflector.

* The <tt>$SPOTME</tt> macro command. This macro will create a cluster spot of the station's
: call at the earliest 15 seconds after being invoked the first time on a new frequency.
: Thereafter it will spot as frequent as allowed by the contest. If the contest rules do not
: specify a minimum period, 10 minutes will be used.

* Checking the menu option <code>Tools|Data entry|Run F1 message self-spots when permitted</code>.
: Works exactly like the <tt>$SPOTME</tt> macro command but is triggered by sending the
: Run F1 message which happens when pressing <code>[Enter]</code> with an empty entry line
: in Run, pressing <code>[F1]</code> in Run, or with Auto-CQ.

* Clicking the menu item <code>Commands|Self-spot</code> or pressing its shortcut key <code>[Ctrl][S]</code>.
: This will immediately create a spot of the station's call but no more often than
: every two seconds to avoid accidental multiple spots.

==DXpedition use==

DXLog is a popular choice for top tier dxpeditions. Below we have collected advice based on experience 
on how to best use DXLog in a dxpedition setting.

* Use client/server networking between stations. Never use UDP over Wi-Fi or WAN links.
* Use the "Minimal data" option in ADIF export to save on satellite link cost.
* For Club Log real time upload, use [https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads Club Log's upload app]
* Club Log truncate QSO time to minutes so to avoid creating dupes when mixing manual and real time upload to Club Log, check ''QSO time in minutes'' when doing ADIF export.
* Use the "Minimal data" option in ADIF export to save on satellite link cost.
* Follow [[Additional_Information#Interacting_with_WSJT-X|the instructions]] to log QSO made with WSJT-X and MSHV.
* Check <code>Options|Broadcast|Spot WSJT-X decodes</code> to make decoded calls appear in e.g., DX cluster announcements.
* You can extend the number of digits in the QSO count with <code>Options|Log|QSO number digits</code>

==Beacon spots on DX cluster==

Although propagation measurements based on FT8 communications has reduced the 
value of beacons, there are still hundreds of them in operation.

Identifying with CW, they are typically reported on reported on the DX cluster.

When beacon spots are received by DXLog, they are always displayed in the bandmap. 
In DXLog, beacon spots are recognized by having a trailing <tt>/B</tt>.

The DX cluster announcement window never shows or counts beacon spots.

Beacon spots can be enabled and disabled in the cluster node.

For CC Cluster, the commands are <tt>SET/BEACON</tt> and <tt>UNSET/BEACON</tt>.

For DXSpider, command is part of the <tt>SET/SKIMMER</tt> command where <tt>SET/SKIMMER</tt> 
or e.g., <tt>SET/SKIMMER CW BCN FT RTTY</tt> will pass beacon spots and <tt>UNSET/SKIMMER</tt> 
or any <tt>SET/SKIMMER</tt> listing modes but not BCN will block them.

AR 6 cluster nodes always pass beacon spots when skimmer spots are enabled. They cannot be disabled.

==Using Piper text-to-speech synthesis==

James M0DST has prepared 7 sample scripts that can be mapped to F keys.

James' comments on the scripts are:

This is just an extended proof of concept. Feel free to play using your own scripts. 
There is a lot of code duplication across the scripts. I may simplify some of this in the future. 
I tried base classes, but the current script engine would need some rework to support that. 
Repeat isn't supported. You will need to press the key manually. 
Multiple op voices are not supported currently. You could hack this in with little effort. 
There is no documentation at present. This feature is experimental whilst I decide how I want 
to move it forward (if at all). If you want to adjust the speed, you can do it per script. 
See SpeakingRate in the F2 script. Lower number is faster.

You can visit https://rhasspy.github.io/piper-samples/ to hear the voices. Set the model in the script.

Any comments or thoughts on anything related to this should be sent to me directly or on the list.

I really suggest training your own voice. I haven't done it yet, but I will when I have time. 
Using common amateur radio phrases in the training data will help teach it to sound more like a ham.

If you improve the scripts, please send them to me and I will update the files behind this link. 
Once everything is stable and formalized I will pass the links to Bjorn for the website, and we 
will add some real documentation.

Experimental scripts:
[https://drive.google.com/file/d/1EhfOpxsL57yuf-1WorASnGf-SBsmfqu7/view?usp=drive_link F1]
[https://drive.google.com/file/d/1MgviBec7HCXIOJZtDZXl0qXlrU-TwMoD/view?usp=drive_link F2]
[https://drive.google.com/file/d/1yAgY5E-KdOcmToXMJQ2lRNhjBIQrJIb9/view?usp=drive_link F3]
[https://drive.google.com/file/d/1-ftWUhFlc4-quwGPIVmNujQ4q-J5E3EZ/view?usp=drive_link F4]
[https://drive.google.com/file/d/1h3C_kLl9C4CEH6kATGAZbfDkfY6KlgqB/view?usp=drive_link F5]
[https://drive.google.com/file/d/1e4tAHz-_dU92RybaFeSuLCd0V7Gk_lWy/view?usp=drive_link F6]
[https://drive.google.com/file/d/1UGxgOpqOjOzl7yFTjrVaml9m5o8gBq5y/view?usp=drive_link F7]

Menu Options

2026-04-09T05:27:17Z

Sm7iun: /* Log */

==Load contest at startup==

* '''Enabled'''

: If checked last opened log will be opened automatically when DXLog is started. 

* '''Disabled'''

: If checked, DXLog is started but no log is opened. 

==Automatic backup==

When clicked, this will open the log automatic backup settings window. Here parameters for log automatic backup can be set according to the user's preference. 

[[image:auto_backup.png]]

==Language==

Chooses the user interface language.

==Keyboard selector==

This option allows the assignment of a different keyboard to each entry line which is 
highly recommended for advanced SO2R but also useful for advanced users in SO2V.

'''Important:''' Dual keyboard in SO2V only works for dual receiver radios and 
<code>Options|Interface specific options|Dual receiver radio (Use split in SO2V)</code> checked.

To use this feature you (obviously) must have more than one keyboard connected to the PC.

Select <code>Options|Keyboard selector</code>. A window opens showing the current keyboard assignment.

[[image:Keyboard_select_default.png]]

Now click on Define. A popup will appear asking you to identify the Radio 1 keyboard.

This keyboard will be assigned to the Radio 1 (upper) log entry line. Press any key on keyboard 1. 
Now press any key on the keyboard to be assigned to the Radio 2 (lower) entry line. If successful, 
the panel will show some cryptic identifiers for the keyboards.

If you really do have separate keyboards ensure that the identifiers are different. 
It is possible to use one keyboard and assign it to both positions, which will show as the same 
identifier for both Radio 1 and Radio 2. The panel should look something like this: 

[[image:Keyboard_select_success.png]]

Now click OK to save your assignments and close the window.

If you find that something doesn't work or need to reset to the default Any Keyboard configuration, open 
the Keyboard selector panel and select the Reset button. Click OK and any previous keyboard assignments will be removed.

==CW & Digital==

===Modify standard messages===
Text command: <code>MESSAGES</code> or <code>MSGS</code>

This option is used to edit the contents of all standard F-key, INS and PLUS messages 
for RUN and Search & Pounce mode.

[[image:standard_messages_cw2.png|none|frame]]

Any edited content is saved for the currently selected contest and '''will be used for any new log for the same contest'''.

The Defaults button will reset all messages back to their default values. This can be particularly convenient 
when switching "role" from a previous contest, such as member/non-nember, IOTA station/non-IOTA station, etc.

The Save and Load buttons allows saving and retrieving all messages to and from a text file.

If you want to reset '''all messages for all contests''' to their default values, click <code>File|Open configuration directory</code>. 
Close DXLog. Delete the file called <tt>DefMsgs.sdb</tt> and start DXLog again.

[[image:standard_messages_options2.png|none|frame]]

The Options tab allows the setting of additional message options:

''$QSOB4 macro''
: This text will be sent if $QSOB4 macro is triggered due to a duplicate QSO.
: '''Important: The use of QSOB4 mechanics in contests is a heritage from paper log days and not a recommended practice.'''

''Use only Run messages''
: DXLog will use only RUN messages, even if you switch mode to Search & Pounce.

''Use sprint exchange logic for the Insert key''
: This setting is available only for contests configured to allow sprint exchange logic and supports
: an old style of operating a sprint contest, keeping DXLog in Run mode constantly.:
: With this option checked, and in Run mode, the Insert key will send the '''RUN''' Insert message if the callsign
: field and the exchange field are empty. If they are not, the '''S&P''' Insert message will be sent.
: Note that you may need to modify the standard messages to suit your operating preferences when using this option.
: For a more modern way of operating a sprint contest, see [[]].

===Modify additional messages===

Shortcut key: <code>[Alt][C]</code>

Text command: <code>AMESSAGES</code> or <code>AMSGS</code>

Define or edit additional CW/Digital mode messages which can be invoked in a macro using commands 
<code>$MSG1..12</code> or by pushing keys <code>[Ctrl][Alt][F1..12]</code>

[[image:Othercwdigi3.PNG]

While the window is open, pressing <code>[F1]</code> through <code>[F12]</code> will send message 1 through 12 and then close window.

The Save and Load buttons allows saving and retrieving all messages to and from a text file.

Content of additional messages are saved in the DXLog config file and is thus '''common for all contests'''.

===CW keying===
'''Computer sidetone''' 
Text command: <code>SOUND</code> and <code>NOSOUND</code>

Unchecked by default. When checked, a CW side tone will be produced in the PC's default audio device. 
Only available for COM-port keying. If a smart keyer (e.g., WinKey) is used, the sidetone function is disabled.

'''Individual radio speed''' 
Text command: <code>SYNCCW</CODE> and <code>NOSYNCCW</code>

If checked, allows the CW speed to be independently set on Radio 1 and Radio 2.

The text command <code>SYNCSPEED</CODE> equalizes the speed of both radios (in SO2R) or VFO in (SO2V).

'''Reduced word spacing''' 
Text command: <code>CTSPACE</code> and <code>NOCTSPACE</code>

When checked, word spacing in CW will be 6 dits rather than the normal 7 dits.

'''Set speed''' Allows you to enter the exact CW keying speed of the focused radio in WPM. Shortcut key: <code>[Alt][V]</code>

'''Decrease speed''' Decreases the CW keying speed of the focused radio with 2WPM. Shortcut key: <code>[Alt][F9]</code>

'''Decrease other radio's speed''' Decreases the CW keying speed of the unfocused radio with 2WPM. Shortcut key: <code>[Shift][Alt][F9]</code>

'''Increase speed''' Increases the CW keying speed of the focused radio with 2WPM. Shortcut key: <code>[Alt][F10]</code>

'''Increase other radio's speed''' Increases the CW keying speed of the unfocused radio with 2WPM. Shortcut key: <code>[Shift][Alt][F10]</code>

===CW macro number sending===

Controls how numbers are sent on CW.

Number sending abbreviations applies to message macros <tt>$CQZONE</tt>, <tt>$ITUZONE</tt>, <tt>$EXCHANGE</tt>, <tt>$RST</tt>, <tt>$SERIAL</tt>, 
<tt>$NEXTSERIAL</tt>, <tt>$PREVSERIAL</tt>, <tt>$POWER</tt>, <tt>$PREV_RCVD</tt>, and <tt>$PREV_RECINFO</tt> and QTC macros <tt>$TIME</tt>, <tt>$NR</tt>, and <tt>$QTC</tt>.

The abbreviations are not applied to macros sending a frequency, time, or grid, such as <tt>$FREQR1</tt>, <tt>$TIME</tt>, or <tt>$GRID</tt>.

<tt>$RST</tt> is a special case with the minimum abbreviation being 5NN.

The available options are:

'''Use 'O' as abbreviated zero''' When checked, all number '''0''' are replaced with the letter '''O'''. '''Important:''' This is an outdated practice and only a source of confusion in contests.

'''Unabbreviated [01590]''' When checked, all numbers are sent without any abbreviation. ($RST sends 5NN.) Text command: <code>NOABBREV</code>

'''Lead abbreviated [T1590]''' When checked, all leading zeroes are sent as the letter '''T'''. Text command: <code>SEMIABBREV</code>

'''Abbreviated [T159NT]''' When checked, all numbers '''0''' and '''9''' are replaced with the letters '''T''' and '''N'''. Text command: <code>FULLABBREV</code>

'''Pro abbreviated [TAENT]''' When checked, all numbers '''0, 1, 5''' and '''9''' are replaced with letters '''T, A, E''' and '''N''' Text command: <code>PROABBREV</code>

'''Custom abbreviation''' When checked the Custom Abbreviation table will be used to substitute characters

'''Set custom abbreviations''' Enables editing of substitutions character by character When clicked, a panel will open to allow assignment of character substitutions.

[[image:custom cw digi abbreviation table form.png]]

* <code>Add</code> Adds a new substitution. First enter the character to be replaced. Then enter the character to be used in its place. 
* <code>Delete</code> Removes the currently selected substitution. 
* <code>OK</code> Saves changes and closes the form 
* <code>Cancel</code> Discards changes and closes the form

Characters/digits not included in the substitution table are sent in their original form.

===Send leading zeros in serial numbers===

Text command: <code>LZ</code> and <code>NOLZ</code>

When checked, macros sending numbers will always send three digits. 

Shorter or longer zero padding can be achieved by adding number within parenthesis 
to the serial number macro e.g., $SERIAL(2).

===Send frequencies rounded to kHz===
If checked, the frequency sent by the $FREQS, $FREQP, and $FREQnn macros will be rounded to the nearest kHz. 
If not checked, the frequency is rounded to the nearest 100 Hz. An 'R' is sent as decimal separator.

===Disable worked-before macros===

Text command: <code>WORKDUPE</code> or <code>WORKDUPEON</code> and <code>NOWORKDUPE</code> or <code>WORKDUPEOFF</code> 

When checked, the <code>$QSOB4</code> and <code>$QSOB4WIPE</code> macros will do nothing, regardless 
if the current callsign is a dupe or not.

Checked by default. It is a bad and outdated practice to not work dupes in a contest.

===Remap keys in keyboard mode===

When checked, keyboard remapping will be active also when sending CW/RTTY text in keyboard mode.

===Remap keys in QTC receive===

When checked, keyboard remapping will be active also in the QTC receive window. 
This option is only available if the contest entry involves receiving QTC.

===Auto sending===

Text command: <code>CWAUTO</code> or <code>AUTOCW</code> and <code>NOCWAUTO</code> or <code>NOAUTOCW</code>

[[image:autocw.png|none|frame]]

When enabled and the mode is CW and you are in Run, DXLog will start sending the Insert message after having 
typed a selected number of characters of the callsign, removing the need to press <code>[Insert]</code> to respond to a call.

The rule for start of transmission of the RUN INSERT message is:

Typed characters contain both a letter and a number AND has reached the threshold number OR typed characters include a slash and 
the number of characters following the slash has reached the threshold number

This means that with the threshold set to 2 transmission will start when pressing

: 7 in SM7IUN
: 2 in SM/E21EIC
: the first 7 in E77DX

and with the threshold set to 3, transmission will start when pressing

: 7 in SM7IUN
: 1 in SM/E21EIC
: the second 7 in E77DX

'''Important:''' When using a number server, a serial number reservation will automatically occur at the start of the RUN INSERT message.

Tip: When you open the dialog to configure auto sending, <code>[Space]</code> will enable/disable and 
<code>[Enter]</code> will press the OK button and close the window.

===Smart correction for $CORRECT===

When checked, DXLog will send only the part of the callsign that was corrected. 
Example: if you correct W6ABB to W6ABC, only ABC will be sent by the <code>$CORRECT</code> macro.

===Copy hour in received QTCs===

When checked, the two hour digits from the previous line will be automatically 
copied to a new line in the receive QTC window.

===QTC window font size===

Sets the font size of the QTC window used in contests with QTC such as Worked All Europe Contest.

==Configure interfaces==

Text command: <code>SETUP</code>

[[File:Portconfig.png|none|frame]]

DXLog currently supports interfaces for up to 8 COM ports and one LPT port. 
To use any of the ports to connect to the hardware and perform a function, 
you must enable the port by checking "Enabled" box.

===Serial ports===

DXLog can communicate with up to eight devices; peripherals or radios. 

For each device, you can select to use a COM port or a "pipe". 
COM ports can be in the range of COM1 to COM40.

There are two types of "pipe" connections; OTRSP and WINKEY. 
These are direct connections and do not rely on a COM port for communication. 
You can only have one of each of these.

You can not select the same COM port for more than one interface. 

Apart from communications interface (COM or pipe) the device type needs to be selected (Winkey, Radio, etc.). 
Additional settings for the device are available by clicking on the setup button on the far right.

'''The "-" port type'''

The "-" device type is a COM port where only the hardware handshake signals are used, 
such as keying or PTT.

It uses a fixed speed of 9600bps, which may cause problems in some cases, such as when 
using a port combiner.

'''Important:''' If you are using a COM-port footswitch together with an external DVK, such as that 
built into microHAM devices, you may need to select the Escape option to reliably stop DVK 
playback when pressing the footswitch.

To make sure a port used for only keying or control is opened at the right speed do the following:

Open the interface configuration panel.

* Select the wanted port and check the enable box.
* Select it as Radio 1 and click Setup.
* Select a random radio model and set the correct speed.
* Set the wanted keying (e.g. CW = DTR, PTT = RTS, Footswitch, Active with Radio 1, etc.)
* Click ''OK''
* Change from "Radio 1" to "-". Do not click Setup.
* Click ''OK''

'''The Winkey port type'''

The default setting is 1200-8-N1 with RTS always on to support the original, serial port Winkey. 
If you have a more modern keyer, you may chose a higher speed. 
'''Important:''' A Winkey always keys both radios and disables COM-port and LPT-port keying.

'''The microHAM port type'''

This device type will support any microHAM keyer with a COM port control interface. 
Serial speed and handshaking signals are ignored when connecting to a microHAM USB 
device router virtual COM port. For more information, refer to the [[Radios_and_Peripherals#microHAM|Microham section]].

'''The OTRSP port type'''

Software PTT (commands X1/X0) is available only with "pipe" connection, otherwise disabled.

Options include to not assert PTT when using DVK and to verify transmitter change before transmissions starts.

The reason for the option to verify transmitter change before transmission starts is to avoid a possible race 
condition that can occur when using a Winkey keyer and an OTRSP device. There is a risk that the keyer receives 
its command first and starts keying risking that the OTRSP device changes transmitter while transmitting. 
Checking the option will make DXLog send an OTRSP query to make sure the transmitter change has occured before keying starts. 
Since such a response is optional in the OTRSP specification, this function must also be optional.

'''The Radio port type'''

See below.

===Digital Voice Keyer===

The Digital Voice Keyer (DVK) section allows PC audio cards or adapters to be used to record and 
play back SSB DVK messages.

For selected radios, it is also possible to use the voice keyer built into the radio. 
The radio's built-in voice keyer is enabled in the [[Menu_Options#Radio_configuration|radio settings]]. 
With a few exceptions, recording is not supported. See the [[Radios|supported radios]] section for more information. 

If you have a microHAM keyer controller, its built-in voice keyer may also be used. 
The microHAM voice keyer is enabled in the [[Menu_Options#microHAM_device_configuration|microHAM settings]]. 

'''Important:''' DXLog's own DVK has priority and must therefore be disabled to allow use of other DVK. 
It is thus important to not enable more than one of these three voice keyer options.

'''Important:''' If you are using DXLog's own DVK with split (transmitting on another frequency) you may 
need to disable radio polling during transmit for stable operation.

To use DXLog's voice keyer:
* Check the enable DVK box in the interface configuration panel.
* Select the relevant DVK playback devices (audio from these must be physically connected the the radio's audio input).
* Select the relevant DVK record device (Usually a microphone connected to the PC's microphone or line input).
* Select muting as required.

In SO2R the audio playback will be channeled to the currently focused radio's playback device. 
If you are using a SO2R controller with internal audio switching, select the controller's audio device 
for both radios. In SO1R and SO2V, audio is always routed to radio 1's device.

The built-in DVK in DXLog will support up to nine different messages: 1, 2, 3, 4, 5, 6, 7, INS, and PLUS. 
'''Important:''' Your external voice keyer may support fewer. 

Recording the messages is done by pressing <code>[Shift]</code> and the wanted function key and ended with <code>[Esc]</code>. 
With no operator [[Menu_Commands#Operator_login|logged in]], the recordings are stored in WAV format in the directory <tt>%appdata%\DXLog.net\Ops</tt>. 
The filenames are <tt>F1.WAV</tt> through <tt>F7.WAV</tt>, <tt>INS.WAV</tt> and <tt>PLUS.WAV</tt>. 
If an operator is logged in, the recordings are located in a subdirectory with the operator's callsign, such as <tt>%appdata%\DXLog.net\Ops\SM7IUN</tt>

Although not recommended, the voice keyer can be used with ESM if DXLog's message convention is used. 
It is described in the [[Getting_started#Voice_memory_playback|getting started]] section.

'''SO1R, SO2R, and SO2V'''

Messages #1 through #7 are played back by pressing function keys <code>[F1]</code> through <code>[F7]</code>. 
Unlike in CW and digital, the same voice message is played back regardless of operating mode, Run or S&P. 
Any macros in messages #1 through #7 are thus ignored in SSB.

The INS and PLUS voice messages are not associated with any keys and can only be played back by a macro. 
<tt>$PBINS</tt> plays back message INS (#8 on external devices) and <tt>$PBPLUS</tt> plays back message PLUS (#9 on external devices).

The keys <code>[Insert]</code> and <code>[+]</code>/<code>[Keypad +]</code> ''work differently'' and do not directly play back a 
voice message when pressed but instead execute the macros in the associated standard message, based on key and operating mode.

This means that in the example below, pressing <code>[Insert]</code> in SSB S&P will play back voice message #2 and then log the QSO.

In SSB mode, all macros sending CW or Digital characters are ignored. In CW, the <tt>$PBINS</tt> and <tt>$PBPLUS</tt> macros are ignored. 
This means that you can create standard messages for the <code>[Insert]</code> and <code>[+]</code>/<code>[Keypad +]</code> keys that works both 
in CW and SSB without the use of conditionals.

An example of this type of multi-mode messages for Worked All Germany in the Mixed class is shown below.

[[image:Dvkmixedcontest.png|none|frame]]

'''Advanced SO2R'''

In Advanced SO2R, the function keys <code>[F1]</code> through <code>[F7]</code> are not directly associated with a 
voice memory but instead executes the active scenario's ''macro string'' associated with the key. 
More information on creating and using SO2R scenarios can be found in the [[Menu_Operating#Edit_SO2R_Scenarios|SO2R Scenarios]] section.

The message/playback macros <tt>$F1</tt> through <tt>$F7</tt> are mode sensitive. The <tt>$PGBINS</tt> and <tt>$PBPLUS</tt> are not. 
In SSB e.g. <tt>$F1</tt> plays back voice memory #1, in CW and Digital it sends the F1 ''standard message'' so 
there is no problem using Advanced SO2R also in a mixed mode contest.

===Radio polling===

The two ''Polling period'' text boxes determine how often DXLog requests information 
from the radio over the CAT interface.

DXLog sends three poll requests per period, i.e. with a setting of 300ms, one poll request is sent every 100ms.

For ICOM, which has a duplex CAT interface, you may experience slow or even missing response 
from the radio if the polling period is set too short since DXLog's polling will consume the entire 
capacity of the CI-V interface. With ICOM you also have a no-polling option called "Transceive" mode. 
You can find more about this feature [[Radios_and_Peripherals#ICOM|HERE]].

A list of recommended polling periods can be found below. Depending on radio model, a shorter interval 
may work and give a better user experience.

{| class="wikitable"
! CAT data rate [bps] !! Poll interval [ms]
|-
| 1200 || 1000
|-
| 2400 || 1000
|-
| 4800 || 800
|-
| 9600 || 600
|-
| 19200 || 400
|-
| 38400 || 200
|-
| 115200 || 100
|}

===PTT===

* PTT lead delay determines the time between PTT activation and start of transmission.
:This value is used both for COM-port keying and Winkey. However, microHAM keyers ignores
:this setting and requires you to set the PTT lead time in the microHAM device router.
* PTT tail delay determines the time between end of transmission and PTT deactivation
* PTT seq delay determines the time between activation of the four available PTT signals: PTT, PTT1, PTT2, and PTT3.

===Keying===

The keying settings are for all keying methods; COM-port, Printer port, or Winkey.

* Max speed sets the maximum speed in WPM.
* Min speed sets the minimum speed in WPM.
* Weight sets the weight of the keying. 50% is standard 3:1 keying. A higher number represents a heavier keying.
* Keying compensation adds to the durations of dits and dahs. Accepts both negative and positive values. Negative values have no effect on Winkey keying.
* Reduced keying stutter selects a keyer with improved immunity to disturbance from other applications running on the PC.

===Printer port configuration===

'''Important:''' Use of the printer port requires installation of a special driver, see the [[Installation#Prerequisites|Installation section]].

To use the parallel printer port (i.e. LPT port), it must be enabled by checking the "Enabled" 
box in the interface configuration panel's Printer port section.

Clicking the Setup opens its configuration panel.

Antenna selection with up to 16 different antennas is supported.

For multi-band antennas, the covered bands should be entered as a comma-separated list as in 
the example below. The operator friendly antenna name in the ''Description'' column is used in the 
''Antenna selector'' window.

'''Important:''' DXLog's band naming convention is to use wavelength up to the 10m band and 
above that, frequency. Band names are thus 160, 80, ..., 12, 10, 50, 144, ...

For more information on antenna selection, see the [[Menu_Windows#Antenna_selector_R1.2FR2|Antenna selector]] section.

The DVK related checkboxes are not implemented.

[[File:Dxl_printer_port_config.png]]

===Radio Setup===

If a COM port is configured as a radio interface, click on 'Setup' to open the Radio Setup form. 
In addition to the generic settings, several radio specific options are available. 

'''Important:''' Radio brand and model specific information can be found in the 
[[Radios_and_Peripherals|Radios and Peripherals]] section.

[[image:Radio_setup_form3.png]]

Radio configuration

* Radio
: Select your radio model. If it is not in the list, feel free to contact the development team.
: Note that many times a similar radio model can be successfully used.
: E.g. many Chinese QRP radios use the Kenwood protocol.

* Speed
: For best performance, use the highest available speed on your radio's CAT interface.
: If there is an "Auto" speed setting, do not use it. It is strongly advised to use a virtual USB CAT port, if available.
: Note that on modern ICOM radios it is necessary to "Unlink" the two CAT interfaces to achieve maximum speed.

* Bits, Parity, Stop
: Set according to the recommendations in your radio's documentation.

* ICOM CI-V address (hex)
: This is by default set to the selected ICOM radio model's factory setting.
: If you change the address in your radio's settings, this has to be set to the same value.

* Use radio's internal voice keyer
: Enables the use of the built-in digital voice keyer on supported radio models (E.g. Elecraft, later ICOM, some Yaesu).
: '''Important:''' If the Enable DVK option is checked in the Port Configuration panel,
: this setting has priority and the radio's DVK will not be used.
: '''Important:''' Due to limitations in the CAT command repertoire for some radios, DXLog may
: not be able to track the radio's transmit/receive state. You can use the
: <code>Options|Log|Show border on TX</code> menu option to determine if this is the case.
: If DXLog can not determine the radio's transmit state, this means 1) software interlock in a
: multi-radio setting will not work reliably with the radio's DVK, and 2) CQ autorepeat will not work.
: '''Important:''' Make sure the option Do not use PTT with voice keyer is checked for
: any device controlling the radio's PTT. If it is not, DXLog will assert the PTT at the start
: of DVK playback and then wait for it to be released, which obviously will never happen.

* Use reverse sideband on CW
: Uses the opposite sideband on CW. Mode is only enforced by DXLog at mode or band changes.

* Use CAT PTT command on Phone and Digital
: Uses a CAT command to switch between receive and transmit when using DXLog's internal voice
: keyer or digital modulator, instead of a COM-port or LPT signal. Only use this as a last
: resort when COM-port PTT is not available.
: Since the time to convey the command to the radio is not insignificant, you may need to increase
: the PTT lead time significantly to avoid hot-switching or lost first syllables.

* Use CAT PTT command on CW
: Uses a CAT command to switch between receive and transmit on CW, instead of a COM-port or LPT signal.
: Only use this option as a last resort when COM-port PTT is not available.
: Since the time to convey the command to the radio is not insignificant, you may need to increase
: the PTT lead time significantly to avoid hot-switching or lost leading dits.

* Use ICOM CI-V "Transceive" mode (reduced polling)
: An ICOM specific feature for which "CI-V Transceive" must be enabled on radio.
: For older ICOM radios with 19200bps or slower CI-V interfaces this option offers a much improved user experience.
: For modern ICOM radios the recommendation is to have this feature ''disabled'', an interface rate of 115200bps,
: "CI-V Transceive" enabled in the radio's set up menu, and polling rate of 100ms. USB Echo Back should be off.

* Control FlexRadio DAX on Phone
: Intended for remote operation with e.g. Maestro. Will temporarily enable DAX during voice keyer playback.

* Reinitialize port after switching from TX to RX
: Upon return to receive, reinitialize the COM port attached to that radio.
: '''Important:''' This is an emergency function and should only be used as a last
: resort when e.g., experiencing bad RF feedback at a DXpedition or a field day
: without access to ferrites.

* Do not poll radio during TX
: Stop polling radio (stop updating frequency, etc.) during transmit.
: May reduce RFI from the CAT interface.
: For e.g. Elecraft this is a recommended option.
: '''Important:''' For natural reasons, polling will only stop during transmit if DXLog is the origin of the PTT signal. The only exceptions are when using a [[microHAM_device_configuration|microHAM]] keyer with TX lock/unlock enabled or a Winkeyer with Detect paddle for interlock enabled.

The two above options may be useful in cases with RF feedback causing unwanted effects. 
They should however be considered as temporary solutions. RF feedback should be addressed at 
the source through proper grounding and ferrite chokes on cables.

* Use radio DATA mode for voice keyer playback
: Switches the radio to data mode during voice keyer playback.
: Intended for for radios that can only use an external modulation input in data modes.
: '''Important:''' Not supported on all radios.

* Always use radio DATA mode for any DIGI mode
: If your radio has a DATA mode for RTTY/PSK/AFSK, checking this option will force the DATA
: mode whenever a DIGI mode is selected.
: '''Important:''' Not supported on all radios.

* Use transverter offsets
: Opens up a configuration panel allowing setting per-band transverter offsets in kHz.

:[[image:Transverteroffsets.png|none|frame]]

* Spectrum

: Allows you to select a supported transceiver model or an external SDR for spectrum display.
: Currently Elecraft K4, SDRPlay, AirSpy and ExtIO type SDR receivers are supported.
: Clicking the ''Setup'' button will allow configuring it for RF or IF reception, etc.

Keying & Control

On many radios the CAT interface's unused hardware handshake signals can be used for keying and control.

In the drop-down menus you can chose to use between them being permanently on or off, CW keying or one 
of four possible PTT signals. The other options (Active radio etc.) are intended for controlling 
external radio controllers or keyers.

'''Important:''' Most Yaesu models have RTS hardware handshaking enabled from factory. Either set RTS 
to "Always on" or disable this function in the radio's settings (better).

'''Important:''' All CW keying via COM-port is disabled if a Winkey is active. PTT is however still active and 
should be disabled with Winkey 2.3 (or later) that has a high performance PTT built in.

The ''DSR/Footswitch'' input (pin 6 in an RS-232C connector) is an input with multiple, alternative uses. 
''PTT'' means that the pin will assert DXLog's PTT. ''R1/R2 toggle'' means that a press on the footswitch will 
switch focus to the other radio. ''R1 on/R2 off'' means that pressing the footswitch will focus radio 1. 
''R1 off/R2 on'' means that pressing the footswitch will focus radio 2. ''TX Rec'' means record to the preselected 
voice keyer memory. ''Escape'' makes pressing the footswitch equivalent to pressing the Escape key. 
The function of ''RX Wait'' is unclear.

* Do not use PTT with voice keyer

: '''Important:''' If you use the radio's built in voice keyer, make sure to check this box
: on the COM port controlling your radio's PTT to avoid a self-locking PTT loop and to make
: sure the transmitter's audio source is not forced to be the microphone.

: If PTT is not asserted when playing back, you may need to uncheck it but this is extremely rare.

==Configure antenna server==

This configuration is for a special antenna hardware used at a few, select contest stations.

[[image:antserv.png|none|frame]]

==Interface specific options==
===Allow different TX/RX antenna===

If checked this option allows different selection for TX and RX antenna with Operating->Antenna selection menu. 

===Use decoder frequency correction===

If checked and audio decoder is used in a digital mode contest, audio frequency in decoder will be 
added or subtracted to the frequency reported by the radio to get effective operating frequency. 
When using a digital mode for which the radio displays the effective operating frequency, such 
as FSK RTTY or FT8, this option should be disabled.

For digital modes when this is not the case, e.g., AFSK RTTY, this option should be enabled.

===Block message transmission if another radio is on the same band===

If checked the Transmitter connected to this DXLog will have it's TX disabled if another radio on the network is on the same band.

===Dual receiver radio (Use split in SO2V)===

If checked (and the technique selected is SO2V) DXLog will send set the radio in split mode when focusing VFO B.

Select this if you are using a radio with a subreceiver, such as Yaesu FTDX101D, ICOM IC-7610, or IC-7851.

===Use different bandmap background for active radio ===

If checked, the background color of radio 1 or radio 2 bandmap will be changed when the radio becomes active. 
'''Important:''' the color used in this mode needs to be selected by using the Colors menu in the bandmap right click menu. 
By default it is set to the same color as the normal background.

=== Automatically open/close digital window on mode change ===

If checked, the digital window for the active radio will be opened when a digital mode is selected. 
If a non-digital mode is selected and the digital window is open, it will be closed. Note that the 
contest configuration must allow both digital and non-digital modes in the same time period (mixed mode). 
The digital window must be configured properly in the RTTY configuration form.

=== Sync radio 1/2 frequency & mode ===

If checked, synchronizes the frequency and mode of physical radio 1 and 2. Does not synchronize VFO in SO2V. 
This option requires radio auto reporting (e.g., ICOM "Transceive") to be disabled or oscillation will occur.

===Band change keys affect both VFO===

With this option checked, <code>[Alt][F1]</code> and <code>[Alt][F2]</code> will change the band of both VFO.

===Select first available antenna on band change ===

If checked, selects the first available antenna on band change.

===Partner and S&P selection===

Controls the function of the [[Menu_Windows#Partner|Partner window]] and [[Menu_Windows#Search_and_Pounce|S&P window]].

==RTTY configuration==

Settings for RTTY decoder types and paths to decoders.

[[File:FrmRTTYConfig.png| 600px]]

Up to three decoders can be used per radio. Note that the decoder for each radio '''must be in a separate user-writable directory''' on your PC.

* '''MMVARI Multimode''' - For MMVARI select MMVARI from the radio buttons 

* '''MMTTY RTTY engine''' - For MMTTY go to http://hamsoft.ca/pages/mmtty.php - download MMTTY engine and extract into a user-writable directory 

* '''2Tone RTTY engine''' - For 2TONE go to http://www.rttycontesting.com/downloads/2tone/ - download the latest 2tone version and extract into a user-writable directory 

* '''GRITTY RTTY decoder''' - For GRITTY go to http://dxatlas.com/Gritty/Files/Gritty.zip and extract into a user-writable directory. GRITTY is run separately from DXLog. Edit its .ini file to set TCP port, RTTY tones, etc. 

* '''EXTFSK, EXTFSK64, TinyFSK''' - For these FSK plugins, go to https://www.qsl.net/j/ja7ude/extfsk/indexe.html and https://www.qsl.net/ja7ude/tinyfsk/index.html. To use any of them with MMTTY, place the .fsk file in the MMTTY directory/ies. To use them with MMVARI, place them in a user-writable directory.

Set the radio buttons for the correct RTTY decoder engine. 
Set the paths to the relevant RTTY decoder engines and MMVARI FSK plugins. 
Set tick box options as appropriate for your operation.

==microHAM device configuration==

Settings for integration with microHAM keyers and SO2R controllers 

You can find more general tips about using microHAM products with DXLog 
in the [[Radios_and_Peripherals#microHAM|Radios and Peripherals section]].

[[image:Mk2r-new9.png|none|frame]]

* '''Enable microHAM device DVK
: Enables the use of the microHAM devices's DVK instead of DXLog's built in DVK.
: Supported for microHAM DKII, MKII, MKIII, MK2R, MK2R+, and u2R.
: '''Important:''' DXLog's own DVK has priority and must thus not be enabled.

* '''Footswitch is PTT
: Enables the use of the microHAM devices's footswitch input for PTT.
: On devices with more than one footswitch/PTT input, DXLog regards them as one.
: No longer optional as of DXLog version 2.4.17 due to removal of this option in microHAM's firmware.

* '''Enable TX lock/unlock
: Enables control of the hardware transmit locking/unlocking built into the device.
: Checking this will enable the software interlock in DXLog to act on all possible means
: of transmission: Message transmission, PTT, Footswitch, and paddle.
: This function is intended for ''multi-station interlock'' but can have other uses since with
: this option checked, keyer PTT, Winkey BKIN, and footswitch status are recognized
: by DXLog and is available e.g. for scripting or transmit/receive antenna selection.
: When using a footswitch with this function it should be connected to the microHAM device.
: Using a COM-port footswitch may cause race conditions since DXLog will be exposed
: to two separate PTT signals with a unpredictable separation in time.
: '''Important''': Winkey BKIN is only recognized with microHAM Device Router 9.3.0 or later.

* '''Enable SW PTT
: Enables the use of software PTT. With this enabled, DXLog will control the devices's
: software PTT via the control interface. Can replace COM-port PTT but comes with
: latency so e.g. PTT lead time may need to be increased.
: Should only be used as last resort when hardware PTT is not possible.

* '''Dual radio device
: Selects single or dual radio microHAM device.
: Should be checked for dual radio devices such as microHAM MK2R, MK2R+, and u2R.
: Should be unchecked for single radio devices, i.e. microHAM DIGI KEYER and micro KEYER, regardless of model.

* '''Operator logon selects DVK bank
: With this option checked, logging on (using <code>[Ctrl][O]</code> or <tt>OPON</tt>) will select the DVK message
: bank for this callsign. If there is no such memory bank defined, it is created.
: With this option unchecked, all operators will use the same memory bank.
: Be aware that with this option checked and no operator logged on, the common memory bank will be used.

* '''Device without CAT interface
: With this option checked, DXLog will force the operating mode of the device.
: This is required for devices such as u2R which lacks a CAT interface and thus can not determine this by itself.
: It can also be used for more advanced devices, such as MK2R+, if its CAT interface is not used.
: Works for both single and dual radio devices.
: '''Important:''' In digital modes DXLog only sends a mode command to the device at startup. This is because radios
: need to be configured differently depending on model and digital mode; PKT, USB-D, DIG, etc.
: To force mode settings onto the microHAM device, type the relevant mode in the entry line and press <code>[Enter]</code>.

* '''RTTY is FSK
: This option is only active for microHAM devices without CAT.
: When checked, it will force the device into FSK mode in RTTY.

* '''Digital is VOICE
: This option should be checked if the device is a microHAM u2R which only supports CW, VOICE, and FSK.
: With this option checked, the default mode for digital operation is VOICE.

* '''Radio 1 RX, Radio 1 TX, Radio 2 RX, and Radio 2 TX tabs'''
: Each tab defines a rule for the two 4-bit BCD outputs on the ACC connector on the back side of the MK2R, MK2R+, or u2R.
: The two ACC outputs are typically used for antenna or PA band selection but can have other uses too.
: The location of the checked box is translated into a 4 bit binary pattern.
: '''Important:''' Band names are 160-10, 50, 70, 144, 432 etc.
: '''Important:''' This means only one box can be checked per row.
: Please refer to the latest microHAM documentation for possible changes to this rule.
: '''Important:''' The coding is not BCD. Check mark location number 1 means 0000, 2 = 0001, ... 13 = 1100, 14 = 1101, 15 = 1110, and 16 means 1111.
: The bit pattern in the Radio 1 RX and Radio 1 TX tabs control the RADIO 1 ACC port and the Radio 2 tabs control the RADIO 2 ACC port.
: The configuration allows up to 25 different band/antenna associations.
: Having multiple antennas on the same band is supported.
: For multi-band antennas you need to include a band line for each band it covers.
: The 60m band has was added in release 2.4.15 so if not visible, clicking RESET will make it appear.
: For information on antenna selection, see the [[Menu_Windows#Antenna_selector_R1.2FR2|Antenna selector]] section.

: '''Important:''' To enable the use of different RX and TX antennas, <code>Options|Interface specific options|Allow different TX/RX antenna</code>
: must be checked. The keyer's respective ACC outputs must also be configured for microHAM protocol control.
: This is done in the ACC tab in the microHAM's Device Router set up as shown below.

:[[image:Microhamrouteracc.png|none|frame]]

==OTRSP device configuration==

* '''Enable OTRSP device DVK
: Enables the use of a digital voice keyer in the OTRSP device.
: Supports recording and playback of up to nine messages, just like DXLog's built-in voice keyer.

* '''Radio 1 and Radio 2 tabs'''
: Each tab defines a selection of states for up to four four-bit Aux outputs. Unlike microHAM, any bit pattern is allowed.
: Each state (i.e. line) associates a band with an antenna usable on that band.
: The configuration allows up to 25 different band/antenna associations.
: Each group of four pins is associated with an Aux output, as listed in the upper left of the panel.
: It is possible to have several antennas for the same band.
: A multi-band antenna needs to have one band-line for each band it covers.
: The bit pattern presented to the Aux outputs is the combination (logical OR) of the currently selected antenna for each radio.
: This means that if Aux 1 is used to control the antenna for radio 1 and Aux 2 is used to control the antenna for
: radio 2, columns 5 through 8 must be unchecked for radio 1 and columns 1 through 4 must be unchecked for radio 2.
: C.f. the example configurations below.
: The 60m band has was added in release 2.4.17 so if not visible, clicking RESET will make it appear.
: '''Important:''' Band names are 160-10, 50, 70, 144, 432 etc.
: '''Important:''' The use of different antennas for transmission and reception is not supported.
: For more information on antenna selection, see the [[Menu_Windows#Antenna_selector_R1.2FR2|Antenna selector]] section.

[[image:OTRSP Setup radio 1.png|none|frame]]

[[image:OTRSP Setup radio 2.png|none|frame]]

==Winkey configuration==

Configure the WinKey properties 
Text command : <code>WKSETUP</code> or <code>WKEY</code>

[[image:winkeyconfig2.png|none|frame]]

'''Important:''' If you are using a microHAM keyer, the below settings will only have effect if 
the Allow logger control option is checked on the USB device router's <tt>CW/Winkey</tt> tab.

'''Important:''' For Winkey 2.3 or later, PTT is managed correctly by the Winkey chip and DXLog PTT should not be used. 
For earlier Winkey, COM port PTT may be required to keep PTT from dropping between transmitted words.

* Keyer mode:
** Iambic A - Curtis A iambic timing
** Iambic B - Curtis B iambic timing
** Ultimatic - Non iambic mode
** Dit
** Dah
** Bug (semi-automatic) - WinKey makes the dits and you make the dahs. Vibroplex style.
: In either Iambic mode, alternating dits and dahs are sent while both paddles are held closed.
: In Iambic mode B, which emulates the legendary Accukeyer, an extra alternate dit or dah is sent after both paddles are released.
: In Ultimatic mode, when both paddles are pressed, the keyer will send a continuous stream of whichever paddle was last pressed.

* Reverse - Reverses the dit/dah paddles (e.g. for keying with the left hand)
* Autospace - If you pause for more than one dit time between a dit or dah, Winkey will interpret this as a letter-space and will not send the next dit or dah until a full letter-space time (3 dits) has passed

* Hang time - Sets PTT hang time for paddle transmission

* Pot controls
** Nothing: Winkey speed knob/potentiometer has no action
** Paddle only: Winkey speed knob affects only paddle CW speed (Recommended)
** Paddle and DXLog : Winkey speed knob changes both DXLog and paddle CW speed

* Two wire: Makes the Winkey assume it is controlled by a 2-wire potentiometer. Rarely used.

* PTT - Enable PTT control from Winkey. Preferably disabled on WKmini. Be aware that this setting is ignored for some integrated Winkey chips, such as in microHAM devices.
* Use two Outputs - WinKey pin 5 keys a second radio. Enable with WKmini to key tip of connector.

* Sidetone - Disables or sets the sidetone frequency on keyers with speaker .

* Extra buffering - Transmits N+1 characters at the time to WinKey. May improve performance with WinKey clones that do not respond timely or with remote operation when using Winkey keying over an internet link. Any number above zero will reduce ability to edit sent text while transmitting.

* Detect paddle for interlock - Makes DXLog detect paddle transmission just as e.g, a footswitch to block other stations if interlock is used
* SO2R Mini extension - Activates protocol extensions for controlling an [https://nn1c.org/so2r/ SO2R Mini].

==MP3 configuration==

Sets the configuration for the MP3 encoder used by the [[Menu_Windows#Contest_Recorder|Contest Recorder]] window.

Player is the output device, normally your PC speaker.

Recorder is the recording device, e.g. the audio device in your SO2R controller or the built-in soundcard in your radio.

Recordings are made in stereo, so both radio 1 and radio 2 (or the main and sub receiver) can be recorded.

The sample rate and coding rate can be set at different values. For normal purposes 8000Hz sample rate and 
24kbps coding rate is sufficient and consumes the least disk space.

[[image:mp3config2.png|none|frame]]

==Rotator configuration==

DXLog supports rotator control using UDP communications to PstRotatorAz by YO3DMU and the EA4TX rotator controller.

'''Important: Do not confuse PstRotatorAz with PstRotator.'''

DXLog also offers a generic UDP broadcast based rotor communication, described [[Additional_Information#Antenna_direction|here]]. This does not 
require any configuration besides enabling it in <code>Options|Broadcast|Antenna direction</code> and selecting the 
desired port in the network configuration panel.

The configuration steps for PstRotatorAz and EA4TX are to be fond below.

You may also find [[http://dxlog.net/sw/files/utilities/DXLog%20rotator%20configuration_v2.pdf this guide by F8GHE]] useful.

[[image:PSTRotator DXLog config3.png]]

Check the "Enable Rotator communication" box at the top of the form.

Enter the required data in each column. Use the Add, Edit, and Delete buttons as required. The columns are:

* Band
: Bandname(s) for which this rotator is active. In meters down to 10, thereafter in Megahertz.
: Comma-separated list if several.
: Example: 15,12,10,50,144

* Ant #
: '''Very important:''' Set to 0 (meaning any antenna) if not using the special Antenna server functionality.
: The number of the antenna for this band turned by this rotator, beginning at 1.
: Antennas are numbered in the order shown on the <t>Radio/Ant Status Window.

* IP Address
: If you are running PstRotatorAz or EA4TX on the same machine as DXLog,
: enter 127.0.0.1. Otherwise enter the IP address of the rotator control server.

* Port
: The UDP port used to communicate with the rotator interface. Normally PstRotatorAz uses
: 12040 for the first rotator, 12042 for the second, etc. However, any port that is free can be used.
: '''Important:''' PstRotatorAz uses two ports, N and N+1, so when configuring multiple rotators, do not use subsequent port numbers.
: Write down the ports used as they are needed for PstRotatorAz or EA4TX configuration.

* Radio
: Determines which radio controls the rototator. Set to zero ("0") for any radio.

* Send freq
: Check this box if you need the radio frequency to be sent to PstRotatorAz.

Select the rotator software type from the drop down list, currently either PstRotatorAz or EA4TX

When completed, press OK.

To configure PstRotatorAz, you may need to refer to the PstRotatorAz manual. Here are the basic steps:

From the PstRotatorAz menu bar, Select <code>Setup|Trackers Setup|DXLog.net/Swisslog</code>.

[[image:Pstrotatoraz-setup.jpg]]

The Setup displayed will be:

[[image:Rotator_tracker_setup_DXLog.png]]

Enter the port number used for this rotator in the Ethernet box. Select 'Azimuth' or 'Callsign' in 
the "Tracking by" box based on preference. Click Save Settings.

Select <code>Tracker|DXLog.net</code> from the PstRotatorAz menu bar.

In the main display, select 'Tracking' from the Mode box. Depending on the view you have selected, you may need to select 
View -> Full View to see the Mode box. The following shows the location of the Mode box in PstRotatorAz:

[[image:PSTRotator_tracking_mode.png]]

If you have more than one rotator, repeat the steps on each instance of PstRotatorAz, using the appropriate UDP Port number. 
See the PstRotatorAz documentation to enable multiple instances of PstRotatorAz.

Once you have everything configured, return to DXLog. Ensure you are on the appropriate band (and the proper antenna selected). 
Enter a callsign or an azimuth value into the callsign field. Press <code>[Ctrl][F12]</code>. DXLog will show the value sent on 
the status line, and the rotator should rotate to the selected azimuth.

Enter a callsign and press <code>[Alt][F12]</code>. Rotator will turn to the long path azimuth.

This completes Rotator configuration. '''Important:''' You may have to restart both DXLog and PSTRotatorAz for correct operation.

==Configure network==
This panel allows configuration of network addresses and identity.

Text command: <code>NETCONFIG</code>

[[image: Network_parameters_form4.png|none|frame]]

* ''Station ID''
: The name/identity of the station used in DXLog networking.
: The name is used for e.g. software interlock, gab messaging, and multiplier passing.
: It is recommended to use explanatory station names such as "INBAND", "RUN1", etc.
: Station names including dash ("-") do not work with macros since dash in a macro is a separator and CW speed reduction.

* ''UDP networking for multiple stations'' (checkbox) Enables UDB based networking. DXLog can use both broadcast-based UDP networking and client-server based networking. Note that UDP is a protocol without confirmation or retransmission and thus vulnerable to packet loss. '''Important:''' Wi-Fi networking is not recommended for any contest station but if used, client-server networking should be used.
** ''UDP network parameters'' IP address and port information for UDP networking. The ''Default'' button will enter the DXLog default parameters. '''Important:''' On computers with multiple active network adapters, the broadcast IP address may have to be entered manually for correct operation.

* ''Act as network server'' (checkbox) Enables client-server based networking with this station as server. '''Important:''' Only one server is allowed on the network.
** ''Server parameters'' The IP address of the PC and the selected port.

* ''No spots via client/server'' (checkbox) Spots will only be forwarded inside the peer-to-peer network and not via client-server connections. Valuable feature when e.g., networking over WAN.

* ''Connect to network server'' (checkbox) Enables client-server based networking with this station as a client.
** ''Client parameters'' IP address and port of the server. This entry box supports both numeric addresses as well as URL via DNS lookup.

* ''Other parameters''
:* ''Network timeout (sec)'': timeout value for network connections.

:* ''Time synchronization server'' (checkbox)
:: Makes the current station the master for station time synchronization.
:: '''Only one station per network should have this option checked''' and all other
:: stations '''must run DXLog as administrator''' to allow adjustment of the computer's time.
:: To run DXLog as administrator, right-click the desktop icon and select the option.

:* ''Serial number server'' (checkbox)
:: Enables the serial number server which allows multiple stations/radios to use serial numbers in chronological
:: sequence for contests that require this, e.g. CQ WPX, in spite of interleaved QSO.
:: '''No more than one station per network may have this option checked.''' (Usually the main run station)
:: Note: All stations must have <code>Options|Networking|Use number server</code> checked to use the server.
:: (Except support stations as these stations do not log).
:: The number server must be used also for SO2R in contests that requires chronological serial numbers.
:: More information can be found in the [[Additional_Information#Using_a_number_server|section on using a number server]].

* ''Live score UDP broadcast''
: IP address and and port number for broadcast of live score information.

* ''DX cluster spots UDP broadcast''
: Up to three IP addresses and port numbers can be specified, separated by space.
: For more information, see [[Additional Information#UDP broadcast|UDP broadcast]].

* ''Radio information UDP broadcast''
: Up to three IP addresses and port numbers can be specified, separated by space.
: For more information, see [[Additional Information#UDP broadcast|UDP broadcast]].

* ''Antenna direction UDP broadcast''
: Up to three IP addresses and port numbers can be specified, separated by space.
: For more information, see [[Additional Information#UDP broadcast|UDP broadcast]].

* ''QSOs UDP broadcast''
: Up to three IP addresses and port numbers can be specified, separated by space.
: For more information, see [[Additional Information#UDP broadcast|UDP broadcast]].

* ''UDP broadcast listener''
: Up to three IP addresses and port numbers can be specified, separated by space.
: For more information, see [[Additional Information#UDP broadcast|UDP broadcast]].

==Enable network==

Text command: <code>NETON</code> or <code>NET</code> and <code>NETOFF</code> or <code>NONET</code>

Enables or disables station networking.

Important: If you intend to use the number server in a multi-station setting it is not sufficient to only enable the network. 
A network interface (UDP or client/server TCP) must also be enabled in the network configuration panel (see above).

[[image:neton.png]]

==Networking==

 

[[image:Options_networking_menu2.png]]

===Synchronize standard messages===

Force the standard (CW/Digital) messages on this station onto all other stations on the network.

===Synchronize log===

Immediately starts the synchronization of logs between networked stations instead of waiting for periodical synchronization. 
May be used to "catch up" a rebooted station more quickly.

===Block logging on this station===

When checked, QSO cannot be added to the log at this PC.

Instead, the callsign entered into the log entry callsign field will be added to the bandmap and the log entry callsign field will be cleared.

This option is usually used for Partner mode or operator training.

===Use serial number server===

This option, when selected, enables the use of a number server. The purpose of a number server 
is to allow all networked stations (or both radios in case of SO2R) to use serial numbers 
in chronological order. The most well known contest with this requirement is CQ WPX.

Only one DXLog instance in a network can be the number server, all other DXLog must have this option unchecked.

When checked, the DXLog number server will be used to determine/reserve the next serial number. 
The reservation of a serial number can either be done with via menu options <code>Tools|Data entry|Space key reserves serial number</code> 
and <code>Tools|Data entry|Insert and F2 messages reserve serial number</code> or by adding <tt>$RESERVENR</tt> 
macro to the F2 RUN and S&P messages.

Typically the space option is preferred for phone whereas the macro option is preferred for CW.

<code>Options|Networking|Use serial number server</code> must be checked on all stations on the network that require 
the use of serial numbers (i.e. all stations logging QSO)

If number reservation is successful, the user will be notified in the status bar at the bottom of the main window 
and the serial number in the QSO entry line will change color (Default red).

If a number is reserved but the QSO is not made, a number reservation can be revoked by wiping the entry line. 
(<code>[Alt][W]</code> or <code>[F11]</code>).

'''Important:''' if you are using the number server on a single computer (for SO2R) you need to enable the network 
but you do not need to enable any networking interfaces in the Network configuration panel. You only need to check 
the ''Serial number server'' box.

===Block logging if serial number reservation is unsuccessful===

When using the serial number server and this option is checked, logging will be blocked 
until a serial number is successfully retrieved from the number server.

When a number server is used and the reservation process has started, DXLog will show the active 
QSO number as 000 until a serial number has been successfully reserved or the reservation is canceled.

===Block standard messages if band/mode change rule is broken===

When operating a contest in a multi-station environment, this option will prevent the use of 
the standard F-key messages if the contest's band/mode change rule is broken. 
Keyboard CW (<code>[Alt][K]</code>) and additional (<code>[Ctrl][Alt][F#]</code>) messages are not affected. 
Blocking all messages is primitive and better control is offered by using the <tt>VIOLATION</tt> 
macro conditional in relevant messages.

===Show different active QSO line color during wait status===

When operating a contest in a Multi transceiver environment, this option will change the color of 
the active log so entry line when the band change rule is violated. 
The use of this option is recommended.

* Example: You make QSO on the multiplier radio on 40m band at 00:00Z.
: In that case, you have to stay with multiplier station on 40m until 00:10Z when you are then allowed
: to QSY to other band with the multiplier station.
: If you do it earlier, or you have multiple multiplier stations, each of them will see the QSO line in
: a different color until the 10 minutes has expired. By default the color is red, until last
: minute when it changes to yellow... and after that it reverts back to the normal background
: color of the logging screen.

In multi/single environment it is very useful for each operator to see if a QSO is allowed on 
that band or not. It's easy, you just have to look at the screen, and if the log entry line is 
red in color, you are not allowed to make a QSO. The timers are also visible in the ''Network status''
and ''Band change info'' windows.

===Block standard messages if no operator is logged on===

If checked, F-key messages are disabled if there is no logged on operator.

===Space key updates QSY Wizard===

If checked, ''HamCAP'' will be automatically invoked when <code>[Space]</code> is pressed 
and QSY information will be shown in the ''QSY wizard'' window

===Enable interlock===

Text command: <code>ILOCK</code> and <code>ILOCKON</code> enables interlock 
Text command: <code>NOILOCK</code> and <code>ILOCKOFF</code> disables interlock 

When this option is checked, software interlock is active. 
Transmission is only possible if the other networked DXLog stations allow it.

When enabled, interlock status is shown as a banner in the ''Operating info'' window.

The ''Radio Status'' window illustrates blocking status through its background color. 
Green means successful transmission, yellow means an interruptible block, and red means 
an uninterruptable block.

[[image:inbandblocking.png]]
[[image:inbandblocked.png]]
[[image:Inbandblockinginterruptable.png]]

===Configure interlock===

Text command: <code>ILOCKC</code> or <code>ILOCKCONFIG</code>

[[image:interlock_options.png|none|frame]]

"Status list" refers to the content of the ''Network status'' window.

===Interlock priority options===

Note that the below options are only available when software interlock is activated.

* '''First one wins'''
: No transmissions are interruptible. The station that first starts
: to transmit is always allowed to complete its transmission.

* '''Last one wins'''
: All transmissions are interruptible. All stations can always
: interrupt the transmission of another station. (Not recommended.)

* '''Last one wins if msg not'''
: All but a defined set of messages are interruptible.

* '''Last one wins if msg is'''
: Only a defined set of messages are interruptible.

* '''If msg/is not selection'''
: Selectable list of messages for more granular control of last one wins strategies.

Although it is considered a good practice to use symmetrical blocking strategies, i.e. having 
identical settings in each participating station, it is possible to have different settings in each station. 
If experimenting with this, keep in mind that the interlock strategy settings refer to the 
behavior of blocked station, not the blocking station.

'''Important:''' For software interlock to work on Phone, a external PTT recognized by DXLog must be used. 
The by far simplest solution is to use a footswitch connected to a microHAM device. 
See the [[Menu_Options#microHAM_device_configuration|microHAM configuration]] section for more details. 
It is also possible to connect a footswitch directly to the computer's RS-232 port, providing it has one. 
How to do this is described [[Additional_Information#Connecting_a_footswitch|HERE]].

[[image:k3_settings2.png|400px]]
 

===Announce QSO progress status in interlock===

Show QSO progress status ("CQ", "QSO", "EXCHANGE") instead of "MAN" '''on the blocked station''' when 
asserting PTT on blocking station.

The rule for determining the status is:
* If the call sign field is empty, the block request reason message is "CQ"
* If the call sign field is not empty and focused, the block request reason message is "QSO"
* If the call sign field is not empty and not focused, the block request reason message is "EXCHANGE"

Note that this setting controls the message sent by the blocking station so it needs to be set on 
all interlocked stations for proper function.

===Optimistic interlock===

Applies to software interlock. If a "blocking allowed" confirmation is not received from all 
stations requested before timeout, assume that all relevant stations are blocked and start 
transmission.

===Allow other stations to abort sending===

Checking this option allows other relevant stations (e.g., an inband station) 
to interrupt your transmission.

<code>[Shift][Esc]</code> aborts transmission on other stations.

The key works differently when software interlock is enabled and when it is not.

* With software interlock enabled, stations matching the interlock criteria will be interrupted.

* With software interlock disabled, stations on the same band for multi-multi and of
:the same type for other operations will be interruped.

Also when this option is disabled, the operator may be informed that another station is trying to abort 
the transmission. This notification can however be disabled, see [[Menu_Options#Log|here]] for more information.

==Broadcast==

For details, see the [[Additional_Information#UDP_broadcast|UDP broadcast section]]

==DX cluster==

DX cluster telnet settings and options 
[[image:Dxclustermenu4.png]] 

===Spot handling policy===

Controls how a new incoming spot (local or cluster) is handled.
Three options are available that differ in terms of what existing spots
are removed before the new spot is added. The result is sensitive to
the spot bandwidth (as set in bandmap Properties) centered on the new spot's frequency:

* '''Standard''' - Remove any existing spot with same band, mode, and call as the new spot;
: and any existing spots within the spot bandwidth of the new spot.
: Keeps a relatively uncluttered spot display, with only the most recent spot shown within the
: spot bandwidth of any frequency on the bandmap.
: Pro: Only shows the most recent spot on each frequency.
: Con: In Run you will not be warned if a station you can not hear, e.g. in your skip zone, is calling CQ on your frequency.
: Con: In a busy, global contest, the band map content can be quite volatile.

* '''Complete''' - Remove any existing spot with same band, mode, and call as the new spot;
: and any existing already-worked ("dupe") spots within the spot bandwidth of the new spot.
: Provides a more complete spot display, allowing displayed non-worked spots to be
: within the spot bandwidth of each other.
: Pro: Provides a complete picture with no risk of missing valuable spots.
: Con: None, really.

* '''None''' - All spots are kept. Can quickly result in a very cluttered
: bandmap with many duplicate spots. Recommended only for testing purposes.
: Resembles "Bandmap type: Multiplier" option prior to release 2.4.3.

===Edit connection list===

Add/remove/edit DX Cluster information.

[[image:DXC_list.png]]

To set a default DX cluster connection, select the connection from the list and click the '''Default''' button.

When editing or adding a new connection, give the connection a meaningful name and enter the address, 
either an IP address or a domain name plus the access port for the telnet connection.

[[image:DXC_def.png]]

The DX Cluster connection list can also be bulk edited by loading the file dxclist.txt in a regular text editor. 
The dxclist.txt file is stored in C:\Program Files (x86)\DXLog\Database and should be overwritten with the latest file available. 
DXLog will automatically use this latest file upon running after the file has been updated.

The dxclist.txt file is formatted as follows:

<code>Display Name=internet_address;port_no;Login_Required_(Yes/No);;</code>

E.g.:

<code>W9PA - No Skimmer=dxc.w9pa.net;23;YES;; *W9PA=dxc.w9pa.net;7373;YES;; W9PA - FT8 Only=dxc.w9pa.net;7374;YES;;</code>

A leading Asterisk "*" before the display name marks the default connection.

===Reset connection list===

Resets the connection list content to its default content. Deletes user additions and changes.

===Reconnect default cluster node at start===

Automatically re-establish connection to DX Cluster on loading or creating a new log.

===Default comment for posted spots===

A default comment when submitting spots to the cluster with <code>Alt-F3</code> or S&P auto-spotting. 
This is typically the name of the contest, such as "CQWW" or "WAE".

===Add exchange to posted spots===

Adds the first part of the contest exchange when submitting spots to the cluster, either manually or automatically. 
This option is only active for contests with where the first part of the exchange does not change, such as e.g. county or zone.

===Self spot comment===

Comment added to self spots. Defaults to the name of the current contest.

===Send spots to SmartSDR===

Sends spots via UDP broadcast for display in other software such as SmartSDR. 
Information on configuration can be found [[Menu_Options#Configure_network|HERE]].

===Don't send ineligible spots to SmartSDR===

Prevents sending spots ineligible for the contest over UDP and to SmartSDR.

===Show talk messages from cluster in GAB window===

Cluster talk messages will be shown in the GAB window.


===Don't show logged call in bandmap in Run===

The default behavior of DXLog is to create a local spot at the current frequency, applying the current 
spot processing policy for erasing adjacent dupes, etc.

Checking this option will prevent this and therefore also give the opportunity to e.g. notice if someone 
else is spotted on your Run frequency.

Note that this setting does not prevent the creation of spots in the bandmap by other, networked stations.

==HamCAP==

HamCAP and VOACAP must be installed for these options to work.

HamCAP is a HF propagation prediction tool and is useful for contest strategy and watching for 
possible openings for multipliers. It relies on VOACAP which operates silently in the background.

HamCAP can be downloaded from http://www.dxatlas.com/Download.asp 
Make sure to use the most recent SSN database. It can be downloaded from the same location.

VOACAP can be downloaded from http://www.greg-hand.com

[[image:hamcap_options.png]]

[[image:hamcapprop.png]]

HamCAP options are:

* '''In background''' - prevents HamCAP from grabbing focus, also when on top.
* '''Always on top''' - makes sure HamCAP is always visible, also in front of DXLog.
* '''Tab''' - controls which HamCAP tab is displayed when invoked from DXLog.

To enable automatic HamCAP prediction by pressing <code>[Space]</code> check <code>Options|Networking|Space key updates QSY Wizard</code>. 

With this option checked, pressing <code>[Space]</code> with a call sign in the entry field will trigger a propagation forecast.

==Data files==
This menu is used to update the SCP and Country files from the internet and set Extra 
info and exchange guessing data base options.

[[image:Options_data_files_menu.png]]

'''It is recommended to update the Country Files and SCP database before every contest'''

===Country files===

Text command: <code>CTYFILES</code> or <code>COUNTRYFILES</code> 
Opens the panel below:

[[File:Dxl_country_files.png]]

Allows you to choose which of the country files you will use for calculation of DXCC, CQ zone, 
ITU zone etc. in the currently active contest. 

It is recommended to always use CTY_WT_MOD.DAT which will provide you with the most 
accurate information.

Click on '''Download''' to update the selected country file from the internet and click OK.

After clicking OK, DXLog will ask you to reload the currently active log in order to 
refresh all calculations. This can easily be done using the text command RELOADNOW.

===Update Super Check Partial database===

Downloads the latest version of the super check partials MASTER.SCP database.

On successful download and update you will be asked to restart DXLog, which 
is easily done with the text command <tt>RELOADNOW</tt>.

:[[image:Master.png]]

===Update prefill database from log===

Updates your local prefill database with information from the currently opened log. 
Missing information will be added and prefill data that was modified when logging will be changed.

Please note that all comments in the original data base file (lines starting with # or !) are lost in this process. 
All three types of databases, ''TXT'', ''CSV'', and ''DTB'' can be updated.

'''VERY IMPORTANT:''' Does not work for "mixed population" contests where not all stations have a fixed exchange.

===Extra info plugins | HamQTH===

Enable or Disable, If enabled, a valid Username and Password must be set in the configuration panel. 
'''Important:''' If your password contains "strange" characters such as ?@#$%& or non-latin letters, the service may not recognize your login.

[[image:hamQTHconf3.png|none|frame]]

===Extra info plugins | QRZ===

Enable or Disable, If enabled, a valid Username and Password must be set in the configuration panel.

'''Important:''' If your password contains "strange" characters such as ?@#$%& or non-latin letters, the service may not recognize your login.

'''Important:''' Requires an active XML subscription with qrz.com.

For more information, see https://www.qrz.com/page/xml_data.html

[[image:QRZconf2.png|none|frame]]

===Prefill database settings===
 
[[image:Prefill database settings2.png|none|frame]]

One or more prefill database(s) may be configured using this panel. 
All information entered here will '''override''' the default database settings 
in the contest configuration. However, when a new log file is created, the default 
settings from the contest configuration file will be used.

To configure the use of a database file, click ''Browse'' and select the database file. 
The standard location for database files is <tt>%appdata%\DXLog.net\Database</tt>. 
Select the database file type using the pull down menu. 
Standard DXLog prefill database files are type ''TXT''. N1MM Logger+ database files are type ''CSV'', and 
WinTest database files are type ''DTB''. Be careful to chose the correct file type.

TXT and CSV files typically have a .TXT filename ending. DTB files typically have a .DTB filename ending.

DXLog supports up to four contest exchange elements. Their name, from left to right, are RCVD, RECINFO, 
RECINFO2, and RECINFO3.

You map an information element in a prefill data base file to an exchange element by specifying its number. 
The first information element following the callsign is number 1, the next is number 2, and so on.

* The line format in a DXLog prefill data base file is:
:<code>callsign1;callsign2;callsign3...=information1;information2;information3...</code>

* The line format in a N1MM Logger+ prefill data base file is:
:<code>callsign,information1,information2,information3,information4</code>

* The format for a standard Win-Test prefill data base file is binary and not possible to easily edit or view.

To not use data for a selected exchange element from a database file, set its number to -1. 
This can be relevant in the case of having several data base files, each contributing to individual exchange elements. 
For example, one data base file for grid locator and another for operator name or state. 
In the example above the first exchange element (name) is collected from information element 
number 1 in the CWOps data basefile, whereas the second exchange element (state) is collected 
from information element number 2 in the NAQP database.

'''Special feature for timed prefill database files''': Some contests use age (license, birth, etc.) as exchange 
which is (unfortunately) not constant over time. Such a database file must include meta command #@NNNN (e.g., #@2022) 
to tell DXLog for which year the file is valid. The #@NNNN command must be the first line in the file. 
The #@NNNN commmand only works for contests with age as the only exchange and will produce a dual digit number as prefill. 
The two special ages "00" (YL) and "99" (club) are unaffected by file age.

DTB files only have one information element per call sign and the column numbers should be left at zero.

The ''Fill format'' text box allows you to optionally specify special formatting of the looked up prefill information, 
using C# string formatting syntax. For example, to append a slash to the prefill, the fill format would be <code>{0}/</code>. 
Note that the argument {0} is of the type ''string'' which means that numerical operations, such as zero padding, will not work.

You can have multiple, overlapping databases. For instance you may have two data bases with grid locator information. 
DXLog will start looking for the call in database #1 and then continue down the list until a match is found. 
This means that as a rule, the most up-to-date database should be placed highest in the list. 
In the Check Partials window the context menu option "Show data from prefill database" will show you the content of all 
databases used.

Exchange elements not used in the current contest (most only have one) are ignored and can be safely left as zero.

==Statistics files==

Allows the creation and saving of statistics.

[[File:statistics_menu.png]]

'''DXCC''': Statistics related to DXCC.

: ''Create multiplier statistics'' - Create DXCC multiplier statistics during the contest.

: ''Save multiplier statistics in file'' - Saves the DXCC multiplier statistics in a file. The file format is SQLite (.sdb).

: ''Import expected mult list from log file'' - Import expected mults from a previous contest log (*.dxn) file.

: ''Clear expected mult list'' - Clear the expected DXCC multiplier list.

==Log==

Log display options. Controls the appearance and functionality of the log fields.

'''Important:''' This sub menu can also invoked by right-clicking the DXLog desktop or 
the log entry window when run in "floating mode".

[[image:options_log_menu_3.png]]

* '''Log and entry lines''' - Opens a panel allowing you to hide or display selected fields in the log and entry lines.
* '''Fonts''' - Set the size of the log text.
* '''Entry line fonts''' - Set the size of the entry line text. '''Important:''' Is never smaller than log.
* '''Headers''' - Controls the display of log column headers. Also offers the option to add headers to the entry line(s).
* '''Show QSOs for all bands''' - Controls the display of QSO in the log lines.
* '''Hide DX cluster multiplier warnings''' - Hides alerts of DX cluster spots being multipliers
* '''Hide alerts for being spotted on other band(s)''' - Hides alerts of being spotted on band(s) other than the currently operated.
* '''Hide network abort warnings''' - Hides alerts about transmission being aborted by another station.
* '''Hide QSO numbers''' - Hides the QSO numbers in the log lines.
* '''QSO number digits''' - Sets the number of visible QSO number digits.
* '''Always show mode in QSO line''' - Controls the display of mode in the log lines. Useful for multimode contests. Note that the contest configuration key <tt>FIELD_MODE_VISIBLE</tt> will override this setting and is used for some contests.
* '''Show date in QSO lines''' - Show date in QSO lines. Can only be modified for an already logged QSO.
* '''Show frequency in QSO lines''' - Show the frequency in the log line in addition to the band. Updates in real time.
* '''Show operator name in QSO lines''' - Show the logged on operator name in the QSO lines.
* '''Colors''' - Edit log background and text colors.
* '''Position''' - Controls location of log and entry field.
* '''SO2R/V view type''' - Sets the way the two entry lines in SO2R and SO2V are displayed. ''Classic'': show entry lines one above the other. ''Side by side'': show entry lines with one on the left and one on the right.
* '''Stay in field when moving up and down log''' - When editing log this option keeps the cursor in the same log field when moving up through the QSO's.
* '''Restrict up arrow movement''' - Prevents the up arrow key from moving the cursor into the logged QSO. Use Goto last QSO <code>[Ctrl][Q]</code> to edit log.
* '''Use focus background color in SO2R(V)''' - Use a different background color for entry line of the currently focused radio.
* '''Show previous and current messages''' - Show CW message as it is being sent below the entry line with the previous message above the log line.
* '''Show RX color status''' - Change the entry line background when radio's audio is active. Overrides focus color.
* '''Show border on TX''' - Display a colored border around the entry line of the currently transmitting radio.
* '''Show RX wait border''' - Display a border around the entry line of the radio being held in wait status.
* '''Show cursor in entry line without focus''' - Shows a ghost cursor in the entry line without focus. Very useful for SO2R and SO2V.

==Frequency allocation==

In the heat of the moment it is easy to accidentally call a spotted station 
in a frequency where your license does not allow you to operate.

This function is to prevent exactly this.

When enabled, DXLog will issue a warning pop-up window when grabbing a 
spot in the bandmap or DX cluster announcement windows that would violate 
the selected license.

If desired, DXLog can also block F-key transmission when outside the selected license.

If your license is not listed, please contact the development team for adding it.

[[image:frequencyallocation.png]]

[[image:outofband.png]]

[[image:outofband2.png]]

==Windows==
There are two different ways that DXLog handles the opening of information windows.

* ''Included in the main window'': All windows are opened inside the main window.
* ''Floating'': Enable to use multiple monitors. All windows will be opened outside
: of the main window and can be moved as needed. Please note that in this mode,
: the color of the title bar of each window is not settable.

==Toolbar==

Enable or Disable DXLog toolbar 
[[image:toolbar.png]]

==Reset window positions==

This option brings all windows back to the upper left corner of the screen, useful if a window has been lost off the screen when changing resolution or in a multi screen environment.

File:Options log menu 3.png

2026-04-09T05:26:16Z

Sm7iun: Sm7iun uploaded a new version of File:Options log menu 3.png

Getting started

2026-04-02T16:36:12Z

Sm7iun: /* Operating techniques */

==Introduction and plea==

DXLog is a very powerful contesting software with enormous flexibility.

Unfortunately this comes with complexity and a significant learning curve for new users.

This wiki is written by DXLog experts who may be somewhat blind of the needs of a new user.

If you have ideas for improvement of this section, please share them with the development 
team via the support reflector.

==User interface==

Contest loggers are a little like clothes. Some like a particular style, some don't. 
DXLog has a classic look and feel and builds on a long tradition when it comes to 
keyboard shortcuts and other UI elements. It is keyboard-centric and designed so you 
should very rarely have to take your hands off the keyboard.

Contrary to e.g., N1MM Logger+, DXLog's default setting is to use a single window, a "desktop". 
There are many benefits with this, for instance the fact that you can rapidly switch between 
the logger and another application, such as a web browser, with <code>[Alt][Tab]</code>.

It also allows other applications that have the ability to stay "on top" to do this also with DXLog.

[[image:Dxl_prev2.png]]

DXLog follows the tradition of many other loggers and have one or two entry lines and the nine 
most recent log entries in fixed locations in the main window. The entry lines are either on 
top or beside each other and, unless you are using dual keyboards, you move between them 
using the arrow keys.

[[image:Entryfields.png]]

DXLog shares many characteristics with other loggers but for those used to e.g. N1MM Logger+, 
there are two very important differences.

* The log and the entry lines are connected. Using the arrow keys, moving up past the top
: entry line will take you into the log.

* You can modify a logged QSO but not delete it. In the spirit of old school contest logging,
: you can only mark it invalid. This is done by navigating to the QSO and pressing <code>[Ctrl][X]</code>.
: The "old school" method of changing the callsign of the QSO to your own is also supported.

* The numbering and use of the standard messages is different.

The entry line is divided into fields, most of them are read-only like QSO number, band, mode, time, etc. 
Each contest has at least callsign and one exchange field. Some contests have several exchange fields. 
You move between major fields by pressing <code>[Space]</code> and between all fields with <code>[Tab]</code>. 
RS/RST is not a major field.

The callsign is checked for validity using this regular expression:

<tt><nowiki>^((([A-Z1-9]+0?\/)?[1-9]?[A-Z]{1,3}[0-9]+[A-Z]+(\/[A-Z0-9]+)?(\/[AMP]{1,2})?)|RAEM|EA0)$</nowiki></tt>

When you have completed your entry, you typically log the QSO using either <code>[Enter]</code> or <code>[+]</code>.

The location and visibility of the log and entry line column headers can be controlled with <code>Options|Log|Headers</code>.

Note that the rightmost ''Stn'' station type column becomes visible only when activating networking or selecting 
an operating technique other than SO1R.

==Creating a log file==

To start using DXLog, the first step is to create a log file. Without an open log file, 
DXLog will just show an empty desktop.

To create a log, select <code>File|New</code>. This opens the contest configuration window.

DXLog needs exclusive and unrestricted access to its log file and relies on Windows' 
standard file permissions for this. This means that some types of shared or synchronized 
directories, or directories in virtualized environments, may not work for log file storage.

'''Unlike most other loggers, DXLog is compatible with Microsoft OneDrive.'''

[[File:DXL_ContestConfig1.png]]

There are many text boxes to fill and not all are used by all contests, but it is a good idea to 
fill as many of them as possible since it will save you typing each time you create a new log.

Should DXLog miss information from you when you click the ''OK'' button, you will get a helpful popup 
window and the cursor will be placed in the field with missing or invalid information.

'''Important: The content of fields like''' '''''Exchange''''' '''and''' '''''State''''' '''is not always the actual exchange''' 
'''or state.''' For instance, the ''Exchange'' field may contain keywords like "DX" to tell DXLog to use a different 
type of exchange, such as a serial number.

After having clicked ''OK'' you will get a file browser window that allows you to decide the name and location 
of your new log file. It is good practice to use a separate directory for each contest since you will have 
other files related to the contest, call history files, export files like Cabrillo, ADIF, SUM, etc.

It is also a good practice to include things like contest name, station callsign and year in the log's filename.

The first time a log is created after the installation, "factory default" colors and window locations 
will be used. From this point on, every time you create a new log, the color settings, the active 
windows and their location will be inherited from the most recently opened log. This means that if you 
for instance run a weekly test in which you want a particular layout or color scheme, it is a good idea 
to open the previous' weeks log before creating a new one.

Also note that messages are stored on a per-contest basis. This means that when creating a new log, the 
messages from the previous, same contest will be used. If there is none, the contest's default messages will 
be used. Since some contests have messages based on location or participation status, this is important 
to be aware of.

You will find much more information in the [[Configuration#Contest_configuration|contest configuration section]].

==Controlling the radio==

The next step is to set up the communication with the radio. You reach the radio interface by 
either clicking <code>Options|Configure interfaces</code> or by typing the text command <tt>SETUP</tt> 
and pressing <code>[Enter]</code> on the entry line.

[[File:Portconfig.png]]

There are numerous settings and alternatives in how to set up your radio. On some models special 
features like diversity, or the built in voice keyer, is supported. In this panel you can also 
configure the control of peripherals such as SO2R controllers. You can find more information in the [[Menu_Options#Configure_interfaces|Configure interfaces section]].

You can also find general recommendations about settings for particular radio models in the 
[[Radios|supported radios]] section.

Setting up DXLog for digital operation involves many settings.

John G4IRN has prepared an excellent tutorial on this topic which can be [https://youtu.be/6VqVCTGUkoI '''viewed here'''.]

==Databases==

The next step is to make sure two important data bases are up to date; the country data base <tt>CTY.DAT</tt> 
(and its siblings) and the callsign database <tt>MASTER.SCP</tt>.

The menu <code>Options|Data files|Country files</code> opens a window that allows you to update three 
alternative country databases. Chose one at the time and click ''Download''. Normally the most detailed, 
<tt>CTY_WT_MOD.DAT</tt> is the recommended one to use.

The callsign database is updated with the menu <code>Options|Data files|Super check partials|Update</code>.

To make all updates come into effect, type <tt>RELOADNOW</tt> followed by <code>[Enter]</code> or simply 
close and restart DXLog.

==Operating techniques==

The next step is to chose your operating method, ''Technique'' in DXLog terminology.

DXLog supports four different techniques; SO1R, SO2V, SO2R, and SO2R Advanced.

SO1R means Single Operator, One Radio. SO2R means Single Operator, Two Radios. SO2V means 
Single Operator, Two VFO but in practice this is normally also Two Receivers. 
In a multi-operator setting you typically use SO1R but an advanced operator can also use SO2V.

The menu <code>Operating|Technique</code> let you choose between SO1R, SO2R, Advanced SO2R and SO2V.

Each technique supports two operating "states"; ''Run'' and ''Search & Pounce'' (or ''S&P'' for short).

Run means you call CQ and work calling stations. S&P means you search for stations and work them by calling them.

Each state has a separate set of predefined messages (see below) and ESM behavior (also see below). 
The keyboard shortcut to switch between the states is <code>[Ctrl][Tab]</code>.

There are also some options for forcing an automatic change, such as 
<code>Tools|Data entry|F1 returns to Run always</code> and <code>Tools|Enable automatic Run/S&P selection</code>.

===SO1R===

SO1R is the most basic and it is the method you use in a single operator setting using a single 
receiver radio or in multi-station setting.

When using this technique, you have a single entry line and one radio with one receiver. 
The band map shows the band map for the currently selected VFO. 

In the top of the bandmap the frequencies of VFO A and VFO B are shown in boxes. 
The boxes are clickable and you can also switch between the VFO using <code>[Keypad *]</code>. 
If you want to make a rapid excursion to work e.g. a multiplier, you can always jump back to 
your Run frequency with <code>[Alt][F4]</code>. 

'''Important:''' SO1R only works for Radio 1 in the <code>Options|Configure interfaces</code> panel.

:[[image:so1r-cqww.png]]

===SO2R and Advanced SO2R===

uses two radios which operate in parallel, each having a separate entry line. (Although you never 
transmit with more than one at any time.)

In "standard" SO2R you operate by manually switching your "focus" between the two radios. 
This is done using the up and down arrow keys or <code>[Keypad *]</code>. 

SO2R also supports external audio control by a large range of SO2R controllers such as all [https://www.microham.com/ microHAM] 
keyers/controllers or devices such as the [http://www.k1xm.org/SO2R/ YCCC SO2R box] or [https://nn1c.org/so2r/ SO2R mini].

In Advanced SO2R the focus shifting is typically scripted, using up to eight different "scenarios" for different 
situations such as hunting for multipliers, alternating CQ, or managing a large pile-up.

More information can be found in the [[Menu_Operating#Advanced_SO2R|Advanced SO2R section]]. 
This feature is particularly appreciated by advanced contesters. 

SO2R requires two radios (Radio 1 and Radio 2) configured in the <code>Options|Configure interfaces</code> panel. 

'''Important:''' If running a contest where the exchange is a serial number, you must use a number server and number 
reservation to secure that the transmitted and logged serial number are the same. You will find more 
information about this in the [[Additional_Information#Using_a_number_server|using a number server section]]. 

[[image:so2r-cqww.png]]

===SO2V===

At a first glance, SO2V looks similar to SO2R but uses only a single radio (two "R" entry lines). 
This method is primarily intended for dual receiver radios (such as Elecraft K4, ICOM IC-7610, or Yaesu FTDX101D) 
but offer some usability and efficiency benefits also for single receiver radios. 

Like in SO2R, learning to have one receiver in each ear will maximize your efficiency. 
The logical model of SO2V is two radios with a shared transmitter. 

Unlike SO2R, the two "radios" are typically on the same band.

Split band SO2V puts very challenging requirements on antenna and amplifier band switching speed 
and requires a very careful station design. DXLog offers no protection against e.g., hot switching
in such a situation.

The most common way to operate SO2V is to switch focus between the two "radios" the same way 
as in "standard" SO2R; using the arrow keys or <code>[Keypad *]</code>. However, dual keyboards may also be used.

It is common practice to run (i.e. call CQ) on the main VFO (left ear) and do S&P on the sub VFO (right ear). 
One of the reasons for this is tradition but another is that RIT is only supported on the main VFO on many radios.

More information about operating SO2V can be found in the [[Menu_Operating#SO2V|SO2V menu item section]]. 
On selected radios (such as more advanced ICOM radios), automatic VFO knob focus and sub receiver control 
is supported. (C.f. the [[Radios|supported radios section]].)

'''Important:''' RTTY SO2V requires the use of FSK together with a radio controller that offers two 
FSK keying COM-ports for the same radio, such as the microHAM series of keyers.

It is also possible to use SO2V with single-receiver radios. There is a benefit in having separate band 
map for each VFO and being able to rapidly switch between VFO A and B.

'''Important:''' SO2V only works for Radio 1 in the <code>Options|Configure interfaces</code> panel.

[[image:so2v-cqww.png]]

More information about the four possible techniques can be found in the [[Menu_Operating#Technique|operating technique section]].

==Standard messages==

A fundamental feature of a contest logger is the ability to send predefined messages.

DXLog has two types of predefined messages; the Standard messages and the [[Menu_Options#Modify_additional_messages|Additional messages]].

The standard messages contain two sets; one for ''Run'' and one for ''Search & Pounce''.

You reach the configuration panel for the standard messages by pressing <code>[Ctrl][Alt][C]</code>, 
clicking <code>Options|CW/Digi|Modify standard messages</code>, or typing the text command <tt>MSGS</tt>.

Each standard message is associated with a function key; <code>[F1]</code> to <code>[F7]</code>, <code>[Insert]</code> and <code>[+]</code>. 
In this wiki, they are also referred by these names.

The use of each message follow a long standing tradition in contest loggers and since functions in DXLog 
(e.g., ESM and DVK) assume the messages are used this way, do not use them differently unless you know 
exactly what you do.

{|class="wikitable"
|+style="text-align:Left;"|Contest loggers' tradition
|-
| Message
| Use
|-
| F1
| Initiate QSO: CQ (RUN) or own call (S&P)
|-
| F2
| RST and contest exchange
|-
| F3
| Contest exchange, typically unabbreviated
|-
| F4
| Own callsign
|-
| F5
| Other station's callsign
|-
| F6
| Request for repetition
|-
| F7
| Query (CW) or QRZ (digital)
|-
| Insert
| Make QSO. Conclude QSO in S&P.
|-
| Plus
| Confirm QSO. Conclude QSO in RUN.
|}

When creating a new log for the first time in DXLog, the standard messages are automatically populated. 
(If the log is not your first for the particular contest, the messages from the previous time will be used.)

Below is one example.

[[File:Standard_messages_cw2.png]]

The messages are composed by regular letters and numbers, special characters, and macro commands. 
Macros always start with a dollar sign, e.g., <tt>$RST</tt>, <tt>$LOGGEDCALL</tt>, or <tt>$CORRECT</tt>. 
Special characters are mainly used to control the CW keying, e.g., <nowiki>^</nowiki> means a half word space 
and <nowiki>+</nowiki> means an increase of the CW speed by 4WPM.

A full list can be found in the [[Configuration#Macro_commands_and_special_characters|macro commands and special characters section]].

Since the exchange, CQ etc. varies between contests, every contest has its own set of default messages. 
These default messages are however only used the first time a log is created for the particular contest. 
To allow customization, all following logs created for a particular contest use the messages from the 
last time a log was saved for this contest. This means that you never have to repeat customizations 
such as adding <tt>$CLEARRIT</tt> to your CQ macro, etc. There is a very large repertoire of macros available. 
You can even call own scripts in the message using the <tt>$!scriptname</tt> syntax.

You can always return to the default messages by clicking the Defaults button. This can also be helpful 
when switching "role" from a previous time you participated in the same contest, such as member/non-member, 
IOTA station/non-IOTA station.

A complete list of macros and special characters as well as the very powerful conditionals syntax 
can be found in the [[Configuration#Macro commands and special characters|message macros section]].

Space characters in the beginning or end of the message are always ignored. To introduce a delay, use <code>$DELAY</code>.

'''Important:''' Contest definitions in DXLog are constantly corrected and updated. If you find that 
the messages from the previous time you participated in a contest are wrong, the first thing to try is 
to reset the messages to their default values.

'''Very important:''' If you run CW and want to secure good spotting by the Reverse Beacon Network, 
do not use speed changes in your CQ message. Your CQ does not have to repeat your call but to get 
spotted, RBN needs to see your call at least twice in a time window corresponding to 256 morse 
code characters at your current transmit speed. Apart from your callsign, a CQ must include at 
least one of the following keywords to bet spotted: CQ, QRZ, UP, TEST, NA, SS, FD, or UP.

===Sprint contest===

Sprint contests, like the NCCC Sprint and the NA Sprint are different in that the calling station 
"inherits" the QSO frequency, forcing operators to be very active and making spotting irrelevant.

The "Sprint exchange logic" checkbox in DXLog's Standard messages panel is a relic from older loggers 
and requires DXLog to be fixed in Run mode which therefore prevents the use of ESM.

A more modern way of operating a sprint contest that fully leverages DXLog's ESM, while still supporting 
operation using F-keys, is described below.

First, make sure the following options are checked:

<tt>Tools|Data entry|Enable Run/S&P switching</tt> 
<tt>Tools|Data entry|Enable automatic Run/S&P switching</tt> 
<tt>Tools|Data entry|F1 key forces Run mode</tt> 
<tt>Tools|Data entry|Enable ESM mode</tt> 
<tt>Tools|Data entry|Focus received exchange after sending exchange in Run</tt> (Optional) 

The example below is from NCCC Sprint and works like follows:

Being called:

* You call CQ by pressing <tt>[F1]</tt>. If you are already in Run, you can just press <tt>[Enter]</tt> with an empty callsign field.
* When you are called, you enter the callsign and press <tt>[Enter]</tt>. This sends the Run Insert message <tt>$LOGGEDCALL $MYCALL $F2</tt>.
: (With the option above, DXLog can automatically move the cursor to the exchange field at this point)
* If you need to resend, you can press <tt>[Enter]</tt>, <tt>[Insert]</tt>, or <tt>[F2]</tt> depending on the circumstances.
* You enter the received exchanges and press <tt>[Enter]</tt> again, this will send the Run Plus message ee and log.
* Moving to a new frequency will take you to S&P mode.

Calling:

* You are in S&P and with the cursor in the callsign field you call a station by pressing <tt>[Enter]</tt>.
* When the station answers, you press <tt>[Space]</tt> and enter the received exchanges.
* Pressing <tt>[Enter]</tt> will now send the S&P Insert message <tt>$LOGGEDCALL $F2 $MYCALL</tt>, log, and switch to Run.
* If you need to resend, you press <tt>[F2]</tt>.
* You now "own" the frequency, and being in Run, you just need to press <tt>[Enter]</tt> to call CQ.

[[File:Standard_messages_sprint.png]]

==Voice memory playback==

In phone contesting having a means to transmit a pre-recorded CQ message is a great help. 
Sometimes for other messages too.

DXLog has a built-in voice recorder (often referred to as a DVK - digital voice keyer) but also supports the 
use of that built into many radios and peripherals. (More information can be found in the [[Menu_Options#Digital_Voice_Keyer|Digital Voice Keyer]] section.)

'''Important:''' If you use the radio's built in voice keyer, make sure to check the box 
"Do not use PTT with voice keyer" on the COM port controlling your radio's PTT to avoid a 
self-locking PTT loop and to make sure the transmitter's audio source is not forced to be the microphone.

If you want to use ESM (see the [[Getting_started#ESM|ESM section]]) also on phone the message 
content convention from CW and digital modes need to be followed.

{|class="wikitable"
|+style="text-align:Left;"|Voice memory convention
|-
| Message #1
| CQ message. E.g. "SM7IUN, contest"
|-
| Message #2
| S&P exchange, when the contest allows. E.g. "Roger, you are five nine fourteen"
|-
| Message #4
| Own call. E.g. "SM7IUN"
|-
| Message #6
| Request repeat. "Again, again?"
|}

'''Important:''' On Phone in SO1R, SO2V, and SO2R, macro commands are only recognized in the 
INSERT and PLUS messages and are ignored in messages 1 through 7. In SO2R Advanced, however, 
each used scenario needs to include the wanted playback macros, $F1, $F2, etc.

'''Important:''' A useful message can be the one associated with logging the QSO in RUN. 
E.g. "Thank you and good luck, SM7IUN, contest". However, for this to work, the RUN PLUS message 
must contain the macro commands to send a message and log. (e.g. <code>$PBPLUS $CR</code>).

Since the INSERT message i RUN contains the other station's call it can not be prerecorded. 
Following the conventions above, the standard INSERT message will however work for S&P.

==Useful settings==

Since this is just a quick-start guide, only the most commonly used or misunderstood settings will be covered here.

<code>Options|Load contest at startup</code>
: Guarantees that the right log file is opened after e.g. a power outage or a reboot.
: '''Very important''' to enable in a multistation setting since opening the wrong log file while
: networked with other stations will force merging of the logs which normally is highly undesired.

<code>Options|Interface specific options|Dual receiver radio (Use split in SO2V)</code>
: A very important setting for SO2V. Should be enabled for dual receiver radios and
: disabled for single receiver radios.

<code>Options|Interface specific options|Band change keys affect both VFO</code>
: Makes band changes with <code>[Alt][F1]</code> and <code>[Alt][F2]</code>
: switch the band of the selected radio's both VFO. Recommended.

<code>Options|Log|Show border on TX</code>
: Shows a colored frame around the entry line of the currently transmitting radio.
: Recommended.

<code>Options|Log|Show previous/current messages</code>
: Shows the current and previous messages sent on the screen.
: Very convenient e.g. when running SO2R with low or no sidetone.

<code>Options|Log|Show cursor in entry line without focus</code>
: Shows a shadow cursor in the unselected entry line. Highly recommended.

<code>Tools|Data entry|Enable ESM mode</code>
: Makes <code>[Enter]</code> send relevant messages in both ''Run'' and ''S&P''.
: Also toggles with <code>[Ctrl][M]</code>. For for more details, see the [[Getting_started#ESM|ESM introduction]].

<code>Tools|Data entry|Enable Run/S&P switching</code>
: Allows switching between ''Run'' and ''S&P''. Recommended setting unless in a DX-pedition.

<code>Tools|Data entry|Enable automatic Run/S&P selection</code>
: Makes DXLog automatically switch to ''S&P'' when you move the VFO knob or grab a spot. Recommended.

<code>Tools|Data entry|Exchange guessing|Automatic</code>
: When applicable, produces an exchange guess as you type. Does the same also for dupe
: and new multiplier information. Highly recommended.

<code>Tools|Data entry|F1 forces Run mode</code>
: Makes the <code>[F1]</code> key always switch to ''Run'', mark the CQ frequency and send CQ.
: Recommended.

==ESM==

ESM, or Enter Sends Message, which the acronym stands for, is a popular and widely used 
way of streamlining the QSO process in a contest logger.

There are different schools in how ESM should work and loggers differ in their implementation.

DXLog has a very straightforward and deterministic ESM. It is stateless which means that it 
does not try to guess the intentions of the operator based on past actions.

The message sent by <code>[Enter]</code> only depends on three factors:

: Operating state (''Run'' or ''Search & Pounce'')
: The location of the cursor
: The content of the current field

This makes DXLog's ESM 100% predictable and easy to learn.

Since ESM may be undesired on Phone the option <code>Tools|Data entry|ESM mode only for CW</code> 
allows you to use it only for CW in e.g., a mixed mode contest entry.

DXLog ESM assumes the following configuration of the standard messages:

: RUN F1 - CQ message
: RUN F6 - Request exchange
: RUN INSERT - Send other call and exchange
: RUN PLUS - Send corrected call if required, log and send semi-CQ (such as own call)

: S&P F1 - Own call
: S&P F6 - Request exchange
: S&P INSERT - Send exchange and log

The function is as follows:

===Run===

Run means you call CQ and stations call you.

Pressing <code>[Enter]</code> in RUN will:

* with the cursor in an empty callsign field send RUN F1, typically CQ
* with the cursor in a partially or correctly filled callsign field send RUN INSERT
* with the cursor in an incorrectly filled exchange field send RUN F6
* with the cursor in a correctly filled exchange field send RUN PLUS

The typical sequence of a Run QSO with ESM is

* with an empty entry field, you press <code>[Enter]</code> to call CQ
* when called, you type the caller's callsign and press <code>[Enter]</code>
* if the caller does not come back to you, you press <code>[Enter]</code> again
* when the caller comes back to you, press <code>[Space]</code> to move cursor to the exchange field
* you type the caller's exchange, or just accept a pre-fill, and press <code>[Enter]</code> to conclude the QSO
* repeat

For a big gun station, where correct reception of the exchange is (almost) guaranteed, you can 
automatically shift focus to the exchange field after having sent the exchange by enabling the 
menu option <code>Tools|Data entry|Focus received exchange after sending exchange in Run</code>.

===Search & Pounce===

Search and Pounce or S&P for short, means you search for stations and call them.

Pressing <code>[Enter]</code> in S&P will:

* with the cursor in the callsign field send S&P F1
* with the cursor in an empty or incorrectly filled exchange field send S&P F6
* with the cursor in a correctly filled exchange field send S&P INSERT

The typical sequence of a S&P QSO with ESM is

* having grabbed or manually entered the other station's callsign, you press <code>[Enter]</code> to call
* if the station does not respond, press <code>[Enter]</code> again
* when you get a response, press <code>[Space]</code> to move to the exchange field and type the exchange or accept a pre-fill
* press <code>[Enter]</code> to send your exchange and conclude the QSO
* if the other station did not get your exchange correctly, press <code>[Insert]</code> to send it again to make sure you get logged
* repeat

For a big gun station, where correct reception of the exchange is (almost) guaranteed, you can automatically 
shift focus to the exchange field after having called the station by adding the <tt>$SPACE</tt> macro to the S&P F1 message.

You can find more information on ESM in the [[Menu_Tools#Data_entry|Data entry menu section]].

==Connecting to the DX cluster==

DXLog offers two ways of connecting to the DX cluster, one basic, included in DXLog, and one advanced, 
relying on a companion program.

'''Important:''' If your current log is unassisted (either by selection or since the contest rules generally 
forbid assistance), DXLog will not display any cluster spots, even when connected. If the contest allows self-spotting, 
you can however spot yourself.

===Basic connection===

Since an increasing number of contests allow self-spotting, also on unassisted entries, DXLog always allows 
connecting to the DX cluster but does not display incoming spots when the log is set to an unassisted entry category.

DXLog's default cluster node is VE7CC. If you prefer another node, you click <code>Options|DX cluster|Edit connection list</code>. 
This opens a window that allows you to edit existing entries, add new ones, and select a new default node. (More [[Menu_Options#Edit_connection_list|HERE]]).

If you get lost editing the list, you can always reset it to "factory" settings with <code>Options|DX cluster|Reset connection list</code>.

Checking <code>Options|DX cluster|Reconnect default cluster node at startup</code> will make sure you are always 
connected when running DXLog.

You connect by clicking <code>Commands|DX cluster|Connect default</code> or <code>Connect other</code>. 
This will bring up a dialog with your default login information. Its content is remembered by DXLog between sessions.

Clicking <code>Windows|DX cluster monitor</code> or pressing <code>[Alt][O]</code> will bring up a window that shows the 
telnet text flow from the cluster node. Although meaningless to use for catching spots, it can be used to make sure 
the connection is correct and see error messages if the login procedure fails.

Spots should now start appearing in your bandmap.

DXLog will only display spots of the mode or modes relevant for your contest entry.

===Advanced connection===

If you are in a multi-station setting and want to separate the cluster connection from your operating positions or 
have a need to connect to multiple spot sources, you can use the <tt>DXLog.net.DXC</tt> companion program.

<tt>DXLog.net.DXC</tt> distributes spots on a LAN to one or several instances of DXLog via the normal DXLog multi-station 
networking protocol. This means networking must be enabled and correctly configured.

Make sure <code>Options|Enable network</code> is checked and that "networking for multiple stations" is checked in the 
network configuration panel. Also make sure that the station's networking IP address is correct. It should typically 
be the computer's IP address with the last number replaced by 255.

<tt>DXLog.net.DXC</tt> offers a rich set of features including blacklisting and skimmer control. More information can be found [[DXLog.net.DXC|HERE]]

In <tt>DXLog.net.DXC</tt>, enter your callsign by clicking <code>Settings|User data</code>. Also check your network settings 
under <code>Settings|Network</code>. For a single station setting, you can click the ''Local defaults'' button which will not 
send spots outside your computer. Clicking ''LAN defaults'' will distribute spots to your entire LAN.

The checkbox ''Cluster cmd'' should be checked for at least one cluster connection. 
This checkbox controls to which nodes commands from DXLog (such as self spots) are forwarded.

You connect to the cluster node by clicking the ''Connect'' button.

If everything is correct, you should now see spots arriving in the <code>Windows|DX cluster monitor</code> window on all networked stations. 
If the current log's category is assisted, they will also appear in the bandmap.

If you are running <tt>DXLog.net.DXC</tt> on a separate computer or server and want to establish all cluster connections automatically 
when <tt>DXLog.net.DXC</tt> is started, check <code>Operating|Connect all tabs at startup</code>.

==The bandmap and other windows==

Beside the entry lines, the bandmap is one of the most central functions in a contest logger. 
The two bandmaps are enabled with <code>Windows|Radio 1</code> and <code>Windows|Radio 2</code>. 
(Note that only one is available in SO1R.)

[[image:Bandmaptherm.png]] [[image:Bandmaplist.png]]

With an internet connection to the DX Cluster you will see the spots spread out over an intuitive, 
thermometer-like representation of a part of the current frequency band or as a color-coded listing. 
You can either let DXLog connect directly to the DX Cluster (as described in the [[Menu_Commands#DX_cluster|DX Cluster section]]) 
or via the DXLog.net.DXC cluster connectivity utility, described in the [[DXLog.net.DXC|DXLog.net.DXC section]].

The bandmap can be set up to convey a large amount of useful information such as if a spot represents 
a new multiplier, if it has been worked before, a suitable antenna direction, the sun's position at the 
station's location etc. You can quickly jump between spots by holding down <code>[Ctrl]</code> while pressing 
the up and down arrow keys. (There are many more keyboard shortcuts associated with the band map, for more 
details, see the [[Keyboard_and_text_functions#Keyboard_functions|keyboard functions section]].) 
The bandmap can be zoomed in and out using the scroll-wheel on the mouse. The settings are available by right-clicking 
the bandmap and selecting <code>Properties</code>. Further information about the bandmap can be found in the [[Menu_Windows#Radio_1|bandmap section]].

The bandmap is also very useful when operating without a DX cluster connection, a.k.a. unassisted. 
You can add stations to the bandmap by entering the call and pressing <code>[Ctrl][Enter]</code>. 
Such manually entered stations are automatically erased when worked in Run. 
Stations worked in S&P are also added to the bandmap to avoid you having to identify them again.

'''Important:''' The bandmap contains some S&P features, such as wiping the currently entered call and/or adding an 
entered call to the bandmap when tuning away from it, that are active also with no bandmap window open. 
You find these settings by selecting <code>Properties</code> in the bandmap context menu.

In the Bandmap properties panel you will also find the spot lifetime settings. These control how long a spot will 
be displayed before erased. A suitable number for cluster spots is 11 minutes for CW and RTTY (RBN has a respotting 
timer of 10 minutes) and 20 minutes or more minutes for phone and other digital modes. For manual spots, 30 minutes 
is a reasonable number.

Besides the bandmap there are many useful windows available. ''DX cluster announcements'' can show you a 
list of all valuable spots as one single list.

''Check Partials'' and ''Check N+1'' helps you guess callsigns you are unsure of. ''Check Multipliers'' gives 
information on which bands you have worked a certain multiplier.

Finally ''Clock'' is a very helpful little bar showing essential information like exact time, operating 
state, logged in operator etc.

==After the contest==

After the contest you typically want to create a Cabrillo or EDI file for submission and perhaps an ADIF file to 
upload to LoTW or import in a bulk logger.

Cabrillo files are exported using <code>File|Export|Cabrillo</code> and ADIF files using <code>File|Export|ADIF</code>. 
ADIF exports offers you the option to also include ''X-QSO'', which you normally do not want to do. There however situations 
when you may want to include them, such as when excluding valid QSO on another band for a single band contest entry.

If your contest uses a prefill database, and you trust your log, you can update the database using 
<code>Options|Data files|Update database</code>. It is possible to update data files of any supported type.

Be however aware that your own updates will be lost the next time an updated database is included in a new DXLog release that you install. 
If you really want to preserve your updates, make a copy of DXLog's database in the same directory as the log file. 
More on how to manage prefill databases can be found in the [[Menu_Options#Prefill_database_settings|prefill database settings section]].

Entering postcontest mode with <code>Edit|Postcontest mode</code> will allow you to edit all properties of the logged QSO using <code>[Alt][F]</code> 
and <code>[Ctrl][F1]</code>/<code>[Ctrl][F2]</code>. It also allows entering a paper log by opening the time field for direct entry.

==Tips and tricks==

* If you connect to the DX cluster and see no spots in your bandmap, make sure you are not using an unassisted contest entry.

* Try the world map. It will show where you are spotted on the DX cluster.

* Try SO2V. You will have more fun and become a an even more productive operator with just one radio.

* Get acquainted with ESM. Once familiar with it, you will find it very convenient.

* On most radios <code>[Shift][Up]</code> and <code>[Shift][Down]</code> work as RIT in ''Run'' and frequency adjustment in ''S&P''. <code>[Shift][Delete]</code> zeroes RIT regardless of operating mode.

* <code>[Ctrl][Up]</code> and <code>[Ctrl][Down]</code> jumps between spots in the bandmap and grabs them onto the focused entry line.

* <code>[Ctrl][Space]</code> grabs the spot in the bandmap on or close to your current frequency.

* <code>[Ctrl][Alt][Up]</code> and <code>[Ctrl][Alt][Down]</code> jumps between spots in the other VFO or radio, depending on if <code>Operating|Bandmap|QSY Opposite radio instead of 2nd VFO</code> is checked or not.

* <code>[Shift][Ctrl][Up]</code> and <code>[Shift][Ctrl][Down]</code> jumps to the next spot that is a multiplier.

* Double-clicking a spot in the bandmap grabs it. There is a menu option change this to single click.

* <code>[Ctrl][Enter]</code> creates a spot using an entered callsign and the focused radio's frequency.

* <code>[Alt][K]</code> opens a panel for sending CW or a conversational digital mode directly from the keyboard. It is closed by pressing <code>[Alt][K]</code> or <code>[Enter]</code>.

* <code>[Ctrl][Alt][+]</code> or <code>[Ctrl][Alt][Keypad +]</code> forces a QSO to be logged, disregarding all validity checks.

* Pressing <code>[Ctrl][X]</code> with the cursors on a QSO in the log will "delete" the QSO by marking it invalid.

* <code>[Shift][Ctrl][F1]</code> shifts focus to radio 1, switches to ''Run'', and sends CQ in SO2R and SO2V. In SO1R and SO2R Advanced it just sends the F1 message. Depending on your operating preferences you may want to redefine <code>[F1]</code> to always execute this key.

* <code>[Alt][Q]</code> activates "intelligent quick QSL" which is a great convenience for DXpeditions and large contest stations. It uses rate statistics to send a short confirmation at the end of each QSO but still regularly send the full callsign.

* The text commands ''RELOAD'' and ''RELOADNOW'' reloads and rescores the current log. The latter skips the confirmation popup. (This command also refreshes contest definitions and scripts without event handlers.)

* ''RESET'' eller <code>[Ctrl][Alt][R]</code> resets all hardware interfaces. When connecting/disconnecting equipment or in the presence of EMC or RFI issues, this can be very helpful.

* To search for a certain callsign in your log, type the callsign in the entry field. The Check Callsign window will show you which bands you have worked the callsign on. Double-click the red checkmark to jump to the corresponding QSO in the log. Return to the entry line with <code>[Ctrl][End]</code>

* Holding down <code>[Ctrl]</code> during start-up of DXLog will give you the option to not restore the previous layout and log file.

* On many contests you can do a reverse look-up from a prefill data file by entering the exchange and pressing <code>[Space]</code>. This will show the candidate matches in the Check Partials window.

* On many contests where the exchange is a grid, you can type a six-character grid in the callsign entry field and press <code>[Space]</code> to get distance and azimuth.

* If you have problems starting DXLog, as a last resort go to the directory <code>%appdata%</code> using the <code>[Win][R]</code> key and rename the <tt>DXLog.net</tt> directory. Then try again.

==DXLog system files==

Log and export files can be stored anywhere on your computer but in line with 
Windows' application programming standard, DXLog keeps its internal system files 
in a special, normally hidden, directory.

This directory can be opened either via Windows' file explorer, using the symbolic address 
<tt>%appdata%\DXLog.net</tt> or using DXLog's menu item <code>File|Open configuration directory</code>.

'''Important:''' The only real need a regular user has to open this directory is to install contest or 
database updates between regular DXLog releases or at emergencies.

Updates to contest definitions and/or databases are better updated by clicking <code>File|Update contest</code>.

The content of the configuration directory is the following:

* Directory '''Contest'''
: contains a working copy of all contest configuration files.
* Directory '''Database'''
: contains a working copy of all database, country, warning and regexp files.
* Optional directory '''CustomForms'''
: when exists contains custom form DLL files.
* File '''DefMsgs.sdb'''
: Default messages for all contests operated. Not editable.
* File '''deftest.dxl'''
: Default contest configuration. Not editable.
* Optional file '''DXCSpotHistory.txt'''
: Result of checking "Incoming spots logging" in DX Cluster announcement window.
* Optional file '''DXCStreamHistory.txt'''
: Result of checking "Stream logging" in the DX Cluster monitor window.
* File '''DXLog.net.config.backup'''
: A backup copy of the most recent working DXLog.net.config
* File '''DXLog.net.DXC.config'''
: DXLog.net.DXC configuration data
* File '''DXLog-debug.txt'''
: Crash and error logging file
* File '''SERIAL-TRACE-...'''
: Serial communications debugging log

Main Page

2026-04-02T16:35:11Z

Sm7iun:

__NOTOC__
{|width=100%
| style="vertical-align:top;" colspan=2|
{{Main Page header}}
|-
|width=70% |
<ol type="I">
<li>'''[[Introduction]]'''
<ol>
<li>[[Introduction#Reasons for chosing DXlog|Reasons for chosing DXLog]]
<li>[[Introduction#History|History]]
<li>[[Introduction#Authors and Contributors|Authors and Contributors]]
</ol>
<li> '''[[Installation|Installation]]'''
<ol>
<li>[[Installation#Download_the_software|Download the software]]
<li>[[Installation#Prerequisites|Prerequisites]]
<li>[[Installation#Install_the_software|Installing DXLog]]
<li>[[Installation#Installing_intermediate_releases|Installing intermediate releases]]
<li>[[Installation#Installing_an_older_release|Installing an older release]]
<li>[[Installation#Resetting_DXLog_to_factory_settings|Resetting DXLog]]
</ol>
<li> '''[[Getting_started|Getting started]]'''
<ol>
<li>[[Getting_started#Reasons for choosing DXLog|Reasons for choosing DXLog]]
<li>[[Getting_started#User interface|User interface]]
<li>[[Getting_started#Creating a log file|Creating a log file]]
<li>[[Getting_started#Controlling the radio|Controlling the radio]]
<li>[[Getting_started#Databases|Databases]]
<li>[[Getting_started#Operating techniques|Operating techniques]]
<li>[[Getting_started#Standard messages|Standard messages]]
<li>[[Getting_started#Voice_memory_playback|Voice memory playback]]
<li>[[Getting_started#Useful settings|Useful settings]]
<li>[[Getting_started#ESM|ESM]]
<li>[[Getting_started#Connecting_to_the_DX_cluster|Connecting to the DX cluster]]
<li>[[Getting_started#The bandmap and other windows|The bandmap and other windows]]
<li>[[Getting_started#After the contest|After the contest]]
<li>[[Getting_started#Tips and tricks|Tips and tricks]]
</ol>
<li> '''[[Main_Window|Main window]]'''
<ol>
<li>[[Main_Window#Main_Window|Main window]]
<li>[[Main_Window#Toolbar|Toolbar]]
<li>[[Main_Window#Main_Window_Logging|Logging]]
<li>[[Main_Window#Main_Window_Options|Options]]
<li>[[Main_Window#Main_Window_Color_Options|Color options]]
<li>[[Main_Window#SO2R.2FV_Classic|Classic SO2R/V]]
<li>[[Main_Window#SO2R.2FV_Side_by_Side|Side-by-side SO2R/V]]
</ol>
<li> '''[[Contest configuration|Contest configuration]]'''
<ol>
<li>[[Contest configuration#The_contest_configuration_panel|The contest configuration panel]]
<li>[[Contest configuration#Contest_irregularities|Contest irregularities]]
<li>[[Contest_configuration#Contest_definition_and_support_files|Contest definition and support files]]
<li>[[Contest configuration#Macro_commands_and_special_characters|Macro commands and special characters]]
<li>[[Contest configuration#Supported_contests|Supported contests]]
<li>[http://dxlog.net/sw/contestlist.php Supported contests - Live list]
</ol>
<li> '''[[Keyboard_and_text_functions|Keyboard and text functions]]'''
<ol>
<li>[[Keyboard_and_text_functions#Keyboard_functions|Keyboard functions]]
<li>[[Keyboard_and_text_functions#Text_commands|Text commands]]
</ol>
<li> '''[[Menu|Menu options]]'''
<ol>
<li>[[Menu_File#File|File]]
<li>[[Menu_Edit#Edit|Edit]]
<li>[[Menu_Operating#Operating|Operating]]
<li>[[Menu_Commands#Commands|Commands]]
<li>[[Menu_Messages#Messages|Messages]]
<li>[[Menu_Tools#Tools|Tools]]
<li>[[Menu_Options#Options|Options]]
<li>[[Menu_Windows#Windows|Windows]]
<li>[[Menu_Custom#Custom|Custom]]
<li>[[Menu_Help#Help|Help]]
</ol>
<li> '''[[DXLog.net.DXC|DX cluster client - DXLog.net (Cluster)]]'''
<ol>
<li>[[DXLog.net.DXC#Program|Program]]
<li>[[DXLog.net.DXC#Setup|Setup]]
<li>[[DXLog.net.DXC#Operation|Operation]]
</ol>
<li> '''[[Radios and Peripherals|Notes on supported radios and peripherals]]'''
<ol>
<li>[[Radios and Peripherals#Elecraft|Elecraft]]
<li>[[Radios and Peripherals#FlexRadio|FlexRadio]]
<li>[[Radios and Peripherals#ICOM|ICOM]]
<li>[[Radios and Peripherals#Kenwood|Kenwood]]
<li>[[Radios and Peripherals#Lab599|Lab599]]
<li>[[Radios and Peripherals#microHAM|microHAM]]
<li>[[Radios_and_Peripherals#QRP_Labs|QRP Labs]]
<li>[[Radios and Peripherals#Ten-Tec|Ten-Tec]]
<li>[[Radios and Peripherals#Yaesu|Yaesu]]
<li>[[Radios_and_Peripherals#YCCC_SO2R_Mini|YCCC SO2R Mini]]
</ol>
<li> '''[[Additional Information|Additional information]]'''
<ol>
<li>[[Additional_Information#Using_alternative_configurations|Using alternative configurations]]
<li>[[Additional_Information#Using_a_number_server|Using a number server]]
<li>[[Additional Information#Networking over internet|Networking over internet]]
<li>[[Additional Information#Real time upload to Club Log Live Stream|Club Log Live Stream]]
<li>[[Additional Information#Diversity reception|Diversity reception]]
<li>[[Additional Information#UDP broadcast|UDP broadcast]]
<li>[[Additional Information#SDR integration|SDR integration]]
<li>[[Additional Information#Time synchronization|Time synchronization]]
<li>[[Additional Information#Disabling_USB_power_management|USB power management]]
<li>[[Additional_Information#Interlock_and_inband_operation|Interlock and inband operation]]
<li>[[Additional_Information#Connecting_a_footswitch|Connecting a footswitch]]
<li>[[Additional_Information#Support_for_CC_Cluster|Support for CC Cluster]]
<li>[[Additional_Information#Support_for_AR_Cluster_6|Support for AR Cluster 6]]
<li>[[Additional_Information#Support_for_DXSpider|Support for DXSpider]]
<li>[[Additional_Information#Support_for_N2WQ_Cluster|Support for N2WQ Cluster]]
<li>[[Additional_Information#Interacting_with_WSJT-X|Interacting with WSJT-X]]
<li>[[Additional_Information#Using_Winkey_FSK|Using Winkey FSK]]
<li>[[Additional_Information#Interfacing_with_LogHX|Interfacing with LogHX]]
<li>[[Additional_Information#Self-spotting|Self-spotting]]
<li>[[Additional_Information#DXpedition_use|DXpedition use]]
<li>[[Additional_Information#Beacon_spots_on_DX_cluster|Beacon spots on DX cluster]]
</ol>
<li> '''[[Contest_definition|Contest definition]]'''
<ol>
<li>[[Contest_definition#Introduction|Introduction]]
<li>[[Contest_definition#File_structure|File structure]]
<li>[[Contest_definition#Regular_expressions|Regular expressions]]
<li>[[Contest_definition#Functions_and_FX_expressions|Functions and FX expressions]]
<li>[[Contest_definition#Custom multiplier lists|Custom multiplier lists]]
<li>[[Contest_definition#General_contest_description_keys|General contest description keys]]
<li>[[Contest_definition#Contest_configuration_panel_control_keys|Contest configuration panel control keys]]
<li>[[Contest_definition#Cabrillo_export_keys|Cabrillo export keys]]
<li>[[Contest_definition#Band_and_mode_keys|Band and mode keys]]
<li>[[Contest_definition#QSO entry field definition keys|QSO entry field definition keys]]
<li>[[Contest_definition#Default_message_keys|Default message keys]]
<li>[[Contest_definition#Additional_configuration_keys|Additional configuration keys]]
<li>[[Contest_definition#Less_obvious_constructs|Less obvious constructs]]
</ol>
<li> '''[[Scripting|C# scripting]]'''
<ol>
<li>[[Scripting#Introduction_to_C#|Introduction to C#]]
<li>[[Scripting#C#_script_structure|C# script structure]]
<li>[[Scripting#Example_scripts|Example scripts]]
<li>[[Scripting#Custom_Forms|Custom forms]]
</ol>
|style="vertical-align:top;"|
|}

Main Page

2026-04-02T16:34:48Z

Sm7iun:

__NOTOC__
{|width=100%
| style="vertical-align:top;" colspan=2|
{{Main Page header}}
|-
|width=70% |
<ol type="I">
<li>'''[[Introduction]]'''
<ol>
<li>[[Introduction#Reasons for chosing DXlog|Reasons for chosing DXLog]]
<li>[[Introduction#History|History]]
<li>[[Introduction#Authors and Contributors|Authors and Contributors]]
</ol>
<li> '''[[Installation|Installation]]'''
<ol>
<li>[[Installation#Download_the_software|Download the software]]
<li>[[Installation#Prerequisites|Prerequisites]]
<li>[[Installation#Install_the_software|Installing DXLog]]
<li>[[Installation#Installing_intermediate_releases|Installing intermediate releases]]
<li>[[Installation#Installing_an_older_release|Installing an older release]]
<li>[[Installation#Resetting_DXLog_to_factory_settings|Resetting all settings]]
</ol>
<li> '''[[Getting_started|Getting started]]'''
<ol>
<li>[[Getting_started#Reasons for choosing DXLog|Reasons for choosing DXLog]]
<li>[[Getting_started#User interface|User interface]]
<li>[[Getting_started#Creating a log file|Creating a log file]]
<li>[[Getting_started#Controlling the radio|Controlling the radio]]
<li>[[Getting_started#Databases|Databases]]
<li>[[Getting_started#Operating techniques|Operating techniques]]
<li>[[Getting_started#Standard messages|Standard messages]]
<li>[[Getting_started#Voice_memory_playback|Voice memory playback]]
<li>[[Getting_started#Useful settings|Useful settings]]
<li>[[Getting_started#ESM|ESM]]
<li>[[Getting_started#Connecting_to_the_DX_cluster|Connecting to the DX cluster]]
<li>[[Getting_started#The bandmap and other windows|The bandmap and other windows]]
<li>[[Getting_started#After the contest|After the contest]]
<li>[[Getting_started#Tips and tricks|Tips and tricks]]
</ol>
<li> '''[[Main_Window|Main window]]'''
<ol>
<li>[[Main_Window#Main_Window|Main window]]
<li>[[Main_Window#Toolbar|Toolbar]]
<li>[[Main_Window#Main_Window_Logging|Logging]]
<li>[[Main_Window#Main_Window_Options|Options]]
<li>[[Main_Window#Main_Window_Color_Options|Color options]]
<li>[[Main_Window#SO2R.2FV_Classic|Classic SO2R/V]]
<li>[[Main_Window#SO2R.2FV_Side_by_Side|Side-by-side SO2R/V]]
</ol>
<li> '''[[Contest configuration|Contest configuration]]'''
<ol>
<li>[[Contest configuration#The_contest_configuration_panel|The contest configuration panel]]
<li>[[Contest configuration#Contest_irregularities|Contest irregularities]]
<li>[[Contest_configuration#Contest_definition_and_support_files|Contest definition and support files]]
<li>[[Contest configuration#Macro_commands_and_special_characters|Macro commands and special characters]]
<li>[[Contest configuration#Supported_contests|Supported contests]]
<li>[http://dxlog.net/sw/contestlist.php Supported contests - Live list]
</ol>
<li> '''[[Keyboard_and_text_functions|Keyboard and text functions]]'''
<ol>
<li>[[Keyboard_and_text_functions#Keyboard_functions|Keyboard functions]]
<li>[[Keyboard_and_text_functions#Text_commands|Text commands]]
</ol>
<li> '''[[Menu|Menu options]]'''
<ol>
<li>[[Menu_File#File|File]]
<li>[[Menu_Edit#Edit|Edit]]
<li>[[Menu_Operating#Operating|Operating]]
<li>[[Menu_Commands#Commands|Commands]]
<li>[[Menu_Messages#Messages|Messages]]
<li>[[Menu_Tools#Tools|Tools]]
<li>[[Menu_Options#Options|Options]]
<li>[[Menu_Windows#Windows|Windows]]
<li>[[Menu_Custom#Custom|Custom]]
<li>[[Menu_Help#Help|Help]]
</ol>
<li> '''[[DXLog.net.DXC|DX cluster client - DXLog.net (Cluster)]]'''
<ol>
<li>[[DXLog.net.DXC#Program|Program]]
<li>[[DXLog.net.DXC#Setup|Setup]]
<li>[[DXLog.net.DXC#Operation|Operation]]
</ol>
<li> '''[[Radios and Peripherals|Notes on supported radios and peripherals]]'''
<ol>
<li>[[Radios and Peripherals#Elecraft|Elecraft]]
<li>[[Radios and Peripherals#FlexRadio|FlexRadio]]
<li>[[Radios and Peripherals#ICOM|ICOM]]
<li>[[Radios and Peripherals#Kenwood|Kenwood]]
<li>[[Radios and Peripherals#Lab599|Lab599]]
<li>[[Radios and Peripherals#microHAM|microHAM]]
<li>[[Radios_and_Peripherals#QRP_Labs|QRP Labs]]
<li>[[Radios and Peripherals#Ten-Tec|Ten-Tec]]
<li>[[Radios and Peripherals#Yaesu|Yaesu]]
<li>[[Radios_and_Peripherals#YCCC_SO2R_Mini|YCCC SO2R Mini]]
</ol>
<li> '''[[Additional Information|Additional information]]'''
<ol>
<li>[[Additional_Information#Using_alternative_configurations|Using alternative configurations]]
<li>[[Additional_Information#Using_a_number_server|Using a number server]]
<li>[[Additional Information#Networking over internet|Networking over internet]]
<li>[[Additional Information#Real time upload to Club Log Live Stream|Club Log Live Stream]]
<li>[[Additional Information#Diversity reception|Diversity reception]]
<li>[[Additional Information#UDP broadcast|UDP broadcast]]
<li>[[Additional Information#SDR integration|SDR integration]]
<li>[[Additional Information#Time synchronization|Time synchronization]]
<li>[[Additional Information#Disabling_USB_power_management|USB power management]]
<li>[[Additional_Information#Interlock_and_inband_operation|Interlock and inband operation]]
<li>[[Additional_Information#Connecting_a_footswitch|Connecting a footswitch]]
<li>[[Additional_Information#Support_for_CC_Cluster|Support for CC Cluster]]
<li>[[Additional_Information#Support_for_AR_Cluster_6|Support for AR Cluster 6]]
<li>[[Additional_Information#Support_for_DXSpider|Support for DXSpider]]
<li>[[Additional_Information#Support_for_N2WQ_Cluster|Support for N2WQ Cluster]]
<li>[[Additional_Information#Interacting_with_WSJT-X|Interacting with WSJT-X]]
<li>[[Additional_Information#Using_Winkey_FSK|Using Winkey FSK]]
<li>[[Additional_Information#Interfacing_with_LogHX|Interfacing with LogHX]]
<li>[[Additional_Information#Self-spotting|Self-spotting]]
<li>[[Additional_Information#DXpedition_use|DXpedition use]]
<li>[[Additional_Information#Beacon_spots_on_DX_cluster|Beacon spots on DX cluster]]
</ol>
<li> '''[[Contest_definition|Contest definition]]'''
<ol>
<li>[[Contest_definition#Introduction|Introduction]]
<li>[[Contest_definition#File_structure|File structure]]
<li>[[Contest_definition#Regular_expressions|Regular expressions]]
<li>[[Contest_definition#Functions_and_FX_expressions|Functions and FX expressions]]
<li>[[Contest_definition#Custom multiplier lists|Custom multiplier lists]]
<li>[[Contest_definition#General_contest_description_keys|General contest description keys]]
<li>[[Contest_definition#Contest_configuration_panel_control_keys|Contest configuration panel control keys]]
<li>[[Contest_definition#Cabrillo_export_keys|Cabrillo export keys]]
<li>[[Contest_definition#Band_and_mode_keys|Band and mode keys]]
<li>[[Contest_definition#QSO entry field definition keys|QSO entry field definition keys]]
<li>[[Contest_definition#Default_message_keys|Default message keys]]
<li>[[Contest_definition#Additional_configuration_keys|Additional configuration keys]]
<li>[[Contest_definition#Less_obvious_constructs|Less obvious constructs]]
</ol>
<li> '''[[Scripting|C# scripting]]'''
<ol>
<li>[[Scripting#Introduction_to_C#|Introduction to C#]]
<li>[[Scripting#C#_script_structure|C# script structure]]
<li>[[Scripting#Example_scripts|Example scripts]]
<li>[[Scripting#Custom_Forms|Custom forms]]
</ol>
|style="vertical-align:top;"|
|}

Main Page

2026-04-02T16:34:27Z

Sm7iun:

__NOTOC__
{|width=100%
| style="vertical-align:top;" colspan=2|
{{Main Page header}}
|-
|width=70% |
<ol type="I">
<li>'''[[Introduction]]'''
<ol>
<li>[[Introduction#Reasons for chosing DXlog|Reasons for chosing DXLog]]
<li>[[Introduction#History|History]]
<li>[[Introduction#Authors and Contributors|Authors and Contributors]]
</ol>
<li> '''[[Installation|Installation]]'''
<ol>
<li>[[Installation#Download_the_software|Download the software]]
<li>[[Installation#Prerequisites|Prerequisites]]
<li>[[Installation#Install_the_software|Installing DXLog]]
<li>[[Installation#Installing_intermediate_releases|Installing intermediate releases]]
<li>[[Installation#Installing_an_older_release|Installing an older release]]
<li>[[Installation#Resetting_DXLog_to_factory_settings|Resetting DXLog to factory settings]]
</ol>
<li> '''[[Getting_started|Getting started]]'''
<ol>
<li>[[Getting_started#Reasons for choosing DXLog|Reasons for choosing DXLog]]
<li>[[Getting_started#User interface|User interface]]
<li>[[Getting_started#Creating a log file|Creating a log file]]
<li>[[Getting_started#Controlling the radio|Controlling the radio]]
<li>[[Getting_started#Databases|Databases]]
<li>[[Getting_started#Operating techniques|Operating techniques]]
<li>[[Getting_started#Standard messages|Standard messages]]
<li>[[Getting_started#Voice_memory_playback|Voice memory playback]]
<li>[[Getting_started#Useful settings|Useful settings]]
<li>[[Getting_started#ESM|ESM]]
<li>[[Getting_started#Connecting_to_the_DX_cluster|Connecting to the DX cluster]]
<li>[[Getting_started#The bandmap and other windows|The bandmap and other windows]]
<li>[[Getting_started#After the contest|After the contest]]
<li>[[Getting_started#Tips and tricks|Tips and tricks]]
</ol>
<li> '''[[Main_Window|Main window]]'''
<ol>
<li>[[Main_Window#Main_Window|Main window]]
<li>[[Main_Window#Toolbar|Toolbar]]
<li>[[Main_Window#Main_Window_Logging|Logging]]
<li>[[Main_Window#Main_Window_Options|Options]]
<li>[[Main_Window#Main_Window_Color_Options|Color options]]
<li>[[Main_Window#SO2R.2FV_Classic|Classic SO2R/V]]
<li>[[Main_Window#SO2R.2FV_Side_by_Side|Side-by-side SO2R/V]]
</ol>
<li> '''[[Contest configuration|Contest configuration]]'''
<ol>
<li>[[Contest configuration#The_contest_configuration_panel|The contest configuration panel]]
<li>[[Contest configuration#Contest_irregularities|Contest irregularities]]
<li>[[Contest_configuration#Contest_definition_and_support_files|Contest definition and support files]]
<li>[[Contest configuration#Macro_commands_and_special_characters|Macro commands and special characters]]
<li>[[Contest configuration#Supported_contests|Supported contests]]
<li>[http://dxlog.net/sw/contestlist.php Supported contests - Live list]
</ol>
<li> '''[[Keyboard_and_text_functions|Keyboard and text functions]]'''
<ol>
<li>[[Keyboard_and_text_functions#Keyboard_functions|Keyboard functions]]
<li>[[Keyboard_and_text_functions#Text_commands|Text commands]]
</ol>
<li> '''[[Menu|Menu options]]'''
<ol>
<li>[[Menu_File#File|File]]
<li>[[Menu_Edit#Edit|Edit]]
<li>[[Menu_Operating#Operating|Operating]]
<li>[[Menu_Commands#Commands|Commands]]
<li>[[Menu_Messages#Messages|Messages]]
<li>[[Menu_Tools#Tools|Tools]]
<li>[[Menu_Options#Options|Options]]
<li>[[Menu_Windows#Windows|Windows]]
<li>[[Menu_Custom#Custom|Custom]]
<li>[[Menu_Help#Help|Help]]
</ol>
<li> '''[[DXLog.net.DXC|DX cluster client - DXLog.net (Cluster)]]'''
<ol>
<li>[[DXLog.net.DXC#Program|Program]]
<li>[[DXLog.net.DXC#Setup|Setup]]
<li>[[DXLog.net.DXC#Operation|Operation]]
</ol>
<li> '''[[Radios and Peripherals|Notes on supported radios and peripherals]]'''
<ol>
<li>[[Radios and Peripherals#Elecraft|Elecraft]]
<li>[[Radios and Peripherals#FlexRadio|FlexRadio]]
<li>[[Radios and Peripherals#ICOM|ICOM]]
<li>[[Radios and Peripherals#Kenwood|Kenwood]]
<li>[[Radios and Peripherals#Lab599|Lab599]]
<li>[[Radios and Peripherals#microHAM|microHAM]]
<li>[[Radios_and_Peripherals#QRP_Labs|QRP Labs]]
<li>[[Radios and Peripherals#Ten-Tec|Ten-Tec]]
<li>[[Radios and Peripherals#Yaesu|Yaesu]]
<li>[[Radios_and_Peripherals#YCCC_SO2R_Mini|YCCC SO2R Mini]]
</ol>
<li> '''[[Additional Information|Additional information]]'''
<ol>
<li>[[Additional_Information#Using_alternative_configurations|Using alternative configurations]]
<li>[[Additional_Information#Using_a_number_server|Using a number server]]
<li>[[Additional Information#Networking over internet|Networking over internet]]
<li>[[Additional Information#Real time upload to Club Log Live Stream|Club Log Live Stream]]
<li>[[Additional Information#Diversity reception|Diversity reception]]
<li>[[Additional Information#UDP broadcast|UDP broadcast]]
<li>[[Additional Information#SDR integration|SDR integration]]
<li>[[Additional Information#Time synchronization|Time synchronization]]
<li>[[Additional Information#Disabling_USB_power_management|USB power management]]
<li>[[Additional_Information#Interlock_and_inband_operation|Interlock and inband operation]]
<li>[[Additional_Information#Connecting_a_footswitch|Connecting a footswitch]]
<li>[[Additional_Information#Support_for_CC_Cluster|Support for CC Cluster]]
<li>[[Additional_Information#Support_for_AR_Cluster_6|Support for AR Cluster 6]]
<li>[[Additional_Information#Support_for_DXSpider|Support for DXSpider]]
<li>[[Additional_Information#Support_for_N2WQ_Cluster|Support for N2WQ Cluster]]
<li>[[Additional_Information#Interacting_with_WSJT-X|Interacting with WSJT-X]]
<li>[[Additional_Information#Using_Winkey_FSK|Using Winkey FSK]]
<li>[[Additional_Information#Interfacing_with_LogHX|Interfacing with LogHX]]
<li>[[Additional_Information#Self-spotting|Self-spotting]]
<li>[[Additional_Information#DXpedition_use|DXpedition use]]
<li>[[Additional_Information#Beacon_spots_on_DX_cluster|Beacon spots on DX cluster]]
</ol>
<li> '''[[Contest_definition|Contest definition]]'''
<ol>
<li>[[Contest_definition#Introduction|Introduction]]
<li>[[Contest_definition#File_structure|File structure]]
<li>[[Contest_definition#Regular_expressions|Regular expressions]]
<li>[[Contest_definition#Functions_and_FX_expressions|Functions and FX expressions]]
<li>[[Contest_definition#Custom multiplier lists|Custom multiplier lists]]
<li>[[Contest_definition#General_contest_description_keys|General contest description keys]]
<li>[[Contest_definition#Contest_configuration_panel_control_keys|Contest configuration panel control keys]]
<li>[[Contest_definition#Cabrillo_export_keys|Cabrillo export keys]]
<li>[[Contest_definition#Band_and_mode_keys|Band and mode keys]]
<li>[[Contest_definition#QSO entry field definition keys|QSO entry field definition keys]]
<li>[[Contest_definition#Default_message_keys|Default message keys]]
<li>[[Contest_definition#Additional_configuration_keys|Additional configuration keys]]
<li>[[Contest_definition#Less_obvious_constructs|Less obvious constructs]]
</ol>
<li> '''[[Scripting|C# scripting]]'''
<ol>
<li>[[Scripting#Introduction_to_C#|Introduction to C#]]
<li>[[Scripting#C#_script_structure|C# script structure]]
<li>[[Scripting#Example_scripts|Example scripts]]
<li>[[Scripting#Custom_Forms|Custom forms]]
</ol>
|style="vertical-align:top;"|
|}

Main Page

2026-04-02T16:04:37Z

Sm7iun:

Main Page

2026-04-02T16:03:55Z

Sm7iun:

__NOTOC__
{|width=100%
| style="vertical-align:top;" colspan=2|
{{Main Page header}}
|-
|width=70% |
<ol type="I">
<li>'''[[Introduction]]'''
<ol>
<li>[[Introduction#Reasons for chosing DXlog|Reasons for chosing DXLog]]
<li>[[Introduction#History|History]]
<li>[[Introduction#Authors and Contributors|Authors and Contributors]]
</ol>
<li> '''[[Installation|Installation]]'''
<ol>
<li>[[Installation#Download_the_software|Download the software]]
<li>[[Installation#Prerequisites|Prerequisites]]
<li>[[Installation#Install_the_software|Installing DXLog]]
<li>[[Installation#Installing_intermediate_releases|Installing intermediate releases]]
<li>[[Installation#Installing_older_releases|Installing older releases]]
<li>[[Installation#Resetting_DXLog_to_factory_settings|Resetting DXLog]]
</ol>
<li> '''[[Getting_started|Getting started]]'''
<ol>
<li>[[Getting_started#Reasons for choosing DXLog|Reasons for choosing DXLog]]
<li>[[Getting_started#User interface|User interface]]
<li>[[Getting_started#Creating a log file|Creating a log file]]
<li>[[Getting_started#Controlling the radio|Controlling the radio]]
<li>[[Getting_started#Databases|Databases]]
<li>[[Getting_started#Operating techniques|Operating techniques]]
<li>[[Getting_started#Standard messages|Standard messages]]
<li>[[Getting_started#Voice_memory_playback|Voice memory playback]]
<li>[[Getting_started#Useful settings|Useful settings]]
<li>[[Getting_started#ESM|ESM]]
<li>[[Getting_started#Connecting_to_the_DX_cluster|Connecting to the DX cluster]]
<li>[[Getting_started#The bandmap and other windows|The bandmap and other windows]]
<li>[[Getting_started#After the contest|After the contest]]
<li>[[Getting_started#Tips and tricks|Tips and tricks]]
</ol>
<li> '''[[Main_Window|Main window]]'''
<ol>
<li>[[Main_Window#Main_Window|Main window]]
<li>[[Main_Window#Toolbar|Toolbar]]
<li>[[Main_Window#Main_Window_Logging|Logging]]
<li>[[Main_Window#Main_Window_Options|Options]]
<li>[[Main_Window#Main_Window_Color_Options|Color options]]
<li>[[Main_Window#SO2R.2FV_Classic|Classic SO2R/V]]
<li>[[Main_Window#SO2R.2FV_Side_by_Side|Side-by-side SO2R/V]]
</ol>
<li> '''[[Contest configuration|Contest configuration]]'''
<ol>
<li>[[Contest configuration#The_contest_configuration_panel|The contest configuration panel]]
<li>[[Contest configuration#Contest_irregularities|Contest irregularities]]
<li>[[Contest_configuration#Contest_definition_and_support_files|Contest definition and support files]]
<li>[[Contest configuration#Macro_commands_and_special_characters|Macro commands and special characters]]
<li>[[Contest configuration#Supported_contests|Supported contests]]
<li>[http://dxlog.net/sw/contestlist.php Supported contests - Live list]
</ol>
<li> '''[[Keyboard_and_text_functions|Keyboard and text functions]]'''
<ol>
<li>[[Keyboard_and_text_functions#Keyboard_functions|Keyboard functions]]
<li>[[Keyboard_and_text_functions#Text_commands|Text commands]]
</ol>
<li> '''[[Menu|Menu options]]'''
<ol>
<li>[[Menu_File#File|File]]
<li>[[Menu_Edit#Edit|Edit]]
<li>[[Menu_Operating#Operating|Operating]]
<li>[[Menu_Commands#Commands|Commands]]
<li>[[Menu_Messages#Messages|Messages]]
<li>[[Menu_Tools#Tools|Tools]]
<li>[[Menu_Options#Options|Options]]
<li>[[Menu_Windows#Windows|Windows]]
<li>[[Menu_Custom#Custom|Custom]]
<li>[[Menu_Help#Help|Help]]
</ol>
<li> '''[[DXLog.net.DXC|DX cluster client - DXLog.net (Cluster)]]'''
<ol>
<li>[[DXLog.net.DXC#Program|Program]]
<li>[[DXLog.net.DXC#Setup|Setup]]
<li>[[DXLog.net.DXC#Operation|Operation]]
</ol>
<li> '''[[Radios and Peripherals|Notes on supported radios and peripherals]]'''
<ol>
<li>[[Radios and Peripherals#Elecraft|Elecraft]]
<li>[[Radios and Peripherals#FlexRadio|FlexRadio]]
<li>[[Radios and Peripherals#ICOM|ICOM]]
<li>[[Radios and Peripherals#Kenwood|Kenwood]]
<li>[[Radios and Peripherals#Lab599|Lab599]]
<li>[[Radios and Peripherals#microHAM|microHAM]]
<li>[[Radios_and_Peripherals#QRP_Labs|QRP Labs]]
<li>[[Radios and Peripherals#Ten-Tec|Ten-Tec]]
<li>[[Radios and Peripherals#Yaesu|Yaesu]]
<li>[[Radios_and_Peripherals#YCCC_SO2R_Mini|YCCC SO2R Mini]]
</ol>
<li> '''[[Additional Information|Additional information]]'''
<ol>
<li>[[Additional_Information#Using_alternative_configurations|Using alternative configurations]]
<li>[[Additional_Information#Using_a_number_server|Using a number server]]
<li>[[Additional Information#Networking over internet|Networking over internet]]
<li>[[Additional Information#Real time upload to Club Log Live Stream|Club Log Live Stream]]
<li>[[Additional Information#Diversity reception|Diversity reception]]
<li>[[Additional Information#UDP broadcast|UDP broadcast]]
<li>[[Additional Information#SDR integration|SDR integration]]
<li>[[Additional Information#Time synchronization|Time synchronization]]
<li>[[Additional Information#Disabling_USB_power_management|USB power management]]
<li>[[Additional_Information#Interlock_and_inband_operation|Interlock and inband operation]]
<li>[[Additional_Information#Connecting_a_footswitch|Connecting a footswitch]]
<li>[[Additional_Information#Support_for_CC_Cluster|Support for CC Cluster]]
<li>[[Additional_Information#Support_for_AR_Cluster_6|Support for AR Cluster 6]]
<li>[[Additional_Information#Support_for_DXSpider|Support for DXSpider]]
<li>[[Additional_Information#Support_for_N2WQ_Cluster|Support for N2WQ Cluster]]
<li>[[Additional_Information#Interacting_with_WSJT-X|Interacting with WSJT-X]]
<li>[[Additional_Information#Using_Winkey_FSK|Using Winkey FSK]]
<li>[[Additional_Information#Interfacing_with_LogHX|Interfacing with LogHX]]
<li>[[Additional_Information#Self-spotting|Self-spotting]]
<li>[[Additional_Information#DXpedition_use|DXpedition use]]
<li>[[Additional_Information#Beacon_spots_on_DX_cluster|Beacon spots on DX cluster]]
</ol>
<li> '''[[Contest_definition|Contest definition]]'''
<ol>
<li>[[Contest_definition#Introduction|Introduction]]
<li>[[Contest_definition#File_structure|File structure]]
<li>[[Contest_definition#Regular_expressions|Regular expressions]]
<li>[[Contest_definition#Functions_and_FX_expressions|Functions and FX expressions]]
<li>[[Contest_definition#Custom multiplier lists|Custom multiplier lists]]
<li>[[Contest_definition#General_contest_description_keys|General contest description keys]]
<li>[[Contest_definition#Contest_configuration_panel_control_keys|Contest configuration panel control keys]]
<li>[[Contest_definition#Cabrillo_export_keys|Cabrillo export keys]]
<li>[[Contest_definition#Band_and_mode_keys|Band and mode keys]]
<li>[[Contest_definition#QSO entry field definition keys|QSO entry field definition keys]]
<li>[[Contest_definition#Default_message_keys|Default message keys]]
<li>[[Contest_definition#Additional_configuration_keys|Additional configuration keys]]
<li>[[Contest_definition#Less_obvious_constructs|Less obvious constructs]]
</ol>
<li> '''[[Scripting|C# scripting]]'''
<ol>
<li>[[Scripting#Introduction_to_C#|Introduction to C#]]
<li>[[Scripting#C#_script_structure|C# script structure]]
<li>[[Scripting#Example_scripts|Example scripts]]
<li>[[Scripting#Custom_Forms|Custom forms]]
</ol>
|style="vertical-align:top;"|
|}

Installation

2026-04-02T16:03:23Z

Sm7iun: /* Installing an older release */

==Download the software==

DXLog.net is available for download at http://www.dxlog.net/sw

DXLog is completely free of charge. Operational costs are generously covered by K1LZ and K1XM. 
The development team does not accept donations at this time.

DXLog does not have any formal minimum requirements but the general 
recommendations are Windows 11 and 4Gbyte of RAM.

==Prerequisites==

DXLog.net is written using in C# and compiled for Microsoft .NET Framework 4.8.

It runs on any Windows version with Microsoft .NET Framework version 4.8 but 
the development team only verifies DXLog on Windows 11.

Due to the need to support SSL v1.2 for secure communication with live scoreboards and to download 
essential data bases like Super Check Partial, Windows XP is no longer supported.

Before installation of DXLog.net, you need to verify that you have Microsoft .NET Framework 4.8 installed on your PC system. 
If you are not sure, you can start DXLog.net installation and the installer will warn you if .NET Framework 4.8 
(or above) is not installed on your PC system. 

Microsoft.NET Framework 4.8 is included in all Windows 10 and Windows 11 installations.

If you plan to use your PC's parallel LPT port for CW keying and other functions, you need to download 
and install the DLPORTIO.DLL driver due to limitations in Windows.
It can be downloaded from https://dxlog.net/sw/files/tools/port95nt.exe

If you plan to use the contest recorder, an MP3 encoder must be installed. See the [[Menu_Windows#Contest_Recorder|Contest recorder section]] for more information.

As of version 2.1.1 DXLog.net is using SQLite database for data storage. 
On some older or custom Windows versions Microsoft Visual C++ 2010 RTM Redistributable Package (x86 version) needs to be installed.

If this package is not found during installation, DXlog.net installer will warn you. 
You can download and install this package from: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=5555 

==Install the software==

DXLog installs in the protected <tt>Program Files</tt> folder on your computer.

When a never version is available, DXLog will prompt you to install it and guide you through the installation.

'''Important:''' The guided installation may cause a false malware alert. The development team is working on a solution.

If the guided upgrade cannot be used or does not work you can manually download the installation package 
(the .MSI file) here https://dxlog.net/sw

You can just install a newer release. There is no need to remove older versions.

'''Important:''' Never modify the files in the installation folder, typically <tt>C:\Program Files\DXLog.net</tt>.

Application configuration files as well as contest and database definitions are copied to a folder in Windows' 
hidden <tt>%AppData%</tt> folder called during the first run of DXLog.net.

'''Important:''' If you need to edit DXLog files, you should only edit these copies.

This hidden folder can be reached via the <code>Files|Open configuration folder</code> menu shortcut, 
the <tt>%AppData%</tt> system variable, or its direct location which is <tt>C:\Users\USERNAME\AppData\Roaming\DXLog.net</tt> 
with <tt>USERNAME</tt> being the active user name on your computer.

'''Important''': To make a completely clean reinstall of DXLog:
* Uninstall DXLog
* Go to the application data folder by entering %appdata% in Windows explorer
* Delete the DXLog.net folder
* Install DXLog

==Installing intermediate releases==

From time to time the development team will make intermediate releases available. 
Such releases may not be of production quality and typically solves a particular problem. 
If you do not suffer from this problem, and are not part of a testing activity you are not 
recommended to install such releases.

Intermediate releases are often referred to as ''devtest'' releases and they are available [[https://dxlog.net/sw/#files%2Fdownload%2Fdevtest here]].

Since the installer may not recognize a public release as newer than recent devtest release, 
you may need to uninstall the devtest release before installing it.

==Installing an older release==

When installing an older release it is '''very important''' to:

* Uninstall DXLog before installing the older release.
* Clear the <tt>%appdata%\DXLog.net\Contest</tt> folder.

==Resetting DXLog to factory settings==

* Go to the application data folder by entering %appdata% in Windows explorer
* Delete (or better, rename) the <tt>DXLog.net</tt> folder
* Start DXLog

Additional Information

2026-04-01T07:10:03Z

Sm7iun: /* Using Piper text-to-speech synthesis */

==Using alternative configurations==

Window positions, coloring and general look and feel is saved in each log file but all other settings such as 
radio control, keying, and networking is saved in a common, contest-independent configuration file.

By default, the configuration file name is <tt>DXLog.net.config</tt> and it is located in the <tt>%appdata%\DXLog.net</tt> configuration folder.

This folder is also reachable via the <code>File|Open configuration folder</code> menu item.

[[image:configfolder.png]]

DXLog can be made to use an alternative configuration file with the command line option <tt>-cfg=<filename></tt>.

A convenient way to use this option is to create a separate Windows desktop shortcut including the command line option 
and give it a meaningful name.

[[image:Desktopshortcut.png]]

The command line option is simply added to the end of the Target text box in the shortcut's properties. 
Double-clicking the icon will start DXLog with the alternative configuration which will also be remembered between sessions. 
In the picture below the target of the shortcut is

[[image:Desktopshortcutconfig.png]]

'''Important:''' If you want to use an alternative configuration, do not just modify the desktop shortcut created at installation 
since this shortcut will be deleted when you upgrade DXLog. Instead make a copy, rename, and add the command line option. 
You should keep the command line option outside the apostrophes, like this

<tt>"C:\Program Files (x86)\DXLog.net\DXLog.net.exe" -cfg=SO2R.config</tt>

==Using a number server==

For contests involving serial numbers you need to secure that the sent number and the (slightly later) 
logged serial numbers are the same. In a straightforward SO1R or SO2V scenario, serial numbers are simply 
chronological but in more complex station configurations such as Multi-single or Multi-2 with inband, and 
advanced SO2R, QSO can be interleaved and requires a central source source of serial numbers together 
with a mechanic to protect an already sent serial number from re-use by another radio.

In DXLog this is achieved with a central number server. A number server can be used either 
by a single instance of DXLog (for SO2R) or by multiple stations on the same LAN.

The use of a number server involves three, natural, steps:

* Activating the server on a single station
* Making sure all stations use it
* Verifying functionality, making sure serial numbers are correctly reserved

The number server is activated in the <code>Options|Configure network</code> panel, described [[Menu_Options#Configure_network|HERE]].

[[image:startnumberserver.png]]

Since the server uses a networking socket, <code>Options|Networking</code> must be enabled '''also''' when 
using a single computer in SO2R. In the case of multiple stations, UDP networking or Client-Server 
networking must also be enabled to transfer the numbers over the LAN. For SO2R, this is however not 
necessary. When using Client-Server networking, a client cannot be number server.

There must only be one number server in a local network and all stations using it must have 
<code>Options|Networking|Use number server</code> checked like in the picture below.

'''Important:''' The number client/server functionality is not very robust. 
If you have stations joining/leaving your network or being rebooted, it is 
best to restart DXLog on all stations to guarantee correct function.

[[image:usenumberserver.png]]

The option <code>Block logging if serial number reservation is unsuccessful</code> can be used as an extra precaution 
but is not necessary in SO2R since the communication with the number server does not leave the computer.

There are three methods for reserving a number from the server:

* Checking <code>Tools|Data entry|Space key reserves serial number</code> and using the space key to reserve serial numbers. This is typically used on phone or when operating "old school" with F-keys.
* Checking <code>Tools|Data entry|Insert and F2 messages reserve serial number</code> and letting DXLog automatically reserve a serial number right before $SERIAL sends it. This is the preferred and most straightforward way for CW and digital.
* Adding the $RESERVENR macro to messages like illustrated below. 

These methods can of course also be combined. 

The $RESERVENR macro is "smart" and will only reserve a serial number if the callsign entry field is not empty and a 
serial number is not already reserved. The same goes for the menu items.

[[image:reservemessages.PNG]]

The sign of a serial number being reserved is that it turns red. It then stays reserved (and red) until the 
QSO is logged or the entry line is cleared with <code>[Alt][W]</code>.

An option that can prove useful is <code>Tools|Data entry|Cancel serial number reservation only if callsign field is empty</code>. 
In the case that you send the exchange and realize you got the other station's callsign call completely wrong, a reflex can be to hit 
<code>[Alt][W]</code> and start typing. If this is your habit, this option will prevent you from releasing the 
already sent serial number, thereby avoiding you the trouble to send a new one to the other station.

[[image:reservednumber.png]]

==Networking over internet==

When, for instance, activating a special event callsign it is possible to network multiple DXLog stations over the internet.

'''Pro tip:''' Consider displaying the callsign, message ID, Message text, etc. fields in the ''Network status'' 
window when operating a distributed station. Also, learn to use the gab <code>[Alt][G]</code> and <code>[Alt][J]</code> function.

===VLAN/VPN Solution===

The most secure way for remote networking is to rely on a VLAN (virtual LAN) software. There are several available such as:

ZeroTier https://www.zerotier.com/ 
FreeLan http://www.freelan.org/ 
Player.me https://player.me/ 
OpenVPN https://openvpn.net/

Each VLAN solutions have their own particular set up which is covered in their respective documentations. 
With a VLAN solution, all DXLog configurations are the same as when operating in a regular LAN however with a few exceptions.

One weakness with connections over the internet (a.k.a. WAN), including VLAN solutions, is that they are prone to packet loss. 
Packet loss is disastrous to DXLog's (or any logger's) "standard" UDP networking.

It is therefore essential to use '''only client/server networking over a VLAN'''. 
'''This also means you should never use interlock over an internet connection unless you use a zero packet loss VPN tunnel.'''

ZeroTier is particularly popular since it is free.

Since DXLog is able to mix TCP (client/server) and UDP (peer-to-peer) networking, a distributed station set up should be configured to rely on TCP 
for the wide-area network and UDP for the local network at each station location. Below you will find the station 
set up for the Swedish HQ station SE9HQ in the 2019 IARU HF Championship. The DXLog.net.DXC cluster client was run 
on SK3W-A which distributed spots to all stations over the network. Inband interlock was also used at the SK3W location.

[[image:SE9HQ-network-eng.png|800px]]

Important to note:

* For the server as well as the main clients, ''Server IP'' should be set to the server's VLAN IP address, '''not''' its LAN address.
* The '''server''' should check both "Act as network server" and "UDP network broadcast for multiple stations".
* The '''main clients''' should check both "Connect to network server" and "UDP network broadcast for multiple stations".
* The '''sub clients''' should check only "UDP networking for multiple stations".
* Interlock (which is UDP-based) over VLAN does not work reliably because of packet loss.
: Therefore, it is important to configure any interlock to '''only''' consider relevant operating positions,
: which all must be local. Use the possibility to only consider named stations for the interlock in the software 
: interlock set up. <code>Options|Networking|Software interlock</code> "Custom station ID(s)"
* For a large set-up with many stations connecting as clients to a central server you may overload the server if you also
: distribute spots via all client-server connections. In this case, check the "No spots via client/server" option
: on all stations and use '''local DX cluster connections''' via UDP at each location.
: '''Important:''' Limitations in Windows networking makes client/server networking unreliable beyond 10 station locations.
* Make sure to check <code>Options->Load contest at startup</code> to avoid opening the wrong log after a restart.
* '''Remote commands are not forwarded''' in the network but are executed in the station where they arrive.
: Thus, to clear all logs, disconnect networking on each main client, execute the remote command CLEARLOGNOW on each main client
: to clear the logs of all sub clients and do not reconnect until the server and all other main clients have done the same.

===Port forwarding Solution===

If you are less worried about competitors or government agencies listening in on your contest data, 
it is possible to route the traffic directly over the internet using port forwarding at the server.

'''Important security notice: This solution is not without risk. It offers no security or authentication. 
Any DXLog station running the same contest configuration, knowing the URL or IP address and IP port of the 
server can connect to the server station. There are no means to disconnect a station by force.'''

Also note the comment about '''remote commands''' in the section above.

With a port forwarding solution, the following must be observed:

* '''Server configuration'''
:* Only one of the stations should be configured as the '''server'''.
:* "Connect to network server" should not be checked on this station and
:: "UDP networking for multiple stations" should only be enabled if it is used to
:: communicate with a cluster client or other stations locally on the same LAN.
:: Either use a central cluster connection (uncheck "No spots via client/server")
:: or use one cluster connection per station location (check "No spots via client/server").
:: If one cluster connection per station location is used, make sure they
:: all use different SSID to prevent disconnects, such as E7HQ-1, E7HQ-2, etc.
:: This will ensure the cluster node regards all connections as having the same callsign
:: which is essential for e.g., correctly receiving own spots.
:* The PC acting as server must be configured for a fixed LAN IP address. This is done
:: either by manually configuring the networking settings in the PC to use a fixed
:: LAN IP address, or by setting up the router in the server's LAN to to always allocate
:: the same IP address to it.
:* The internet connection used by the server PC must ''either'' have a fixed public IP address ''or''
:: use dynamic DNS. Otherwise clients will not be able to reliable connect over the internet.
:* The server's TCP/IP port (e.g., <code>9888</code>) must be forwarded to the server by the server LAN's router.
:: Only TCP traffic should be forwarded. DXLog UDP traffic is not carried well over the internet.

:: [[image:serverconfig.png|600px]]
:: '''Example configuration for server for networking over internet'''

::[[image:portforwarding.png|600px]]
::'''Example of port forwarding UI in router'''

* '''All other stations'''
:* All other PC in the multi-station set up should be set up as clients.
:* Over the internet, "Server:" is either the static, public IP address of the server's internet
:: connection (e.g. <code>5.140.211.42</code>) or the dynamic DNS address (e.g. <code>hq.sm7iun.se</code>).
:: Clients connecting over the internet does not have to enable UDP networking and ''should not''
:: enable a server.
:* A client may connect via UDP if it is on the same LAN as the server ''or'' a "main client".
:: A "main client" is a client that connects to the server using the "Connect to network server" option in
:: the networking set up panel. A "main client" acts as a UDP gateway which means that if
:: several computers on a LAN are part of the same multi station set up but the server is located
:: elsewhere, only one computer in that LAN needs to connect as a client and the rest can use UDP.
:* Software interlock is UDP-based and can only reliably be used locally. Never over the internet.
:: If used, make sure the interlock is explicitly limited to local stations. See above for more details.

::[[image:clientconfig.png|600px]]
::'''Example configuration of client for networking over internet'''

* In a multi-station setting it is recommended to enable
: <code>Options|Networking|Block standard messages if no operator is logged on</code>
* Make sure <code>Options|Enable network</code> is checked.
* It is also a very good idea to check <code>Options|Load contest at startup</code> to reduce the
: risk of the wrong contest log file being loaded by any stations.

==Real time upload to Club Log Live Stream==

'''Important:''' Club Log truncates QSO time to minutes which means that if you mix real time upload 
with manual upload, make sure to check "QSO time in minutes" when creating ADIF export files.

The author of Club Log, Michael Wall, G7VJR, has developed a very powerful agent for real time uploads. 
It works with all the three major loggers, DXLog, N1MM Logger+, and Win-Test.

It can either be used as is, with a command line user interface, or with an optional user interface front end.

Information on how to download and configure it can be found [[https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads HERE]]

The Club Log Gateway can either listen to DXLog's native multi-station networking protocol or to N1MM style XML broadcast.

To use DXLog's networking protocol, make sure the same port (default 9888) is used in the gateway and DXLog 
and that UDP networking is enabled in DXLog. Do not enable QSO broadcast.

Although this works, it is recommended to use N1MM style broadcast since it contains information like logged on operator, etc.

To use this make sure the port (default 12060) is the same in N1MM port setting in the gateway and in the 
QSO broadcast port settings in DXLog's network configuration. Also make sure to se the DXLog port number 
in the gateway is not the same as that used in DXLog to avoid QSO duplication.

Also set:

<code>Options|Broadcast|QSOs</code> 
<code>Options|Broadcast|QSOs</code> 
<code>Options|Broadcast|Use N1MM QSO format</code> 
<code>Options|Broadcast|QSO time in minutes only</code>

'''Important:''' If you are going to also upload exported ADIF files to Club Log, it is important to also 
check "QSO time in minutes" in the ADIF export configuration to avoid creating virtual dupes, since Club 
Log does not know seconds.

==Diversity reception==

Diversity means receiving the same signal through two different receive chains, including antenna. 
With two antennas having different characteristics this can give substantial benefits in receiving 
fading and/or weak signals or separating calls in a large pile-up. Particularly on low bands.

DXLog supports diversity operation on a selected number of radio models.

For the supported radios, diversity operation can be toggled on and off using <code>[Ctrl][-]</code> or <code>[Ctrl][Keypad -]</code>.

If enabled via the radio's controls, DXLog will automatically detect diversity operation and enable 
the necessary mechanics. Diversity operation is indicated by a small DIV icon in the frequency 
counter box for the radio's band map.

'''Yaesu FTDX101D

Yaesu calls this feature "Sync" and it has a dedicated button up and left of the main VFO knob. 
Enabling this will make DXLog update both VFO with the same information when grabbing spots. 
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO. 
Since both VFO are kept on the same frequency, split operation is not supported.

'''ICOM IC-7851 and IC-7610

ICOM calls this feature "Tracking" and it can be enabled either via a menu entry or a long press on the "MAIN/SUB" button. 
Enabling this will make DXLog update both VFO with the same information when grabbing spots. 
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO. 
Since both VFO are kept on the same frequency, split operation is not supported.

'''Elecraft K3/K3S/K4

Elecraft calls this feature by its proper name. It is enabled by a long press on the "Sub" button. 
It should be noted that Elecraft's implementation where the main VFO controls both the main and 
sub receivers allows for split operation, i.e. transmitting on a different frequency using VFO B.

==UDP broadcast==

For interaction with other applications, DXLog can broadcast useful information as 
XML datagrams over UDP. 

There are five types of broadcast messages produced by DXLog:

* QSO information. Sent when logging.
* Radio information. Sent at changes as well as periodically.
* Antenna direction information. Sent when rotor control is invoked.
* Callsign look-up information
* Spots

QSO can be broadcasted in traditional DXLog format or in a more N1MM-like format.

Radio information can report SO2V as a single physical radio or as two physical radios, like N1MM.

There is an option to truncate the broadcasted QSO time to full minutes for better 
interoperability with some online services and software such as MSHV.

In addition, DXLog can also recognize QSY commands from Waterfall Bandmap and log QSO done as well as create 
local spots from decodes broadcasted by WSJT-X and its forks.

The broadcasting of QSO and radio related data is enabled using the <code>Options|Broadcast</code> submenu.

The broadcasting of spots is enabled by checking <code>Options|DX Cluster|Send spots to SmartSDR</code>.

[[image:radiobroadcastenable3.png]]

[[image:sendspotstosmartsdr.png]]

UDP broadcast parameters are configured in the <code>Options|Network configuration</code> panel. 
Please note that up to three ports can be specified for each broadcast, thereby supporting 
multiple receivers of the information.

[[image:Networksettingsbroadcast3.png]]

If you are writing a C# application to make use of these datagrams, there is a very nice online tool 
for creating an object from a sample XML datagram here https://xmltocsharp.azurewebsites.net/ 

In C# parsing is easily done using Linq. One example of XML parsing and deserialization using Linq 
can be found here https://github.com/bjornekelund/ICOMautomagic

===QSO information===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program
|-
| qsoid
| A unique string for this QSO. If this QSO is edited another contactinfo message will be sent with the same qsoid. Note that the qsoid is only unique within one instance of DXLog. If the computer is networked to others running DXLog the different computers may have a different qsoid for the same QSO.
|-
| contestname
| The name of the contest as it would be written to a Cabrillo file.
|-
| timestamp
| The UTC date and time of the QSO.
|-
| mycall
| The callsign of this station.
|-
| band
| The band on which the QSO was made. In MHz with period as decimal separator.
|-
| txfreq
| The frequency on which the QSO was made.
|-
| operator
| The callsign of the operator if the OPON command was used to set it, otherwise blank.
|-
| mode
| The mode used for the QSO.
|-
| call
| The callsign of the station worked.
|-
| countryprefix
| The DXCC country of the station worked.
|-
| wpxprefix
| The WPX prefix of the station worked.
|-
| snt
| The RST sent. This is always included whether or not the contest exchange contains an RST.
|-
| rcv
| The RST received. This is always included whether or not the contest exchange contains an RST.
|-
| nr
| The number sent if the exchange uses a serial number, otherwise the QSO number from this station.
|-
| exch1
| The first element in the contest exchange if any.
|-
| exch2
| The second element in the contest exchange if any.
|-
| exch3
| The third element in the contest exchange if any.
|-
| exch4
| The fourth element in the contest exchange if any.
|-
| xqso
| True if this QSO should not be counted towards the score.
|-
| invalid
| True if this QSO is invalid, for example a DX QSO in a domestic contest.
|-
| duplicate
| True if this QSO is a dupe (the station has previously been worked).
|-
| rule10broken
| True if this QSO breaks the 10 minute or similar rule. Note that a QSO may not break the 10 minute rule when it is logged but may later if another QSO is edited. This may not cause a broadcast.
|-
| azimuth
| The approximate direction of the station worked, in degrees.
|-
| distance
| The approximate distance of the station worked, in kilometers.
|-
| stationid
| The station ID of the station which made the QSO.
|-
| stationqso
| A unique QSO ID generated by the logging station. The combination of stationid and stationqso forms a unique identifier for the QSO.
|-
| stationtype
| The type of station - R for run, R1 for run 1 etc.
|-
| local
| True if this broadcast is due to this QSO being logged or edited on this computer.
|-
| runqso
| True if QSO logged in Run, false if S&P, and empty if unknown. '''Important:''' Only valid when local is True.
|-
| mult1
| The name of the multiplier if this station is a new multipllier, empty otherwise.
|-
| mult2
| The name of the multiplier if this station is a new multiplier, emtpy otherwise.
|-
| mult3
| The name of the multiplier if this station is a new multiplier, empty otherwise.
|-
| points
| The logged points for the QSO.
|-
| period
| The number of the operating period.
|-
| guid
| The GUID in hex format.
|-
| newqso
| True if a new QSO, False if this message is an update to an existing QSO.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<contactinfo>
<logger>DXLog v2.4.13</logger>
<qsoid>19</qsoid>
<contestname>ARRL-SS-CW</contestname>
<timestamp>2020-01-13 18:28:07</timestamp>
<mycall>SM7IUN</mycall>
<band>3.5</band>
<txfreq>352376</txfreq>
<operator></operator>
<mode>CW</mode>
<call>K4BAI</call>
<countryprefix>K</countryprefix>
<wpxprefix>K4</wpxprefix>
<snt>599</snt>
<rcv>599</rcv>
<nr>19</nr>
<exch1>076</exch1>
<exch2>B</exch2>
<exch3>54</exch3>
<exch4>GA</exch4>
<xqso>False</xqso>
<invalid>False</invalid>
<duplicate>False</duplicate>
<rule10broken>False</rule10broken>
<azimuth>225</azimuth>
<distance>1388</distance>
<stationid>STN1</stationid>
<stationqso>19</stationqso>
<stationtype>R1</stationtype>
<local>True</local>
<runqso>True</local>
<mult1>GA</mult1>
<mult2></mult2>
<mult3></mult3>
<points>3</points>
<period>1</period>
<guid>11223344556677889900aabbccddeeff</newqso>
<newqso>True</newqso>
</contactinfo>
</pre>

Alternative N1MM format

Note that the band name uses the computer's local number format so it may use either comma 
or period as decimal separator. The ID is a number rather than an alphanumeric string.

Also note that IsRunQSO is only valid when IsOriginal is True.

<pre><?xml version="1.0" encoding="utf-8"?>
<contactinfo>
<app>N1MM</app>
<contestname>CWOps</contestname>
<timestamp>2020-01-17 16:43:38</timestamp>
<mycall>SM7IUN</mycall>
<band>3.5</band>
<rxfreq>352519</rxfreq>
<txfreq>352519</txfreq>
<operator></operator>
<mode>CW</mode>
<call>K1XM</call>
<countryprefix>K</countryprefix>
<wpxprefix>K1</wpxprefix>
<stationprefix>K1XM</stationprefix>
<continent>NA</continent>
<snt>599</snt>
<sntnr>5</sntnr>
<rcv>599</rcv>
<misctext></misctext>
<ismultiplier1>1</ismultiplier1>
<ismultiplier2>0</ismultiplier2>
<ismultiplier3>0</ismultiplier3>
<points>l</points>
<radionr>l</radionr>
<run1run2>1<run1run2>
<IsOriginal>False</IsOriginal>
<NetBiosName>DESKTOP-23AB</NetBiosName>
<IsRunQSO>0</IsRunQSO>
<StationName>STATION_B</StationName>
<ID>23</ID>
<IsClaimedQso>true</IsClaimedQso>
</contactinfo>
</pre>

===Radio information===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| The name of the logging program.
|-
| logger
| The name and version of the logging program.
|-
| Station
| The ID of the station.
|-
| RadioNr
| The radio being described.
|-
| Freq
| The receiving frequency.
|-
| TXFreq
| The transmitting frequency
|-
| InactiveFreq
| The frequency of the VFO not receiving.
|-
| Mode
| The reported radio's mode.
|-
| OpCall
| The callsign of the operator if the OPON command was used to set it, otherwise blank.
|-
| mycall
| The callsign of the station.
|-
| IsRunning
| "True" if the station is running, "False" if search and pounce.
|-
| FocusEntry
| The Windows handle for the focused entry window.
|-
| Antenna
| Antenna number.
|-
| Rotors
| Rotators used by selected antenna (not currently used by DXLog).
|-
| FocusRadioNr
| The radio which has keyboard focus. In SO2V with "Report SO2V as two radios" checked, radio 2 is the sub/B VFO.
|-
| IsStereo
| True if headphones are listening to two radios.
|-
| IsSplit
| True if radio is set to split.
|-
| ActiveRadioNr
| The radio which is transmitting, if any.
|-
| Technique
| SO1R, SO2R, SO2R_ADV, or SO2V
|-
| StationType
| Station role: R, M, R1, R2, or R+.
|-
| isTransmitting
| True if a DXLog is transmitting. False if DXLog is not aware of transmission.
|-
| IFFrequency
| Optional element only used with Elecraft K3/K4. Contains the current IF frequency in Hz.
|-
|}

Important note: In SO2V the format differs from some other loggers and is:

: Only physical radio 1 is reported.
: <tt>Freq</tt> and <tt>TXFreq</tt> are the frequency of the currently focused VFO.
: <tt>InactiveFreq</tt> is the frequency of the currently unfocused VFO.
: <tt>ActiveRadio</tt> is always 1.
: <tt>FocusedRadioNr</tt> is 1 when the main/A VFO is focused, 2 otherwise.
: <tt>IsSplit</tt> is always false.

With the option "Report SO2V as two radios" checked, the reporting is similar to some other loggers and is:

: The two VFO are reported as two physical radios.
: <tt>Freq</tt> and <tt>TXFreq</tt> for radio 1 are the frequency of the main/A VFO.
: <tt>Freq</tt> and <tt>TXFreq</tt> for radio 2 are the frequency of the sub/B VFO.
: <tt>InactiveFreq</tt> is the frequency of the other VFO.
: <tt>ActiveRadio</tt> and <tt>FocusedRadioNr</tt> are 1 when the main/A VFO is focused, 2 otherwise.
: <tt>IsSplit</tt> is always false.

Example message:

<pre><?xml version = "1.0"?>
<RadioInfo>
<app>DXLog</app>
<logger>DXLog v2.4.13</logger>
<Station>STN1</Station>
<RadioNr>1</RadioNr>
<Freq>704000</Freq>
<TXFreq>704000</TXFreq>
<InactiveFreq>702500</InactiveFreq>
<Mode>CW</Mode>
<OpCall>K1XM</OpCall>
<mycall>HQ9X</mycall>
<IsRunning>False</IsRunning>
<FocusEntry>591124</FocusEntry>
<Antenna>1</Antenna>
<Rotors>ABC</Rotors>
<FocusRadioNr>1</FocusRadioNr>
<IsStereo>False</IsStereo>
<IsSplit>False</IsSplit>
<ActiveRadioNr>1</ActiveRadioNr>
<Technique>SO2R</Technique>
<StationType>R1</StationType>
<IsTransmitting>False</IsTransmitting>
<IFFrequency>8215000</IFFrequency>
</RadioInfo>
</pre>

===Antenna direction===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program.
|-
| station
| The ID of the station.
|-
| radio
| The radio associated with the rotator.
|-
| go
| True if the rotator should be turned.
|-
| stop
| True if the rotator should be stopped if it is turning.
|-
| azimuth
| The direction to turn the rotator if go is True.
|-
| frequency
| The transmit frequency of the specified radio.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<Rotator>
<logger>DXLog v2.4.13</logger>
<station>STN1</station>
<radio>2</radio>
<go>True</go>
<azimuth>252</azimuth>
<frequency>2800200</frequency>
</Rotator>

</pre>
<pre><?xml version="1.0" encoding="utf-8"?>
<Rotator>
<logger>DXLog v2.4.13</logger>
<station>STN1</station>
<radio>2</radio>
<stop>True</stop>
<frequency>2800200</frequency>
</Rotator>
</pre>

===Callsign lookup===

Sent either when callsign in entry row is changed or when space or tab is pressed.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program.
|-
| contestname
| The name of the contest.
|-
| mycall
| Station's call
|-
| band
| Current band
|-
| txfreq
| Transmitter frequency
|-
| operator
| The call sign of the logged in operator
|-
| mode
| Operating mode
|-
| call
| Call entered in the logging field
|-
| countryprefix
| DXCC entity prefix
|-
| wpxprefix
| WPX prefix
|-
| azimuth
| Short path antenna direction
|-
| distance
| Distance in km
|-
| stationid
| The ID of the station sending the datagram
|-
| stationtype
| The role of the station sending the datagram; R, R1, R2, M, or R+
|-
| period
| Contest period
|-
| reason
| Reason for transmission; SpaceOrTab or CallChanged
|-
|}

Example message:

<pre><?xml version = "1.0"?>
<lookupinfo>
<logger>DXLog v2.4.20</logger>
<contestname>DARC-WAEDC-CW</contestname>
<mycall>K1XM</mycall>
<band>20</band>
<txfreq>1400200</txfreq>
<operator></operator>
<mode>CW</mode>
<call>E7DX</call>
<countryprefix>E7</countryprefix>
<wpxprefix>E7</wpxprefix>
<azimuth>54</azimuth>
<distance>6824</distance>
<stationid></stationid>
<stationtype>R</stationtype>
<period>1</period>
<reason>SpaceOrTab</reason>
</lookupinfo>
</pre>

===Spot===

Sent for every incoming spot from the DX cluster that is valid for the current contest.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| Application sending the message.
|-
| StationName
| The station issuing the broadcast.
|-
| dxcall
| The callsign of the spotted station.
|-
| frequency
| Frequency in kHz with decimal sign of the PC's current locale. (sic)
|-
| spottercall
| The callsign of the spotter. Station name if locally spotted or result of a logging operation.
|-
| timestamp
| Spot time in format yyyy-MM-dd HH:mm:ss
|-
| action
| add or delete.
|-
| mode
| actual or guessed mode of the spot in capitals.
|-
| comment
| The comment section of the spot.
|-
| status
| Spot status. Valid values are "dupe", "double mult", "single mult", and "new qso".
|-
| statuslist
| Same as status
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<spot>
<app>DXLog.net</app>
<StationName>CONTEST-PC</StationName>
<dxcall>E7DX</dxcall>
<frequency>14022.3</frequency>
<spottercall>SM7IUN-#</spottercall>
<timestamp>2O23-07-15 14:29:37</timestamp>
<action>add</action>
<mode>CW</mode>
<comment>CW 31 DB 42 WPM CQ</comment>
<status>single mult</status>
<statuslist>single mult</statuslist>
</spot></pre>

===Broadcast listener===

DXLog also listens for commands over UDP.

Currently only one command is implemented, <code><radio_setfrequency></code>, which is a QSY command.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| Application sending the command
|-
| radionr
| The radio to be changed. In SO2V radio 2 means VFO B. Optional as of DXLog 2.5.20.
|-
| frequency
| Requested frequency. Both period and comma is accepted as decimal separator.
|-
| mousebutton
| Which mouse button was used to create message, if any. Optional.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<radio_setfrequency>
<app>WaterfallBandmap</app>
<radionr>1</radionr>
<frequency>21022.194</frequency>
<mousebutton>Left</mousebutton>
</radio_setfrequency>
</pre>

==SDR integration==

===HDSDR, OmniRig, and microHAM===

''Contributed by Ingo SM5AJV/SE5E''

Until DXLog offers SDR integration there are still ways to get a waterfall/spectrum display with DXLog.

I have integrated the free SDR software [http://www.hdsdr.de/ HDSDR] with DXLog using
[http://www.microham.com Microham Device Router], 
[http://dxatlas.com/OmniRig/ OmniRig]
and [https://www.autohotkey.com/ AutoHotkey].

As illustrated below I place the HDSDR window at the very top of the desktop with DXLog right below.

I share my transceiver's (an Elecraft K3) antenna with the SDR. The receiver antenna signal from my 
K3's RX-ANT OUT is connected to the input of a 3dB power splitter. The two outputs from the splitter 
are connected RX-ANT IN on the K3 and the SDR Receiver antenna input, respectively. On a K3 you 
need to enable the RX-antenna input to make this to work. An additional benefit with this method 
is that the SDR is protected during transmission. It is a widely used method and is e.g. described 
by Bob N6TV in this
[http://dxlog.net/sw/files/utilities/Adding%20an%20SDR%20to%20an%20SO2R%20Station.pdf presentation].

'''Screenshot of my desktop:

[[Image:Sdrdesktop.png|800px]]

Since both DXLog and HDSDR need to communicate with the radio, you need to "split" 
the CAT communication. microHAM's USB Device Router provides a second, independent, 
CAT port that can be used via HDSDR's omniRig interface.

'''"PORT" Tab on microHamRouter:

[[Image:Sdrmicrohamrouter.png|800px]]

'''OmniRig settings in HDSDR:

[[Image:Sdromnirig.png|200px]]

With this set up, the radio, DxLog, and HDSDR will be fully synchronized. For instance, you can 
click in the waterfall to make the radio QSY, and it is easy to quickly find a clean frequency.

To make the integration even better I use a small AutoHotkey script. The script pulls entry focus 
back to DxLog after clicking on the HDSDR waterfall and in DXLog it allows you to use hotkeys to 
control HDSDR. <code>[Ctrl][Alt]+</code> and <code>[Ctrl][Alt]-</code> zooms the waterfall/spectrum 
in and out, and <code>[Ctrl][Alt]C</code> centers it.

'''AutoHotkey script:

SetTitleMatchMode, 2
#InstallKeybdHook
#IfWinActive, HDSDR
{
F4:: return ; disable F4
~LButton Up::
sleep, 1
Winactivate, DXLog
return
}
#IfWinActive, DXLog
{
^!+:: ControlSend ,, ^{+}, HDSDR
^!-:: ControlSend ,, ^{-}, HDSDR
^!c:: ControlSend ,, {c}, HDSDR
}

The script can be downloaded [http://DXLog/sw/files/utilities/dxlog_hdsr.ahk here].

If you start two instances of HDSDR with two different SDR you can even have two waterfalls 
running at the same time.

I have not yet found a way to display cluster spots in the HDSDR spectrum panel. 
But I still find it very useful to check band activity and it allows me to easily find 
a new Run frequency on a crowded band.

===Waterfall Bandmap===

The free waterfall/spot display utility "Waterfall Bandmap" by Steve N2IC is supported by DXLog.

Waterfall Bandmap supports almost any SDR that produce I/Q output either via ExtIO.DLL or a 
sound card; SDRPlay, FunCubeProPlus, HackRF, SDR-IQ, RTLSDR, SoftRock, etc.

A zip file with an executable binary and a Microsoft word document with installation and 
configuration instructions can be found here: https://groups.io/g/waterfallbandmap/files

If you are not a member of the support forum group, you need to apply for membership to download. 
Membership is free.

[[Image:Waterfallbandmap.png]]

The SDR can be connected either to a separate receive antenna, an external receiver output on 
your transceiver or to an IF output, should your transceiver have one. If connected to an antenna, 
keep in mind that you may need protection from the transmitter such as a T/R relay or a passive level limiter.

Please refer to Waterfall Bandmap's documentation for setting it up with your SDR.

Waterfall Bandmap needs two information feeds over UDP: Radio information and spot information. 
Both are provided as UDP broadcast by DXLog.

The default port for both is 13063 and this needs to be set in DXLog's Network configuration panel. 
If Waterfall Bandmap runs on the same computer as DXLog, the broadcast address can be left at the default 127.0.0.1.

[[Image:Setbroadcastportsforwfbandmap.png]]

Clicking on the waterfall display can set the frequency of DXLog. (Left click sets VFO A, right click sets VFO B.) 
To enable this functionality, check the option <code>Options|Broadcast|Receive Broadcasts</code> 
Also make sure "UDP broadcast listener" includes port 13064 in the network settings panel.

The radio information feed needs to be enabled by checking the <code>Options|Broadcast|Radio information</code> option

[[Image:radiobroadcastenable2.png]]

and the spot feed needs to be enabled by checking the <code>Options|DX Cluster|Send spots to SmartSDR</code> option.

[[Image:Enablesendspotstosmartsdr.png]]

==Time synchronization==

In a multi-station setting, the time needs to be accurately synchronized across all networked PC.

Windows' built in time synchronization is very crude and for a PC with poor clock stability the 
inaccuracy of the clock may be up to a minute. Which of course is not acceptable for contesting.

DXLog has built in support for time synchronization as described in the [[Menu Options#Configure network|Configure network section]].

Due to Windows' security system, this however requires all except the PC running as time server to 
run DXLog with elevated permissions. There is unfortunately no way around this inconvenience.

An equally accurate and less intrusive method is to use a standalone time synchronization application on each networked PC. 
This will keep each PC's clock accurate within a fraction of a second.

Contrary to a solution built into a logger it also has the great benefit of being an "install and forget" solution.

A popular application is Dimension 4 by Thinking Man Software. It is free for personal use and 
can be downloaded here: https://dxlog.net/sw/files/utilities/d4time531.msi

It runs in the background and only shows up as a tiny icon in your system tray. 
You hover the mouse above the icon to check status and right-click to open and change settings.

:::[[image:dimension4tray.png|50px]]

After installation a brief configuration is required.

First of all, allow the application to disable Windows' time service and to modify your system clock.

For maximum accuracy, select a time server geographically close to your location. 
When in doubt, you can always add the global server "pool.ntp.org" to the list and use that. 

There are also national and continental pools of time servers. You can find them here https://www.ntppool.org.

[[image:dimension4b.png]]

Make sure the check boxes "Load Dimension 4 at startup", "Start minimized", "Hide when minimized", 
and "Display icon in tray" are all checked.

[[image:dimension4advanced.png]]

Click the Advanced button and also make sure the option "Use the selected server" is selected.

Make sure the application reports a successful connection to the selected time server. 
From here on, you can basically forget the application. 
It will silently start with your PC and always keep its time accurate.

==Disabling USB power management==

In the interest of saving energy, Windows habitually power down USB interfaces 
when it believes there is inactivity. Some USB-to-serial and USB audio devices 
respond poorly to being suspended or powered down so as a rule this "feature" should 
be disabled when used in a ham radio environment.

There are two places where this functionality needs to be disabled; the device driver 
and Windows' energy management.

To disable it for each USB interface and device, open Windows settings. (Click the Windows 
icon in the lower left corner and then chose the cogwheel.) Type ''device manager'' and
select the result.

[[image:devicemanager-c.png|none|frame]]

This opens up a new window, Windows' Device Manager.

[[image:devicemanager2b.png|none|frame]]

For '''every''' USB interface component (there may be many), COM-port, and audio device, 
and '''uncheck''' the option ''Allow the computer to turn this device off to save power''.

The devices you are looking for are in the categories: ''Ports (COM & LPT)'', 
''Sound, video and game controllers'', ''Universal serial bus controllers'',

Note that some devices may not have a ''Power Management'' tab.

[[image:usbdevicemanager.png|none|frame]]

The next step is to disable Windows ''Selective suspend'' feature for USB interfaces.

Go back to Windows Settings and type ''edit power'', click the appearing ''Edit power plan'' menu entry.

[[image:editpowerplan2.png|none|frame]]

This should open the window below, the plan editing panel.

[[image:editplansettings.png|none|frame]]

Click ''Change advanced power settings''. Scroll down to ''USB settings'' and make 
sure ''USB selective suspend setting'' is '''disabled''' for all situations.

[[image:Advancedsettings.png|none|frame]]

To prevent audio devices from becoming unreachable or going into sleep mode you should also 
disable exclusive access. While changing this, also make sure all audio enhancements are disabled.

You reach the detailed audio device settings by entering Windows settings, search for Control panel, 
and in the Control panel view, select Hardware and audio, and then Sound.

[[image:Audiodevice.png]]

Reboot your computer to make sure all settings are recognized by Windows.

==Interlock and inband operation==

In contest station terminology, the term ''Interlock'' refers to a technical solution preventing 
more than one station from using a shared resource, typically an antenna, at the same time.

The most common use for interlock is for inband operation. Inband operation means to have multiple 
transmitters on a single band, interleaving their transmissions. Sometimes on a split-second basis.

As long as you never have more than one transmitter active at any time, the majority of contests allow 
an unlimited number of transmitters and receivers on a single band for multi-operator categories. 
This fact is used by most big contest stations.

For an inband solution to be effective, each station must be able to receive while the 
other station transmits. This means it requires a separate, high performance receive antenna 
with very good isolation from the transmitter antenna. The most common way to 
achieve this is physical separation and geographic orientation to minimize the situations 
when they will radiate/listen in the direction of the other antenna.

For a station operating in the M/M, M/S, or M/2 category, inband operation can boost the points 
per hour performance significantly. It is also a lot more fun.

However, as with everything else, it comes at a cost. An efficient inband solution has:

* A high performance receive antenna for each operated band(s) with very good isolation from the transmitter antenna.
* A fail-safe antenna switching hardware.
* Interlock-capable keyers and/or station controllers.
* An interlock-capable contest logging software

A typical inband configuration can be seen in the illustration below.

[[image:inbandconcept-trx.jpg|800px]]

DXLog offers a software-based interlock which can be configured in a variety of ways, e.g. based on frequency 
band, operating mode, or station role. It supports an unlimited number of stations interlocking each other 
using a great variety of strategies.

The interlock relies on UDP networking and is overlaid on the communication for multi-station logging. 
UDP networking has the benefit of speed and low latency but is, unlike TCP, susceptible to packet loss. 
This means that a '''wired LAN''' is a necessity for any station using interlock. 
For the same reason, it is also not recommended to run interlock over e.g. VLAN/VPN link for 
geographically distributed stations.

A software interlock is not 100% reliable. Computer or software malfunction, networking issues such as packet 
loss, etc. can cause interlock to fail, even if only momentarily.

For this reason it is necessary to also accompany a software interlock with a fail-safe '''hardware''' interlock. 
Without hardware supported interlock you run the risk of not only violating contest rules but also cause serious equipment damage. 
Some contests, such as CQ WW, explicitly requires hardware interlock when using multiple stations on the same band.

There are many designs and even commercial products available for hardware interlock. 
One example of a simple but effective two station hardware interlock which also supports 
power amplifier sharing can be found [https://sm7iun.se/contest/inband/ HERE].

The purpose of this section is to describe steps of setting up a basic two station in-band solution with 
DXLog and microHAM keyers. The microHAM keyers are not mandatory but offers a much better user experience 
and removes the need for additional hardware.

'''Pro tip:''' Consider checking <code>Options|Networking|Allow other stations to abort sending</code> 
which will allow your partner station to interrupt your transmission with <code>[Shift][Esc]</code> in 
critical situations. Be careful though, the use of this function requires good judgment to avoid violence.

===Networking===

Open the networking configuration panel with <code>Options|Configure network</code> and make sure each 
station has a unique name and that only UDP networking is enabled.

Make sure the two stations use the same broadcast IP address and that it is in line with your LAN's 
configuration. Pressing the <tt>Default</tt> button is a good way to ensure this.

Make sure the menu option <code>Options|Enable network</code> has a checkmark.

[[image:inbandnetworkrun.png|left|frame]][[image:inbandnetworkinband.png|none|frame]] 

===DXLog Interlock configuration===

First of all, make sure that the <code>Options|Interface specific options|Prevent TX if another radio is on same band</code> 
is '''not''' enabled. This option completely prevents transmission if more than one networked station is set to the same band 
and the whole idea with inband is to have exactly that.

Next, activate software interlock on both stations using the menu option <code>Options|Networking|Software interlock</code> 
or by typing the commmand <tt>ILOCKON</tt>.

[[image:inbandinterlock2.png|none|frame]]

There are multiple options for configuring the interlock. In a simple set up with only two stations, the topmost 
option ''Same band from status list'' is a good choice. This option will prevent more than one station transmitting 
on the same band, regardless of mode.

In an environment with many stations (such as a multi-operator-multi-transmitter station) it is 
recommended to use the bottom option to only interlock with one or several named stations. 
This will reduce both LAN traffic and inband operation latency. This is particularly important when 
running parts of the DXLog network over high latency links such as VLAN/VPN or if some stations (albeit not 
part of the interlock cluster) are connected via Wi-Fi.

For more advanced scenarios you can also use interlock based on mode or station type (e.g. Run 1, Run 2, Mult, etc.).

The "status list" listing the networked DXLog stations is displayed in the ''Status Window'' which is opened 
with <code>Windows|Status window</code> or <code>[Alt][J]</code>.

[[image:inbandstatuslist2.png]]

DXLog also offers great flexibility when it comes to interlock strategy. The most straightforward and 
most commonly used is ''First one wins''. This is also typically the behavior of "unintelligent" 
hardware solutions when not assisted by software. With this strategy, the station starting to transmit 
first can not be interrupted and always gets to finish its transmission.

[[image:inbandinterlockoptions.png]]

With a ''Last one wins'' strategy, the transmitting station can be interrupted. A carte blanche permission 
to interrupt all transmissions by the other station may however be counterproductive in a real contest situation.

For this reason, DXLog offers additional control of which transmit actions can be interrupted and which can not. 
This is a powerful tool but requires both operators to be aware of it and may require 
practice before fully effective.

[[image:inbandstrategyexceptions.png]]

''F1'' through ''F7'', ''PLUS'' and ''INS'' refers to DXLog's standard messages. ''KEYB'' means a free text transmission 
from the keyboard using the <code>[Alt][K]</code> function and ''MAN'' means manual transmission using either paddle 
break-in or a footswitch.

For CW, DXLog recognizes paddle break in from a K1EL Winkey-compatible keyer as described in the [[Menu_Options#Winkey_Configuration|Winkey configuration section]].

Since DXLog recognizes a footswitch connected to a microHAM device, this is a recommended approach for phone. 
It is also possible to connect a footswitch to the DSR pin (pin 6) on a physical COM-port on the PC, but today 
few PC have such a port and it also requires additional circuitry.
Details on how to do this is available [[Additional_Information#Connecting_a_footswitch|HERE]].

===microHAM configuration===

Open the microHAM device configuration panel with <code>Options|microHAM device configuration</code>.

[[image:Mk2r-new9.png|none|frame]]

Check the option ''Enable TX lock/unlock''. This will do two things; it will enable DXLog to prevent 
transmission and and it will make DXLog aware of the microHAM device's PTT status. The latter is particularly 
important since it means DXLog will recognize PTT assertion not only by a footswitch connected to the 
microHAM device but also by the built-in Winkeyer (requires microHAM USB Device Router version 9.3.0 or later) 
'''Paddle-based break-in in an inband solution is currently unique for microHAM with DXLog.'''

'''Important:''' Making DXLog "PTT aware" means that care has to be taken in how PTT is set up. If you, for instance, 
enable DXLog PTT for the voice keyer, this will create a self-reinforcing feedback loop and PTT will thus never drop.

Check the option ''Dual radio device'' if you are using a u2R, MK2R, or MK2R+, otherwise, leave this unchecked.

Check the option ''Device without CAT interface'' if the device lacks a CAT interface (like the u2R) 
or if its CAT interface is not connected to the radio. This option will make sure the e.g. keying and 
audio routing is always set correctly in line with the operating mode (Voice, CW, or RTTY).

===Operating===

Inband operation requires a fair amount of training and it is a good idea to define and agree 
on general rules for operation, such as hand signals for challenging QSO, beforehand.

There are more than enough YouTube videos of inband operators yelling at each other.

The operating tactics may have to be adjusted during the contest. If Run is slow, 
doing S&P on the inband station can increase the points per minute significantly. 
However, if Run is strong, an overly active inband operator doing S&P, but not working 
multipliers, may actually reduce the station's points per minute significantly.

Real-time interlock status is shown in the ''Radio status'' window, which is opened with 
<code>Windows|Radio status</code>.

[[image:inbandblocking.png]] [[image:inbandblocked.png]]

For Phone contesting, you typically rely on footswitches for PTT and the option 
<code>Options|Networking|Show QSO status when blocking</code> makes the blocking 
station send a more helpful blocking cause than ''MAN''.

With this option enabled, the blocking station will instead send ''CQ'', ''QSO'', or ''EXCHANGE'' 
as blocking cause, determined by cursor location and entry field content at the locking station.

Further reading can be found in the [[Menu_Options#microHAM_device_configuration|microHAM device configuration]] and [[Menu_Options#Networking|Networking]] sections.

==Connecting a footswitch==

To free up both hands in Phone contesting, a footswitch PTT is a great help.

Also, to use interlock in Phone contesting, a footswitch is mandatory.

There are two basic ways to interface a footswitch with DXLog; via a microHAM device (which is the recommended solution) 
or directly connected to a physical serial port on the PC (which very few PC have today).

The connection of a footswitch to a microHAM device is very straightforward and by checking the ''Enable TX lock/unlock'' 
in the ''microHAM device configuration'' panel, it is recognized by DXLog.

Lacking a microHAM device, it is also possible to use the computer's DB9 RS-232 serial port connector, providing it has one.

The required steps to do this are:
* Connect a 10k resistor between DB9 pin 6 and pin 7.
* In the port's settings (<code>Options|Configure interfaces</code>) set DTR (pin 4) to ''Always On'' and RTS (pin 7) to ''Always Off'' for the port.
* Connect the footswitch between DB9 pins 4 and pin 6. '''Important:''' Neither pole on the footswitch must be connected to ground.
* In the radio's configuration panel, check ''use CAT PTT command on Phone'' and set ''Footswitch (pin 6)'' to ''PTT''

==Support for CC Cluster==

CC Cluster is today the main choice for contest use.

It offers a high quality, database-verified, flow of skimmer spots and a rapid 3-minute respotting period for skimmer spots.

It also publishes unique spots from less common locations which are valuable for DX chasers or as contest multipliers.

To make use of the display of own spot in the world map, make sure to issue the command '''<tt>SET/OWN</tt>''' to the cluster node. 
This setting is persistent and only needs to be done once.

A list of cluster nodes that runs CC Cluster can be found here: [https://www.dxcluster.info/telnet/index.php?software=CC%20Cluster CC Cluster nodes]

A description of the command line syntax can be found here: [http://bcdxc.org/ve7cc/ccc/CCC_Commands.htm CC Cluster command syntax]

A convenient software for setting up filters etc. can be found here [http://www.bcdxc.org/ve7cc/default.htm#prog CC User]

[[Image:Ccclustersspotflow.png]]

==Support for AR Cluster 6==

With the author tragically SK, AR Cluster is no longer under development but still available as an executable binary.

In its standard configuration, AR Cluster offers no consolidation of skimmer spots meaning a very high flow of spots 
that can become extreme during a major contest weekend.

With the advent of skimmers, the traffic on the DX Cluster has risen dramatically. Even though CW skimmers are generally 
quite reliable, the absolute number of busted spots can be quite high during a busy contest.

Jose CT1BOH has developed an algorithm for evaluating spot quality which is included in version 6 of AR Cluster. 
Today many cluster nodes runs this version and thereby offer this mechanic. 
A complete list can be found here: [http://www.dxcluster.info/telnet/index.php?software=AR-Cluster AR Cluster nodes]

To enable the functionality on a cluster node running AR Cluster 6, the command

<tt>'''SET DX EXTENSION SKIMMERQUALITY'''</tt>

needs to be issued to the cluster node. The easiest way to do this in DXLog is via <code>[Alt][T]</code>. 
This setting will be remembered at subsequent logins.

The quality of the spots is indicated by a character ("tag") in the last column of the comment field and, 
in some cases, a corrected callsign within parenthesis. This syntax is recognized by DXLog and can reduce the 
number of bad spots in your bandmap.

The CT1BOH skimmer quality algorithm is based on three parts:

; Validation : When a callsign is first spotted, it is tagged with "?" in the last column of the spot's comment field. If the callsign of an unverified spot closely resembles an already verified one on the same frequency, the verified callsign is provided within parenthesis in the spot's comment field. When two or more skimmers agree on the spot, it is considered verified and the tag becomes "V".

; Frequency : When a verified spot appears more than 0.35kHz off its verified frequency, the spot is tagged "Q" for QSY. Once verified, this becomes the new verified frequency and it is tagged "V".

; Probability : The algorithm checks uncertain spots for resemblance with already verified spots and spots at or near the same frequency. If the resemblance is high enough, the spot is considered busted "B" and the corrected callsign is provided within parenthesis in the spot's comment field.

Below you can see an example of the spot flow from W9PA-4 with skimmer quality enabled. 
The flow contains one unverified and one busted spot.

[[image:spotquality.png]]

DXLog's policy for spots with CT1BOH skimmer quality tags is the following:

: '''V''' - Accept spot.
: '''Q''' - Accept spot.
: '''?''' - Accept spot. Use corrected call when provided.
: '''B''' - Accept spot if corrected call provided. Else ignore.

DXLog recognizes the skimmer quality tags but consolidates them for consistency 
with other cluster nodes' quality tags and to minimize confusion when mixing spot flows. 
The legend is:

: '''?''' means a spot with ? This is an unreliable spot.
: '''P''' means a spot with Q or B with correction. This is a fairly reliable spot.
: '''V''' means a spot with V. This spot is considered validated.

This basic policy can be modified by using additional filters at the cluster node end. Some examples are:

: <tt>'''SET DX FILTER NOT SKIMBUSTED'''</tt> - Do not send busted spots at all
: <tt>'''SET DX FILTER NOT SKIMQSY'''</tt> - Do not send QSY spots
: <tt>'''SET DX FILTER SKIMVALID'''</tt> - Only send verified spots
: <tt>'''SET DX FILTER NOT SKIMUNKNOWN'''</tt> - Do not send unreliable spots
: <tt>'''SET DX FILTER SKIMMER'''</tt> - Do not send manual spots

You can also compose more complex filters such as:

: <tt>'''SET DX FILTER SKIMVALID OR SKIMBUSTED OR NOT SKIMMER'''</tt>

This can be a good filter for most contests. It will will only provide valid or busted skimmer spots together with manual spots. 
It is safe to receive busted spots since DXLog will ignore them if there is no corrected callsign included. 

For assisted operation in serious contesting you however need to allow also unknown spots since weak stations spotted 
only by one or a few skimmers may never reach validated status. You do this by adding <tt>'''OR SKIMUNKNOWN'''</tt> to the filter.

Both the bandmap and the DX cluster announcement windows have the option to display the spot quality tag. 
These windows will show two additional tags; L and C. L stands for local spot, created by yourself or one of your team members. 
C stands for corrected, i.e., a B or ? spot where a corrected call has been included in the spot's comment field.

The AR6 filtering syntax offers a lot of flexibility. Another example:

: <tt>'''SET DX FILTER (SKIMVALID OR NOT SKIMMER OR ((SKIMQSY OR SKIMUNKNOWN) AND (CTY <> K AND CONT <> EU )))'''</tt>

will provide only validated and human spots except if they are from outside the US and EU.

If you get lost in the filter settings you can always reset with : <tt>'''SET DX DEFAULT'''</tt>.

Some more guidance on how to work with filters on AR-Cluster nodes can be found in [http://dxlog.net/sw/files/utilities/AR_Cluster_v6_User_Manual.pdf this document].

==Support for DXSpider==

DXSpider is the by far most dominant DX cluster software but has historically not been a good choice for contesters. 
The reasons for this include: Long respotting time, lack of pass function for own spots, and suppression of spots from a single skimmer.

The good news is however that the author Dirk G1TLH has worked hard to address these aspects of the otherwise brilliant software.

From '''version 1.57 release 440''' the respotting time is now 3 minutes and there is a <tt>SET/SEEME</tt> command that passes all spots 
without consolidation of your own callsign.

So if your favorite cluster node is not running this version, ask the owner to upgrade asap.

Yet another reason for its popularity is its extreme resource-efficiency which allows it to run virtually 
any Linux capable hardware, including a $20 Raspberry Pi Zero.

A list of all DX cluster nodes running DX Spider can be found here: [https://www.dxcluster.info/telnet/index.php?software=DX%20Spider DX Spider cluster nodes]

[[image:dxspiderflow.png]]

DXLog recognizes the <tt>Q:#</tt> skimmer quality tag in the comment field and converts them into "CT1BOH-like" quality 
tags that can be displayed in DXLog's bandmap. The legend is:

: '''?''' means a spot with Q:1, i.e. heard by only one skimmer. This is an unreliable spot.
: '''P''' means a spot with Q:2, i.e. heard by only two skimmers. This is a fairly reliable spot.
: '''V''' means a spot with Q:3 or higher, i.e. heard by several skimmers. This spot is considered validated.

Since a DXSpider node currently needs to be specially configured by the owner to publish Q:1 spots, very few do this. 
Also, since DXSpider lacks busted call detection, the the quality of the spot flow will suffer if this is done.

There is a wealth of information to be found on the [http://wiki.dxcluster.org/index.php/Main_Page DXSpider wiki].

==Support for N2WQ Cluster==

Introduced in late 2025, Rudy N2WQ has developed the first new DX cluster node software in decades.

The N2WQ-2 cluster has some unique features like a more advanced callsign validation than 
AR 6 and propagation estimation tags embedded in the spot comments. An example can be seen below.

[[image:n2wpspotflow.png]]

When you connect to dxc.n2wq.com port 8300 and you have set your 4-digit Maidenhead grid (SET GRID), there 
will be a single character just before the DX’s grid locator. This character is the path prediction glyph.

It is a crowdsourced, real-time estimate of how reliable the path is between you and the DX on that band right now, 
based on recent on-air propagation reports from RBN and PSKreporter. Its values and meaning are:

: > High: Strong path. If you can hear them, you should be able to work them.
: = Medium: Decent path. Workable with normal contest/DX technique.
: < Low: Weak path. Possible, but expect repeats, timing, and patience.
: - Unlikely: Marginal. Try only if it’s rare/needed, or you have a strong station advantage.

A missing glyph means insufficient data to estimate the path.

the glyph is mode-aware. A path that looks great for a very sensitive mode (FT8) can look 
more moderate for a less sensitive one (SSB).

You can filter spots by path reliability using the PASS/REJECT PATH command.

It is important to be aware that the glyph does not know:

: Your antenna gain/pattern, height, or takeoff angle
: Your transmit power and duty cycle constraints
: Your operating technique (timing, split discipline, pileup strategy)
: Short-lived phenomena the network has not yet “seen” such as sporadic E or aurora.

The cluster ingests upwards of 50,000 CW, FT, RTTY, and WSPR spots per minute. To compare different modes 
fairly, the system normalizes reports onto a common “FT8-equivalent” scale (so a CW SNR can be compared 
to an FT8 SNR).

Your grid and the DX grid are mapped into small geographic cells and the cluster calculates propagation 
at two levels:

: Fine (local): what’s happening close to your area (~180 miles).
:: On averages there are about 90,000 DE/DX pairs being tracked
: Coarse (regional): what’s happening in the broader region around
:: you (~480 miles). On average, there are about 30,000 DE/DX pairs.

If there isn’t enough local data, the system leans more on regional behavior. 
If there’s plenty of local data, it uses that more heavily.

Sometimes you can hear them better than they can hear you (or the reverse) due to noise 
floors, antennas, geography, or ionospheric effects. The system tracks both:

: Receive direction: DX to you (can you hear them?)
: Transmit direction: you to DX (can they hear you?)

It combines these into one “path reliability” estimate, weighting receive a bit more 
because if you can’t hear them, you can’t work them.

Propagation changes fast, so older reports get discounted using a half-life (data fades 
in influence over time). Typical behavior by band:

: Low bands (160/80m): slower changes (longer half-life)
: Mid bands (40–20m): medium pace
: High bands (15–6m): fast changes (shorter half-life)

In practice, this means glyphs can shift in minutes on 10m/6m, and more slowly on 80m/160m. 
Also, new openings take time to show up. A "insufficient" can simply mean “the path just opened 
and the cluster hasn’t collected enough recent reports yet.”

Your local noise floor heavily affects what you can receive, so the cluster lets you tell 
it what your noise environment is. This mainly tunes the receive-side expectation (DX to you).

Set it with SET NOISE SUBURBAN. Available profiles per ITU:

: QUIET: very low noise, rural/remote
: RURAL: mild noise
: SUBURBAN: typical neighborhood QRM
: URBAN: elevated noise, dense housing
: INDUSTRIAL: severe noise

If you don’t set it, the system may assume a quieter environment than you actually 
have, and your receive-side glyphs can look too optimistic.

Treat the glyph as a real-time probability hint that helps you spend your operating 
time where the odds are best. When you see > on a needed multiplier, move fast. 
When you see -, be intentional about whether it’s worth the time. 
And when you see a space, fall back to classic DX/contest instincts and your own ears.

The N2WQ cluster also offers spot quality tags between the DX grid and the time.

A quality (in terms of callsign reliability) tag can be V, P, S, C, or ? where V means validated, 
P highly likely, S less likely, C corrected, and ? unsure.

The propagation and quality tags can be displayed in the bandmaps and the DX cluster announcement window.

DXLog recognizes the skimmer quality tags but consolidates them before display for consistency 
with other cluster nodes' quality tags and to minimize confusion when mixing spot flows. 
The legend is:

: '''?''' means a spot with ? or S. This is an unreliable spot.
: '''P''' means a spot with P or C. This is a fairly reliable spot.
: '''V''' means a spot with V. This spot is considered verified.

==Interacting with WSJT-X==

Important: When in a DXpedition/multi-station setting, always use local host 127.0.0.1 as the 
broadcast address to prevent packets being picked up by other stations in the network. 
Also, enabling the creation of local spots from decodes may overwhelm DXLog.

DXLog can add QSO performed with WSJT-X to its log. Note that this functionality only works 
for contests with grid as the first and only exchange or for DXPedition type logs.

DXLog can also create local spots from WSJT-X decodes by checking 
<code>Options|Broadcast|Spot WSJT-X decodes</code>.

To enable logging of WSJT-X QSO, set up WSJT-X to broadcast information:

[[image:Wsjt-x-udp.png]]

[[image:Radiobroadcastenable3.png]]

Activate DXLog's UDP listener by checking <code>Options|Broadcast|Receive broadcasts</code> and set 
the same port number as in WSTJ-X in DXLog's network configuration panel.

[[image:Dxlog-udp.png]]

==Using Winkey FSK==

Winkey FSK is not natively supported by DXLog's digital mode engines MMVARI or MMTTY but 
Rafal EI6LA has developed a plugin for MMTTY that makes this possible.

You can find it [https://github.com/RafalLukawiecki/WinKeyerMMTY here].

==Interfacing with LogHX==

Christian F8GHE has prepared a guide on how to do this.

You can find it [http://dxlog.net/sw/files/utilities/DXLOG-LogHX_UDP-config_v2.pdf here].

==Self-spotting==

More and more contests allow spotting your own station on the DX cluster.

DXLog supports this, even when operating unassisted, as long as you connect to the cluster.

DXLog has three mechanics for self-spotting.

DXLog blocks self spotting unless specifically allowed in the contest rules. 
Should you find that DXLog incorrectly allows or blocks self-spotting, please make 
the development team aware via the support reflector.

* The <tt>$SPOTME</tt> macro command. This macro will create a cluster spot of the station's
: call at the earliest 15 seconds after being invoked the first time on a new frequency.
: Thereafter it will spot as frequent as allowed by the contest. If the contest rules do not
: specify a minimum period, 10 minutes will be used.

* Checking the menu option <code>Tools|Data entry|Run F1 message self-spots when permitted</code>.
: Works exactly like the <tt>$SPOTME</tt> macro command but is triggered by sending the
: Run F1 message which happens when pressing <code>[Enter]</code> with an empty entry line
: in Run, pressing <code>[F1]</code> in Run, or with Auto-CQ.

* Clicking the menu item <code>Commands|Self-spot</code> or pressing its shortcut key <code>[Ctrl][S]</code>.
: This will immediately create a spot of the station's call but no more often than
: every two seconds to avoid accidental multiple spots.

==DXpedition use==

DXLog is a popular choice for top tier dxpeditions. Below we have collected advice based on experience 
on how to best use DXLog in a dxpedition setting.

* Use client/server networking between stations. Never use UDP over Wi-Fi or WAN links.
* Use the "Minimal data" option in ADIF export to save on satellite link cost.
* For Club Log real time upload, use [https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads Club Log's upload app]
* Club Log truncate QSO time to minutes so to avoid creating dupes when mixing manual and real time upload to Club Log, check ''QSO time in minutes'' when doing ADIF export.
* Use the "Minimal data" option in ADIF export to save on satellite link cost.
* Follow [[Additional_Information#Interacting_with_WSJT-X|the instructions]] to log QSO made with WSJT-X and MSHV.
* Check <code>Options|Broadcast|Spot WSJT-X decodes</code> to make decoded calls appear in e.g., DX cluster announcements.
* You can extend the number of digits in the QSO count with <code>Options|Log|QSO number digits</code>

==Beacon spots on DX cluster==

Although propagation measurements based on FT8 communications has reduced the 
value of beacons, there are still hundreds of them in operation.

Identifying with CW, they are typically reported on reported on the DX cluster.

When beacon spots are received by DXLog, they are always displayed in the bandmap. 
In DXLog, beacon spots are recognized by having a trailing <tt>/B</tt>.

The DX cluster announcement window never shows or counts beacon spots.

Beacon spots can be enabled and disabled in the cluster node.

For CC Cluster, the commands are <tt>SET/BEACON</tt> and <tt>UNSET/BEACON</tt>.

For DXSpider, command is part of the <tt>SET/SKIMMER</tt> command where <tt>SET/SKIMMER</tt> 
or e.g., <tt>SET/SKIMMER CW BCN FT RTTY</tt> will pass beacon spots and <tt>UNSET/SKIMMER</tt> 
or any <tt>SET/SKIMMER</tt> listing modes but not BCN will block them.

AR 6 cluster nodes always pass beacon spots when skimmer spots are enabled. They cannot be disabled.

==Using Piper text-to-speech synthesis==

James M0DST has prepared 7 sample scripts that can be mapped to F keys.

James' comments on the scripts are:

This is just an extended proof of concept. Feel free to play using your own scripts. 
There is a lot of code duplication across the scripts. I may simplify some of this in the future. 
I tried base classes, but the current script engine would need some rework to support that. 
Repeat isn't supported. You will need to press the key manually. 
Multiple op voices are not supported currently. You could hack this in with little effort. 
There is no documentation at present. This feature is experimental whilst I decide how I want 
to move it forward (if at all). If you want to adjust the speed, you can do it per script. 
See SpeakingRate in the F2 script. Lower number is faster.

You can visit https://rhasspy.github.io/piper-samples/ to hear the voices. Set the model in the script.

Any comments or thoughts on anything related to this should be sent to me directly or on the list.

I really suggest training your own voice. I haven't done it yet, but I will when I have time. 
Using common amateur radio phrases in the training data will help teach it to sound more like a ham.

If you improve the scripts, please send them to me and I will update the files behind this link. 
Once everything is stable and formalized I will pass the links to Bjorn for the website, and we 
will add some real documentation.

Experimental scripts:
[https://drive.google.com/file/d/1EhfOpxsL57yuf-1WorASnGf-SBsmfqu7/view?usp=drive_link F1]
[https://drive.google.com/file/d/1MgviBec7HCXIOJZtDZXl0qXlrU-TwMoD/view?usp=drive_link F2]
[https://drive.google.com/file/d/1yAgY5E-KdOcmToXMJQ2lRNhjBIQrJIb9/view?usp=drive_link F3]
[https://drive.google.com/file/d/1-ftWUhFlc4-quwGPIVmNujQ4q-J5E3EZ/view?usp=drive_link F4]
[https://drive.google.com/file/d/1h3C_kLl9C4CEH6kATGAZbfDkfY6KlgqB/view?usp=drive_link F5]
[https://drive.google.com/file/d/1e4tAHz-_dU92RybaFeSuLCd0V7Gk_lWy/view?usp=drive_link F6]
[https://drive.google.com/file/d/1UGxgOpqOjOzl7yFTjrVaml9m5o8gBq5y/view?usp=drive_link F7]

Additional Information

2026-04-01T07:09:35Z

Sm7iun: /* DXpedition use */

==Using alternative configurations==

Window positions, coloring and general look and feel is saved in each log file but all other settings such as 
radio control, keying, and networking is saved in a common, contest-independent configuration file.

By default, the configuration file name is <tt>DXLog.net.config</tt> and it is located in the <tt>%appdata%\DXLog.net</tt> configuration folder.

This folder is also reachable via the <code>File|Open configuration folder</code> menu item.

[[image:configfolder.png]]

DXLog can be made to use an alternative configuration file with the command line option <tt>-cfg=<filename></tt>.

A convenient way to use this option is to create a separate Windows desktop shortcut including the command line option 
and give it a meaningful name.

[[image:Desktopshortcut.png]]

The command line option is simply added to the end of the Target text box in the shortcut's properties. 
Double-clicking the icon will start DXLog with the alternative configuration which will also be remembered between sessions. 
In the picture below the target of the shortcut is

[[image:Desktopshortcutconfig.png]]

'''Important:''' If you want to use an alternative configuration, do not just modify the desktop shortcut created at installation 
since this shortcut will be deleted when you upgrade DXLog. Instead make a copy, rename, and add the command line option. 
You should keep the command line option outside the apostrophes, like this

<tt>"C:\Program Files (x86)\DXLog.net\DXLog.net.exe" -cfg=SO2R.config</tt>

==Using a number server==

For contests involving serial numbers you need to secure that the sent number and the (slightly later) 
logged serial numbers are the same. In a straightforward SO1R or SO2V scenario, serial numbers are simply 
chronological but in more complex station configurations such as Multi-single or Multi-2 with inband, and 
advanced SO2R, QSO can be interleaved and requires a central source source of serial numbers together 
with a mechanic to protect an already sent serial number from re-use by another radio.

In DXLog this is achieved with a central number server. A number server can be used either 
by a single instance of DXLog (for SO2R) or by multiple stations on the same LAN.

The use of a number server involves three, natural, steps:

* Activating the server on a single station
* Making sure all stations use it
* Verifying functionality, making sure serial numbers are correctly reserved

The number server is activated in the <code>Options|Configure network</code> panel, described [[Menu_Options#Configure_network|HERE]].

[[image:startnumberserver.png]]

Since the server uses a networking socket, <code>Options|Networking</code> must be enabled '''also''' when 
using a single computer in SO2R. In the case of multiple stations, UDP networking or Client-Server 
networking must also be enabled to transfer the numbers over the LAN. For SO2R, this is however not 
necessary. When using Client-Server networking, a client cannot be number server.

There must only be one number server in a local network and all stations using it must have 
<code>Options|Networking|Use number server</code> checked like in the picture below.

'''Important:''' The number client/server functionality is not very robust. 
If you have stations joining/leaving your network or being rebooted, it is 
best to restart DXLog on all stations to guarantee correct function.

[[image:usenumberserver.png]]

The option <code>Block logging if serial number reservation is unsuccessful</code> can be used as an extra precaution 
but is not necessary in SO2R since the communication with the number server does not leave the computer.

There are three methods for reserving a number from the server:

* Checking <code>Tools|Data entry|Space key reserves serial number</code> and using the space key to reserve serial numbers. This is typically used on phone or when operating "old school" with F-keys.
* Checking <code>Tools|Data entry|Insert and F2 messages reserve serial number</code> and letting DXLog automatically reserve a serial number right before $SERIAL sends it. This is the preferred and most straightforward way for CW and digital.
* Adding the $RESERVENR macro to messages like illustrated below. 

These methods can of course also be combined. 

The $RESERVENR macro is "smart" and will only reserve a serial number if the callsign entry field is not empty and a 
serial number is not already reserved. The same goes for the menu items.

[[image:reservemessages.PNG]]

The sign of a serial number being reserved is that it turns red. It then stays reserved (and red) until the 
QSO is logged or the entry line is cleared with <code>[Alt][W]</code>.

An option that can prove useful is <code>Tools|Data entry|Cancel serial number reservation only if callsign field is empty</code>. 
In the case that you send the exchange and realize you got the other station's callsign call completely wrong, a reflex can be to hit 
<code>[Alt][W]</code> and start typing. If this is your habit, this option will prevent you from releasing the 
already sent serial number, thereby avoiding you the trouble to send a new one to the other station.

[[image:reservednumber.png]]

==Networking over internet==

When, for instance, activating a special event callsign it is possible to network multiple DXLog stations over the internet.

'''Pro tip:''' Consider displaying the callsign, message ID, Message text, etc. fields in the ''Network status'' 
window when operating a distributed station. Also, learn to use the gab <code>[Alt][G]</code> and <code>[Alt][J]</code> function.

===VLAN/VPN Solution===

The most secure way for remote networking is to rely on a VLAN (virtual LAN) software. There are several available such as:

ZeroTier https://www.zerotier.com/ 
FreeLan http://www.freelan.org/ 
Player.me https://player.me/ 
OpenVPN https://openvpn.net/

Each VLAN solutions have their own particular set up which is covered in their respective documentations. 
With a VLAN solution, all DXLog configurations are the same as when operating in a regular LAN however with a few exceptions.

One weakness with connections over the internet (a.k.a. WAN), including VLAN solutions, is that they are prone to packet loss. 
Packet loss is disastrous to DXLog's (or any logger's) "standard" UDP networking.

It is therefore essential to use '''only client/server networking over a VLAN'''. 
'''This also means you should never use interlock over an internet connection unless you use a zero packet loss VPN tunnel.'''

ZeroTier is particularly popular since it is free.

Since DXLog is able to mix TCP (client/server) and UDP (peer-to-peer) networking, a distributed station set up should be configured to rely on TCP 
for the wide-area network and UDP for the local network at each station location. Below you will find the station 
set up for the Swedish HQ station SE9HQ in the 2019 IARU HF Championship. The DXLog.net.DXC cluster client was run 
on SK3W-A which distributed spots to all stations over the network. Inband interlock was also used at the SK3W location.

[[image:SE9HQ-network-eng.png|800px]]

Important to note:

* For the server as well as the main clients, ''Server IP'' should be set to the server's VLAN IP address, '''not''' its LAN address.
* The '''server''' should check both "Act as network server" and "UDP network broadcast for multiple stations".
* The '''main clients''' should check both "Connect to network server" and "UDP network broadcast for multiple stations".
* The '''sub clients''' should check only "UDP networking for multiple stations".
* Interlock (which is UDP-based) over VLAN does not work reliably because of packet loss.
: Therefore, it is important to configure any interlock to '''only''' consider relevant operating positions,
: which all must be local. Use the possibility to only consider named stations for the interlock in the software 
: interlock set up. <code>Options|Networking|Software interlock</code> "Custom station ID(s)"
* For a large set-up with many stations connecting as clients to a central server you may overload the server if you also
: distribute spots via all client-server connections. In this case, check the "No spots via client/server" option
: on all stations and use '''local DX cluster connections''' via UDP at each location.
: '''Important:''' Limitations in Windows networking makes client/server networking unreliable beyond 10 station locations.
* Make sure to check <code>Options->Load contest at startup</code> to avoid opening the wrong log after a restart.
* '''Remote commands are not forwarded''' in the network but are executed in the station where they arrive.
: Thus, to clear all logs, disconnect networking on each main client, execute the remote command CLEARLOGNOW on each main client
: to clear the logs of all sub clients and do not reconnect until the server and all other main clients have done the same.

===Port forwarding Solution===

If you are less worried about competitors or government agencies listening in on your contest data, 
it is possible to route the traffic directly over the internet using port forwarding at the server.

'''Important security notice: This solution is not without risk. It offers no security or authentication. 
Any DXLog station running the same contest configuration, knowing the URL or IP address and IP port of the 
server can connect to the server station. There are no means to disconnect a station by force.'''

Also note the comment about '''remote commands''' in the section above.

With a port forwarding solution, the following must be observed:

* '''Server configuration'''
:* Only one of the stations should be configured as the '''server'''.
:* "Connect to network server" should not be checked on this station and
:: "UDP networking for multiple stations" should only be enabled if it is used to
:: communicate with a cluster client or other stations locally on the same LAN.
:: Either use a central cluster connection (uncheck "No spots via client/server")
:: or use one cluster connection per station location (check "No spots via client/server").
:: If one cluster connection per station location is used, make sure they
:: all use different SSID to prevent disconnects, such as E7HQ-1, E7HQ-2, etc.
:: This will ensure the cluster node regards all connections as having the same callsign
:: which is essential for e.g., correctly receiving own spots.
:* The PC acting as server must be configured for a fixed LAN IP address. This is done
:: either by manually configuring the networking settings in the PC to use a fixed
:: LAN IP address, or by setting up the router in the server's LAN to to always allocate
:: the same IP address to it.
:* The internet connection used by the server PC must ''either'' have a fixed public IP address ''or''
:: use dynamic DNS. Otherwise clients will not be able to reliable connect over the internet.
:* The server's TCP/IP port (e.g., <code>9888</code>) must be forwarded to the server by the server LAN's router.
:: Only TCP traffic should be forwarded. DXLog UDP traffic is not carried well over the internet.

:: [[image:serverconfig.png|600px]]
:: '''Example configuration for server for networking over internet'''

::[[image:portforwarding.png|600px]]
::'''Example of port forwarding UI in router'''

* '''All other stations'''
:* All other PC in the multi-station set up should be set up as clients.
:* Over the internet, "Server:" is either the static, public IP address of the server's internet
:: connection (e.g. <code>5.140.211.42</code>) or the dynamic DNS address (e.g. <code>hq.sm7iun.se</code>).
:: Clients connecting over the internet does not have to enable UDP networking and ''should not''
:: enable a server.
:* A client may connect via UDP if it is on the same LAN as the server ''or'' a "main client".
:: A "main client" is a client that connects to the server using the "Connect to network server" option in
:: the networking set up panel. A "main client" acts as a UDP gateway which means that if
:: several computers on a LAN are part of the same multi station set up but the server is located
:: elsewhere, only one computer in that LAN needs to connect as a client and the rest can use UDP.
:* Software interlock is UDP-based and can only reliably be used locally. Never over the internet.
:: If used, make sure the interlock is explicitly limited to local stations. See above for more details.

::[[image:clientconfig.png|600px]]
::'''Example configuration of client for networking over internet'''

* In a multi-station setting it is recommended to enable
: <code>Options|Networking|Block standard messages if no operator is logged on</code>
* Make sure <code>Options|Enable network</code> is checked.
* It is also a very good idea to check <code>Options|Load contest at startup</code> to reduce the
: risk of the wrong contest log file being loaded by any stations.

==Real time upload to Club Log Live Stream==

'''Important:''' Club Log truncates QSO time to minutes which means that if you mix real time upload 
with manual upload, make sure to check "QSO time in minutes" when creating ADIF export files.

The author of Club Log, Michael Wall, G7VJR, has developed a very powerful agent for real time uploads. 
It works with all the three major loggers, DXLog, N1MM Logger+, and Win-Test.

It can either be used as is, with a command line user interface, or with an optional user interface front end.

Information on how to download and configure it can be found [[https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads HERE]]

The Club Log Gateway can either listen to DXLog's native multi-station networking protocol or to N1MM style XML broadcast.

To use DXLog's networking protocol, make sure the same port (default 9888) is used in the gateway and DXLog 
and that UDP networking is enabled in DXLog. Do not enable QSO broadcast.

Although this works, it is recommended to use N1MM style broadcast since it contains information like logged on operator, etc.

To use this make sure the port (default 12060) is the same in N1MM port setting in the gateway and in the 
QSO broadcast port settings in DXLog's network configuration. Also make sure to se the DXLog port number 
in the gateway is not the same as that used in DXLog to avoid QSO duplication.

Also set:

<code>Options|Broadcast|QSOs</code> 
<code>Options|Broadcast|QSOs</code> 
<code>Options|Broadcast|Use N1MM QSO format</code> 
<code>Options|Broadcast|QSO time in minutes only</code>

'''Important:''' If you are going to also upload exported ADIF files to Club Log, it is important to also 
check "QSO time in minutes" in the ADIF export configuration to avoid creating virtual dupes, since Club 
Log does not know seconds.

==Diversity reception==

Diversity means receiving the same signal through two different receive chains, including antenna. 
With two antennas having different characteristics this can give substantial benefits in receiving 
fading and/or weak signals or separating calls in a large pile-up. Particularly on low bands.

DXLog supports diversity operation on a selected number of radio models.

For the supported radios, diversity operation can be toggled on and off using <code>[Ctrl][-]</code> or <code>[Ctrl][Keypad -]</code>.

If enabled via the radio's controls, DXLog will automatically detect diversity operation and enable 
the necessary mechanics. Diversity operation is indicated by a small DIV icon in the frequency 
counter box for the radio's band map.

'''Yaesu FTDX101D

Yaesu calls this feature "Sync" and it has a dedicated button up and left of the main VFO knob. 
Enabling this will make DXLog update both VFO with the same information when grabbing spots. 
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO. 
Since both VFO are kept on the same frequency, split operation is not supported.

'''ICOM IC-7851 and IC-7610

ICOM calls this feature "Tracking" and it can be enabled either via a menu entry or a long press on the "MAIN/SUB" button. 
Enabling this will make DXLog update both VFO with the same information when grabbing spots. 
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO. 
Since both VFO are kept on the same frequency, split operation is not supported.

'''Elecraft K3/K3S/K4

Elecraft calls this feature by its proper name. It is enabled by a long press on the "Sub" button. 
It should be noted that Elecraft's implementation where the main VFO controls both the main and 
sub receivers allows for split operation, i.e. transmitting on a different frequency using VFO B.

==UDP broadcast==

For interaction with other applications, DXLog can broadcast useful information as 
XML datagrams over UDP. 

There are five types of broadcast messages produced by DXLog:

* QSO information. Sent when logging.
* Radio information. Sent at changes as well as periodically.
* Antenna direction information. Sent when rotor control is invoked.
* Callsign look-up information
* Spots

QSO can be broadcasted in traditional DXLog format or in a more N1MM-like format.

Radio information can report SO2V as a single physical radio or as two physical radios, like N1MM.

There is an option to truncate the broadcasted QSO time to full minutes for better 
interoperability with some online services and software such as MSHV.

In addition, DXLog can also recognize QSY commands from Waterfall Bandmap and log QSO done as well as create 
local spots from decodes broadcasted by WSJT-X and its forks.

The broadcasting of QSO and radio related data is enabled using the <code>Options|Broadcast</code> submenu.

The broadcasting of spots is enabled by checking <code>Options|DX Cluster|Send spots to SmartSDR</code>.

[[image:radiobroadcastenable3.png]]

[[image:sendspotstosmartsdr.png]]

UDP broadcast parameters are configured in the <code>Options|Network configuration</code> panel. 
Please note that up to three ports can be specified for each broadcast, thereby supporting 
multiple receivers of the information.

[[image:Networksettingsbroadcast3.png]]

If you are writing a C# application to make use of these datagrams, there is a very nice online tool 
for creating an object from a sample XML datagram here https://xmltocsharp.azurewebsites.net/ 

In C# parsing is easily done using Linq. One example of XML parsing and deserialization using Linq 
can be found here https://github.com/bjornekelund/ICOMautomagic

===QSO information===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program
|-
| qsoid
| A unique string for this QSO. If this QSO is edited another contactinfo message will be sent with the same qsoid. Note that the qsoid is only unique within one instance of DXLog. If the computer is networked to others running DXLog the different computers may have a different qsoid for the same QSO.
|-
| contestname
| The name of the contest as it would be written to a Cabrillo file.
|-
| timestamp
| The UTC date and time of the QSO.
|-
| mycall
| The callsign of this station.
|-
| band
| The band on which the QSO was made. In MHz with period as decimal separator.
|-
| txfreq
| The frequency on which the QSO was made.
|-
| operator
| The callsign of the operator if the OPON command was used to set it, otherwise blank.
|-
| mode
| The mode used for the QSO.
|-
| call
| The callsign of the station worked.
|-
| countryprefix
| The DXCC country of the station worked.
|-
| wpxprefix
| The WPX prefix of the station worked.
|-
| snt
| The RST sent. This is always included whether or not the contest exchange contains an RST.
|-
| rcv
| The RST received. This is always included whether or not the contest exchange contains an RST.
|-
| nr
| The number sent if the exchange uses a serial number, otherwise the QSO number from this station.
|-
| exch1
| The first element in the contest exchange if any.
|-
| exch2
| The second element in the contest exchange if any.
|-
| exch3
| The third element in the contest exchange if any.
|-
| exch4
| The fourth element in the contest exchange if any.
|-
| xqso
| True if this QSO should not be counted towards the score.
|-
| invalid
| True if this QSO is invalid, for example a DX QSO in a domestic contest.
|-
| duplicate
| True if this QSO is a dupe (the station has previously been worked).
|-
| rule10broken
| True if this QSO breaks the 10 minute or similar rule. Note that a QSO may not break the 10 minute rule when it is logged but may later if another QSO is edited. This may not cause a broadcast.
|-
| azimuth
| The approximate direction of the station worked, in degrees.
|-
| distance
| The approximate distance of the station worked, in kilometers.
|-
| stationid
| The station ID of the station which made the QSO.
|-
| stationqso
| A unique QSO ID generated by the logging station. The combination of stationid and stationqso forms a unique identifier for the QSO.
|-
| stationtype
| The type of station - R for run, R1 for run 1 etc.
|-
| local
| True if this broadcast is due to this QSO being logged or edited on this computer.
|-
| runqso
| True if QSO logged in Run, false if S&P, and empty if unknown. '''Important:''' Only valid when local is True.
|-
| mult1
| The name of the multiplier if this station is a new multipllier, empty otherwise.
|-
| mult2
| The name of the multiplier if this station is a new multiplier, emtpy otherwise.
|-
| mult3
| The name of the multiplier if this station is a new multiplier, empty otherwise.
|-
| points
| The logged points for the QSO.
|-
| period
| The number of the operating period.
|-
| guid
| The GUID in hex format.
|-
| newqso
| True if a new QSO, False if this message is an update to an existing QSO.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<contactinfo>
<logger>DXLog v2.4.13</logger>
<qsoid>19</qsoid>
<contestname>ARRL-SS-CW</contestname>
<timestamp>2020-01-13 18:28:07</timestamp>
<mycall>SM7IUN</mycall>
<band>3.5</band>
<txfreq>352376</txfreq>
<operator></operator>
<mode>CW</mode>
<call>K4BAI</call>
<countryprefix>K</countryprefix>
<wpxprefix>K4</wpxprefix>
<snt>599</snt>
<rcv>599</rcv>
<nr>19</nr>
<exch1>076</exch1>
<exch2>B</exch2>
<exch3>54</exch3>
<exch4>GA</exch4>
<xqso>False</xqso>
<invalid>False</invalid>
<duplicate>False</duplicate>
<rule10broken>False</rule10broken>
<azimuth>225</azimuth>
<distance>1388</distance>
<stationid>STN1</stationid>
<stationqso>19</stationqso>
<stationtype>R1</stationtype>
<local>True</local>
<runqso>True</local>
<mult1>GA</mult1>
<mult2></mult2>
<mult3></mult3>
<points>3</points>
<period>1</period>
<guid>11223344556677889900aabbccddeeff</newqso>
<newqso>True</newqso>
</contactinfo>
</pre>

Alternative N1MM format

Note that the band name uses the computer's local number format so it may use either comma 
or period as decimal separator. The ID is a number rather than an alphanumeric string.

Also note that IsRunQSO is only valid when IsOriginal is True.

<pre><?xml version="1.0" encoding="utf-8"?>
<contactinfo>
<app>N1MM</app>
<contestname>CWOps</contestname>
<timestamp>2020-01-17 16:43:38</timestamp>
<mycall>SM7IUN</mycall>
<band>3.5</band>
<rxfreq>352519</rxfreq>
<txfreq>352519</txfreq>
<operator></operator>
<mode>CW</mode>
<call>K1XM</call>
<countryprefix>K</countryprefix>
<wpxprefix>K1</wpxprefix>
<stationprefix>K1XM</stationprefix>
<continent>NA</continent>
<snt>599</snt>
<sntnr>5</sntnr>
<rcv>599</rcv>
<misctext></misctext>
<ismultiplier1>1</ismultiplier1>
<ismultiplier2>0</ismultiplier2>
<ismultiplier3>0</ismultiplier3>
<points>l</points>
<radionr>l</radionr>
<run1run2>1<run1run2>
<IsOriginal>False</IsOriginal>
<NetBiosName>DESKTOP-23AB</NetBiosName>
<IsRunQSO>0</IsRunQSO>
<StationName>STATION_B</StationName>
<ID>23</ID>
<IsClaimedQso>true</IsClaimedQso>
</contactinfo>
</pre>

===Radio information===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| The name of the logging program.
|-
| logger
| The name and version of the logging program.
|-
| Station
| The ID of the station.
|-
| RadioNr
| The radio being described.
|-
| Freq
| The receiving frequency.
|-
| TXFreq
| The transmitting frequency
|-
| InactiveFreq
| The frequency of the VFO not receiving.
|-
| Mode
| The reported radio's mode.
|-
| OpCall
| The callsign of the operator if the OPON command was used to set it, otherwise blank.
|-
| mycall
| The callsign of the station.
|-
| IsRunning
| "True" if the station is running, "False" if search and pounce.
|-
| FocusEntry
| The Windows handle for the focused entry window.
|-
| Antenna
| Antenna number.
|-
| Rotors
| Rotators used by selected antenna (not currently used by DXLog).
|-
| FocusRadioNr
| The radio which has keyboard focus. In SO2V with "Report SO2V as two radios" checked, radio 2 is the sub/B VFO.
|-
| IsStereo
| True if headphones are listening to two radios.
|-
| IsSplit
| True if radio is set to split.
|-
| ActiveRadioNr
| The radio which is transmitting, if any.
|-
| Technique
| SO1R, SO2R, SO2R_ADV, or SO2V
|-
| StationType
| Station role: R, M, R1, R2, or R+.
|-
| isTransmitting
| True if a DXLog is transmitting. False if DXLog is not aware of transmission.
|-
| IFFrequency
| Optional element only used with Elecraft K3/K4. Contains the current IF frequency in Hz.
|-
|}

Important note: In SO2V the format differs from some other loggers and is:

: Only physical radio 1 is reported.
: <tt>Freq</tt> and <tt>TXFreq</tt> are the frequency of the currently focused VFO.
: <tt>InactiveFreq</tt> is the frequency of the currently unfocused VFO.
: <tt>ActiveRadio</tt> is always 1.
: <tt>FocusedRadioNr</tt> is 1 when the main/A VFO is focused, 2 otherwise.
: <tt>IsSplit</tt> is always false.

With the option "Report SO2V as two radios" checked, the reporting is similar to some other loggers and is:

: The two VFO are reported as two physical radios.
: <tt>Freq</tt> and <tt>TXFreq</tt> for radio 1 are the frequency of the main/A VFO.
: <tt>Freq</tt> and <tt>TXFreq</tt> for radio 2 are the frequency of the sub/B VFO.
: <tt>InactiveFreq</tt> is the frequency of the other VFO.
: <tt>ActiveRadio</tt> and <tt>FocusedRadioNr</tt> are 1 when the main/A VFO is focused, 2 otherwise.
: <tt>IsSplit</tt> is always false.

Example message:

<pre><?xml version = "1.0"?>
<RadioInfo>
<app>DXLog</app>
<logger>DXLog v2.4.13</logger>
<Station>STN1</Station>
<RadioNr>1</RadioNr>
<Freq>704000</Freq>
<TXFreq>704000</TXFreq>
<InactiveFreq>702500</InactiveFreq>
<Mode>CW</Mode>
<OpCall>K1XM</OpCall>
<mycall>HQ9X</mycall>
<IsRunning>False</IsRunning>
<FocusEntry>591124</FocusEntry>
<Antenna>1</Antenna>
<Rotors>ABC</Rotors>
<FocusRadioNr>1</FocusRadioNr>
<IsStereo>False</IsStereo>
<IsSplit>False</IsSplit>
<ActiveRadioNr>1</ActiveRadioNr>
<Technique>SO2R</Technique>
<StationType>R1</StationType>
<IsTransmitting>False</IsTransmitting>
<IFFrequency>8215000</IFFrequency>
</RadioInfo>
</pre>

===Antenna direction===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program.
|-
| station
| The ID of the station.
|-
| radio
| The radio associated with the rotator.
|-
| go
| True if the rotator should be turned.
|-
| stop
| True if the rotator should be stopped if it is turning.
|-
| azimuth
| The direction to turn the rotator if go is True.
|-
| frequency
| The transmit frequency of the specified radio.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<Rotator>
<logger>DXLog v2.4.13</logger>
<station>STN1</station>
<radio>2</radio>
<go>True</go>
<azimuth>252</azimuth>
<frequency>2800200</frequency>
</Rotator>

</pre>
<pre><?xml version="1.0" encoding="utf-8"?>
<Rotator>
<logger>DXLog v2.4.13</logger>
<station>STN1</station>
<radio>2</radio>
<stop>True</stop>
<frequency>2800200</frequency>
</Rotator>
</pre>

===Callsign lookup===

Sent either when callsign in entry row is changed or when space or tab is pressed.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program.
|-
| contestname
| The name of the contest.
|-
| mycall
| Station's call
|-
| band
| Current band
|-
| txfreq
| Transmitter frequency
|-
| operator
| The call sign of the logged in operator
|-
| mode
| Operating mode
|-
| call
| Call entered in the logging field
|-
| countryprefix
| DXCC entity prefix
|-
| wpxprefix
| WPX prefix
|-
| azimuth
| Short path antenna direction
|-
| distance
| Distance in km
|-
| stationid
| The ID of the station sending the datagram
|-
| stationtype
| The role of the station sending the datagram; R, R1, R2, M, or R+
|-
| period
| Contest period
|-
| reason
| Reason for transmission; SpaceOrTab or CallChanged
|-
|}

Example message:

<pre><?xml version = "1.0"?>
<lookupinfo>
<logger>DXLog v2.4.20</logger>
<contestname>DARC-WAEDC-CW</contestname>
<mycall>K1XM</mycall>
<band>20</band>
<txfreq>1400200</txfreq>
<operator></operator>
<mode>CW</mode>
<call>E7DX</call>
<countryprefix>E7</countryprefix>
<wpxprefix>E7</wpxprefix>
<azimuth>54</azimuth>
<distance>6824</distance>
<stationid></stationid>
<stationtype>R</stationtype>
<period>1</period>
<reason>SpaceOrTab</reason>
</lookupinfo>
</pre>

===Spot===

Sent for every incoming spot from the DX cluster that is valid for the current contest.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| Application sending the message.
|-
| StationName
| The station issuing the broadcast.
|-
| dxcall
| The callsign of the spotted station.
|-
| frequency
| Frequency in kHz with decimal sign of the PC's current locale. (sic)
|-
| spottercall
| The callsign of the spotter. Station name if locally spotted or result of a logging operation.
|-
| timestamp
| Spot time in format yyyy-MM-dd HH:mm:ss
|-
| action
| add or delete.
|-
| mode
| actual or guessed mode of the spot in capitals.
|-
| comment
| The comment section of the spot.
|-
| status
| Spot status. Valid values are "dupe", "double mult", "single mult", and "new qso".
|-
| statuslist
| Same as status
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<spot>
<app>DXLog.net</app>
<StationName>CONTEST-PC</StationName>
<dxcall>E7DX</dxcall>
<frequency>14022.3</frequency>
<spottercall>SM7IUN-#</spottercall>
<timestamp>2O23-07-15 14:29:37</timestamp>
<action>add</action>
<mode>CW</mode>
<comment>CW 31 DB 42 WPM CQ</comment>
<status>single mult</status>
<statuslist>single mult</statuslist>
</spot></pre>

===Broadcast listener===

DXLog also listens for commands over UDP.

Currently only one command is implemented, <code><radio_setfrequency></code>, which is a QSY command.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| Application sending the command
|-
| radionr
| The radio to be changed. In SO2V radio 2 means VFO B. Optional as of DXLog 2.5.20.
|-
| frequency
| Requested frequency. Both period and comma is accepted as decimal separator.
|-
| mousebutton
| Which mouse button was used to create message, if any. Optional.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<radio_setfrequency>
<app>WaterfallBandmap</app>
<radionr>1</radionr>
<frequency>21022.194</frequency>
<mousebutton>Left</mousebutton>
</radio_setfrequency>
</pre>

==SDR integration==

===HDSDR, OmniRig, and microHAM===

''Contributed by Ingo SM5AJV/SE5E''

Until DXLog offers SDR integration there are still ways to get a waterfall/spectrum display with DXLog.

I have integrated the free SDR software [http://www.hdsdr.de/ HDSDR] with DXLog using
[http://www.microham.com Microham Device Router], 
[http://dxatlas.com/OmniRig/ OmniRig]
and [https://www.autohotkey.com/ AutoHotkey].

As illustrated below I place the HDSDR window at the very top of the desktop with DXLog right below.

I share my transceiver's (an Elecraft K3) antenna with the SDR. The receiver antenna signal from my 
K3's RX-ANT OUT is connected to the input of a 3dB power splitter. The two outputs from the splitter 
are connected RX-ANT IN on the K3 and the SDR Receiver antenna input, respectively. On a K3 you 
need to enable the RX-antenna input to make this to work. An additional benefit with this method 
is that the SDR is protected during transmission. It is a widely used method and is e.g. described 
by Bob N6TV in this
[http://dxlog.net/sw/files/utilities/Adding%20an%20SDR%20to%20an%20SO2R%20Station.pdf presentation].

'''Screenshot of my desktop:

[[Image:Sdrdesktop.png|800px]]

Since both DXLog and HDSDR need to communicate with the radio, you need to "split" 
the CAT communication. microHAM's USB Device Router provides a second, independent, 
CAT port that can be used via HDSDR's omniRig interface.

'''"PORT" Tab on microHamRouter:

[[Image:Sdrmicrohamrouter.png|800px]]

'''OmniRig settings in HDSDR:

[[Image:Sdromnirig.png|200px]]

With this set up, the radio, DxLog, and HDSDR will be fully synchronized. For instance, you can 
click in the waterfall to make the radio QSY, and it is easy to quickly find a clean frequency.

To make the integration even better I use a small AutoHotkey script. The script pulls entry focus 
back to DxLog after clicking on the HDSDR waterfall and in DXLog it allows you to use hotkeys to 
control HDSDR. <code>[Ctrl][Alt]+</code> and <code>[Ctrl][Alt]-</code> zooms the waterfall/spectrum 
in and out, and <code>[Ctrl][Alt]C</code> centers it.

'''AutoHotkey script:

SetTitleMatchMode, 2
#InstallKeybdHook
#IfWinActive, HDSDR
{
F4:: return ; disable F4
~LButton Up::
sleep, 1
Winactivate, DXLog
return
}
#IfWinActive, DXLog
{
^!+:: ControlSend ,, ^{+}, HDSDR
^!-:: ControlSend ,, ^{-}, HDSDR
^!c:: ControlSend ,, {c}, HDSDR
}

The script can be downloaded [http://DXLog/sw/files/utilities/dxlog_hdsr.ahk here].

If you start two instances of HDSDR with two different SDR you can even have two waterfalls 
running at the same time.

I have not yet found a way to display cluster spots in the HDSDR spectrum panel. 
But I still find it very useful to check band activity and it allows me to easily find 
a new Run frequency on a crowded band.

===Waterfall Bandmap===

The free waterfall/spot display utility "Waterfall Bandmap" by Steve N2IC is supported by DXLog.

Waterfall Bandmap supports almost any SDR that produce I/Q output either via ExtIO.DLL or a 
sound card; SDRPlay, FunCubeProPlus, HackRF, SDR-IQ, RTLSDR, SoftRock, etc.

A zip file with an executable binary and a Microsoft word document with installation and 
configuration instructions can be found here: https://groups.io/g/waterfallbandmap/files

If you are not a member of the support forum group, you need to apply for membership to download. 
Membership is free.

[[Image:Waterfallbandmap.png]]

The SDR can be connected either to a separate receive antenna, an external receiver output on 
your transceiver or to an IF output, should your transceiver have one. If connected to an antenna, 
keep in mind that you may need protection from the transmitter such as a T/R relay or a passive level limiter.

Please refer to Waterfall Bandmap's documentation for setting it up with your SDR.

Waterfall Bandmap needs two information feeds over UDP: Radio information and spot information. 
Both are provided as UDP broadcast by DXLog.

The default port for both is 13063 and this needs to be set in DXLog's Network configuration panel. 
If Waterfall Bandmap runs on the same computer as DXLog, the broadcast address can be left at the default 127.0.0.1.

[[Image:Setbroadcastportsforwfbandmap.png]]

Clicking on the waterfall display can set the frequency of DXLog. (Left click sets VFO A, right click sets VFO B.) 
To enable this functionality, check the option <code>Options|Broadcast|Receive Broadcasts</code> 
Also make sure "UDP broadcast listener" includes port 13064 in the network settings panel.

The radio information feed needs to be enabled by checking the <code>Options|Broadcast|Radio information</code> option

[[Image:radiobroadcastenable2.png]]

and the spot feed needs to be enabled by checking the <code>Options|DX Cluster|Send spots to SmartSDR</code> option.

[[Image:Enablesendspotstosmartsdr.png]]

==Time synchronization==

In a multi-station setting, the time needs to be accurately synchronized across all networked PC.

Windows' built in time synchronization is very crude and for a PC with poor clock stability the 
inaccuracy of the clock may be up to a minute. Which of course is not acceptable for contesting.

DXLog has built in support for time synchronization as described in the [[Menu Options#Configure network|Configure network section]].

Due to Windows' security system, this however requires all except the PC running as time server to 
run DXLog with elevated permissions. There is unfortunately no way around this inconvenience.

An equally accurate and less intrusive method is to use a standalone time synchronization application on each networked PC. 
This will keep each PC's clock accurate within a fraction of a second.

Contrary to a solution built into a logger it also has the great benefit of being an "install and forget" solution.

A popular application is Dimension 4 by Thinking Man Software. It is free for personal use and 
can be downloaded here: https://dxlog.net/sw/files/utilities/d4time531.msi

It runs in the background and only shows up as a tiny icon in your system tray. 
You hover the mouse above the icon to check status and right-click to open and change settings.

:::[[image:dimension4tray.png|50px]]

After installation a brief configuration is required.

First of all, allow the application to disable Windows' time service and to modify your system clock.

For maximum accuracy, select a time server geographically close to your location. 
When in doubt, you can always add the global server "pool.ntp.org" to the list and use that. 

There are also national and continental pools of time servers. You can find them here https://www.ntppool.org.

[[image:dimension4b.png]]

Make sure the check boxes "Load Dimension 4 at startup", "Start minimized", "Hide when minimized", 
and "Display icon in tray" are all checked.

[[image:dimension4advanced.png]]

Click the Advanced button and also make sure the option "Use the selected server" is selected.

Make sure the application reports a successful connection to the selected time server. 
From here on, you can basically forget the application. 
It will silently start with your PC and always keep its time accurate.

==Disabling USB power management==

In the interest of saving energy, Windows habitually power down USB interfaces 
when it believes there is inactivity. Some USB-to-serial and USB audio devices 
respond poorly to being suspended or powered down so as a rule this "feature" should 
be disabled when used in a ham radio environment.

There are two places where this functionality needs to be disabled; the device driver 
and Windows' energy management.

To disable it for each USB interface and device, open Windows settings. (Click the Windows 
icon in the lower left corner and then chose the cogwheel.) Type ''device manager'' and
select the result.

[[image:devicemanager-c.png|none|frame]]

This opens up a new window, Windows' Device Manager.

[[image:devicemanager2b.png|none|frame]]

For '''every''' USB interface component (there may be many), COM-port, and audio device, 
and '''uncheck''' the option ''Allow the computer to turn this device off to save power''.

The devices you are looking for are in the categories: ''Ports (COM & LPT)'', 
''Sound, video and game controllers'', ''Universal serial bus controllers'',

Note that some devices may not have a ''Power Management'' tab.

[[image:usbdevicemanager.png|none|frame]]

The next step is to disable Windows ''Selective suspend'' feature for USB interfaces.

Go back to Windows Settings and type ''edit power'', click the appearing ''Edit power plan'' menu entry.

[[image:editpowerplan2.png|none|frame]]

This should open the window below, the plan editing panel.

[[image:editplansettings.png|none|frame]]

Click ''Change advanced power settings''. Scroll down to ''USB settings'' and make 
sure ''USB selective suspend setting'' is '''disabled''' for all situations.

[[image:Advancedsettings.png|none|frame]]

To prevent audio devices from becoming unreachable or going into sleep mode you should also 
disable exclusive access. While changing this, also make sure all audio enhancements are disabled.

You reach the detailed audio device settings by entering Windows settings, search for Control panel, 
and in the Control panel view, select Hardware and audio, and then Sound.

[[image:Audiodevice.png]]

Reboot your computer to make sure all settings are recognized by Windows.

==Interlock and inband operation==

In contest station terminology, the term ''Interlock'' refers to a technical solution preventing 
more than one station from using a shared resource, typically an antenna, at the same time.

The most common use for interlock is for inband operation. Inband operation means to have multiple 
transmitters on a single band, interleaving their transmissions. Sometimes on a split-second basis.

As long as you never have more than one transmitter active at any time, the majority of contests allow 
an unlimited number of transmitters and receivers on a single band for multi-operator categories. 
This fact is used by most big contest stations.

For an inband solution to be effective, each station must be able to receive while the 
other station transmits. This means it requires a separate, high performance receive antenna 
with very good isolation from the transmitter antenna. The most common way to 
achieve this is physical separation and geographic orientation to minimize the situations 
when they will radiate/listen in the direction of the other antenna.

For a station operating in the M/M, M/S, or M/2 category, inband operation can boost the points 
per hour performance significantly. It is also a lot more fun.

However, as with everything else, it comes at a cost. An efficient inband solution has:

* A high performance receive antenna for each operated band(s) with very good isolation from the transmitter antenna.
* A fail-safe antenna switching hardware.
* Interlock-capable keyers and/or station controllers.
* An interlock-capable contest logging software

A typical inband configuration can be seen in the illustration below.

[[image:inbandconcept-trx.jpg|800px]]

DXLog offers a software-based interlock which can be configured in a variety of ways, e.g. based on frequency 
band, operating mode, or station role. It supports an unlimited number of stations interlocking each other 
using a great variety of strategies.

The interlock relies on UDP networking and is overlaid on the communication for multi-station logging. 
UDP networking has the benefit of speed and low latency but is, unlike TCP, susceptible to packet loss. 
This means that a '''wired LAN''' is a necessity for any station using interlock. 
For the same reason, it is also not recommended to run interlock over e.g. VLAN/VPN link for 
geographically distributed stations.

A software interlock is not 100% reliable. Computer or software malfunction, networking issues such as packet 
loss, etc. can cause interlock to fail, even if only momentarily.

For this reason it is necessary to also accompany a software interlock with a fail-safe '''hardware''' interlock. 
Without hardware supported interlock you run the risk of not only violating contest rules but also cause serious equipment damage. 
Some contests, such as CQ WW, explicitly requires hardware interlock when using multiple stations on the same band.

There are many designs and even commercial products available for hardware interlock. 
One example of a simple but effective two station hardware interlock which also supports 
power amplifier sharing can be found [https://sm7iun.se/contest/inband/ HERE].

The purpose of this section is to describe steps of setting up a basic two station in-band solution with 
DXLog and microHAM keyers. The microHAM keyers are not mandatory but offers a much better user experience 
and removes the need for additional hardware.

'''Pro tip:''' Consider checking <code>Options|Networking|Allow other stations to abort sending</code> 
which will allow your partner station to interrupt your transmission with <code>[Shift][Esc]</code> in 
critical situations. Be careful though, the use of this function requires good judgment to avoid violence.

===Networking===

Open the networking configuration panel with <code>Options|Configure network</code> and make sure each 
station has a unique name and that only UDP networking is enabled.

Make sure the two stations use the same broadcast IP address and that it is in line with your LAN's 
configuration. Pressing the <tt>Default</tt> button is a good way to ensure this.

Make sure the menu option <code>Options|Enable network</code> has a checkmark.

[[image:inbandnetworkrun.png|left|frame]][[image:inbandnetworkinband.png|none|frame]] 

===DXLog Interlock configuration===

First of all, make sure that the <code>Options|Interface specific options|Prevent TX if another radio is on same band</code> 
is '''not''' enabled. This option completely prevents transmission if more than one networked station is set to the same band 
and the whole idea with inband is to have exactly that.

Next, activate software interlock on both stations using the menu option <code>Options|Networking|Software interlock</code> 
or by typing the commmand <tt>ILOCKON</tt>.

[[image:inbandinterlock2.png|none|frame]]

There are multiple options for configuring the interlock. In a simple set up with only two stations, the topmost 
option ''Same band from status list'' is a good choice. This option will prevent more than one station transmitting 
on the same band, regardless of mode.

In an environment with many stations (such as a multi-operator-multi-transmitter station) it is 
recommended to use the bottom option to only interlock with one or several named stations. 
This will reduce both LAN traffic and inband operation latency. This is particularly important when 
running parts of the DXLog network over high latency links such as VLAN/VPN or if some stations (albeit not 
part of the interlock cluster) are connected via Wi-Fi.

For more advanced scenarios you can also use interlock based on mode or station type (e.g. Run 1, Run 2, Mult, etc.).

The "status list" listing the networked DXLog stations is displayed in the ''Status Window'' which is opened 
with <code>Windows|Status window</code> or <code>[Alt][J]</code>.

[[image:inbandstatuslist2.png]]

DXLog also offers great flexibility when it comes to interlock strategy. The most straightforward and 
most commonly used is ''First one wins''. This is also typically the behavior of "unintelligent" 
hardware solutions when not assisted by software. With this strategy, the station starting to transmit 
first can not be interrupted and always gets to finish its transmission.

[[image:inbandinterlockoptions.png]]

With a ''Last one wins'' strategy, the transmitting station can be interrupted. A carte blanche permission 
to interrupt all transmissions by the other station may however be counterproductive in a real contest situation.

For this reason, DXLog offers additional control of which transmit actions can be interrupted and which can not. 
This is a powerful tool but requires both operators to be aware of it and may require 
practice before fully effective.

[[image:inbandstrategyexceptions.png]]

''F1'' through ''F7'', ''PLUS'' and ''INS'' refers to DXLog's standard messages. ''KEYB'' means a free text transmission 
from the keyboard using the <code>[Alt][K]</code> function and ''MAN'' means manual transmission using either paddle 
break-in or a footswitch.

For CW, DXLog recognizes paddle break in from a K1EL Winkey-compatible keyer as described in the [[Menu_Options#Winkey_Configuration|Winkey configuration section]].

Since DXLog recognizes a footswitch connected to a microHAM device, this is a recommended approach for phone. 
It is also possible to connect a footswitch to the DSR pin (pin 6) on a physical COM-port on the PC, but today 
few PC have such a port and it also requires additional circuitry.
Details on how to do this is available [[Additional_Information#Connecting_a_footswitch|HERE]].

===microHAM configuration===

Open the microHAM device configuration panel with <code>Options|microHAM device configuration</code>.

[[image:Mk2r-new9.png|none|frame]]

Check the option ''Enable TX lock/unlock''. This will do two things; it will enable DXLog to prevent 
transmission and and it will make DXLog aware of the microHAM device's PTT status. The latter is particularly 
important since it means DXLog will recognize PTT assertion not only by a footswitch connected to the 
microHAM device but also by the built-in Winkeyer (requires microHAM USB Device Router version 9.3.0 or later) 
'''Paddle-based break-in in an inband solution is currently unique for microHAM with DXLog.'''

'''Important:''' Making DXLog "PTT aware" means that care has to be taken in how PTT is set up. If you, for instance, 
enable DXLog PTT for the voice keyer, this will create a self-reinforcing feedback loop and PTT will thus never drop.

Check the option ''Dual radio device'' if you are using a u2R, MK2R, or MK2R+, otherwise, leave this unchecked.

Check the option ''Device without CAT interface'' if the device lacks a CAT interface (like the u2R) 
or if its CAT interface is not connected to the radio. This option will make sure the e.g. keying and 
audio routing is always set correctly in line with the operating mode (Voice, CW, or RTTY).

===Operating===

Inband operation requires a fair amount of training and it is a good idea to define and agree 
on general rules for operation, such as hand signals for challenging QSO, beforehand.

There are more than enough YouTube videos of inband operators yelling at each other.

The operating tactics may have to be adjusted during the contest. If Run is slow, 
doing S&P on the inband station can increase the points per minute significantly. 
However, if Run is strong, an overly active inband operator doing S&P, but not working 
multipliers, may actually reduce the station's points per minute significantly.

Real-time interlock status is shown in the ''Radio status'' window, which is opened with 
<code>Windows|Radio status</code>.

[[image:inbandblocking.png]] [[image:inbandblocked.png]]

For Phone contesting, you typically rely on footswitches for PTT and the option 
<code>Options|Networking|Show QSO status when blocking</code> makes the blocking 
station send a more helpful blocking cause than ''MAN''.

With this option enabled, the blocking station will instead send ''CQ'', ''QSO'', or ''EXCHANGE'' 
as blocking cause, determined by cursor location and entry field content at the locking station.

Further reading can be found in the [[Menu_Options#microHAM_device_configuration|microHAM device configuration]] and [[Menu_Options#Networking|Networking]] sections.

==Connecting a footswitch==

To free up both hands in Phone contesting, a footswitch PTT is a great help.

Also, to use interlock in Phone contesting, a footswitch is mandatory.

There are two basic ways to interface a footswitch with DXLog; via a microHAM device (which is the recommended solution) 
or directly connected to a physical serial port on the PC (which very few PC have today).

The connection of a footswitch to a microHAM device is very straightforward and by checking the ''Enable TX lock/unlock'' 
in the ''microHAM device configuration'' panel, it is recognized by DXLog.

Lacking a microHAM device, it is also possible to use the computer's DB9 RS-232 serial port connector, providing it has one.

The required steps to do this are:
* Connect a 10k resistor between DB9 pin 6 and pin 7.
* In the port's settings (<code>Options|Configure interfaces</code>) set DTR (pin 4) to ''Always On'' and RTS (pin 7) to ''Always Off'' for the port.
* Connect the footswitch between DB9 pins 4 and pin 6. '''Important:''' Neither pole on the footswitch must be connected to ground.
* In the radio's configuration panel, check ''use CAT PTT command on Phone'' and set ''Footswitch (pin 6)'' to ''PTT''

==Support for CC Cluster==

CC Cluster is today the main choice for contest use.

It offers a high quality, database-verified, flow of skimmer spots and a rapid 3-minute respotting period for skimmer spots.

It also publishes unique spots from less common locations which are valuable for DX chasers or as contest multipliers.

To make use of the display of own spot in the world map, make sure to issue the command '''<tt>SET/OWN</tt>''' to the cluster node. 
This setting is persistent and only needs to be done once.

A list of cluster nodes that runs CC Cluster can be found here: [https://www.dxcluster.info/telnet/index.php?software=CC%20Cluster CC Cluster nodes]

A description of the command line syntax can be found here: [http://bcdxc.org/ve7cc/ccc/CCC_Commands.htm CC Cluster command syntax]

A convenient software for setting up filters etc. can be found here [http://www.bcdxc.org/ve7cc/default.htm#prog CC User]

[[Image:Ccclustersspotflow.png]]

==Support for AR Cluster 6==

With the author tragically SK, AR Cluster is no longer under development but still available as an executable binary.

In its standard configuration, AR Cluster offers no consolidation of skimmer spots meaning a very high flow of spots 
that can become extreme during a major contest weekend.

With the advent of skimmers, the traffic on the DX Cluster has risen dramatically. Even though CW skimmers are generally 
quite reliable, the absolute number of busted spots can be quite high during a busy contest.

Jose CT1BOH has developed an algorithm for evaluating spot quality which is included in version 6 of AR Cluster. 
Today many cluster nodes runs this version and thereby offer this mechanic. 
A complete list can be found here: [http://www.dxcluster.info/telnet/index.php?software=AR-Cluster AR Cluster nodes]

To enable the functionality on a cluster node running AR Cluster 6, the command

<tt>'''SET DX EXTENSION SKIMMERQUALITY'''</tt>

needs to be issued to the cluster node. The easiest way to do this in DXLog is via <code>[Alt][T]</code>. 
This setting will be remembered at subsequent logins.

The quality of the spots is indicated by a character ("tag") in the last column of the comment field and, 
in some cases, a corrected callsign within parenthesis. This syntax is recognized by DXLog and can reduce the 
number of bad spots in your bandmap.

The CT1BOH skimmer quality algorithm is based on three parts:

; Validation : When a callsign is first spotted, it is tagged with "?" in the last column of the spot's comment field. If the callsign of an unverified spot closely resembles an already verified one on the same frequency, the verified callsign is provided within parenthesis in the spot's comment field. When two or more skimmers agree on the spot, it is considered verified and the tag becomes "V".

; Frequency : When a verified spot appears more than 0.35kHz off its verified frequency, the spot is tagged "Q" for QSY. Once verified, this becomes the new verified frequency and it is tagged "V".

; Probability : The algorithm checks uncertain spots for resemblance with already verified spots and spots at or near the same frequency. If the resemblance is high enough, the spot is considered busted "B" and the corrected callsign is provided within parenthesis in the spot's comment field.

Below you can see an example of the spot flow from W9PA-4 with skimmer quality enabled. 
The flow contains one unverified and one busted spot.

[[image:spotquality.png]]

DXLog's policy for spots with CT1BOH skimmer quality tags is the following:

: '''V''' - Accept spot.
: '''Q''' - Accept spot.
: '''?''' - Accept spot. Use corrected call when provided.
: '''B''' - Accept spot if corrected call provided. Else ignore.

DXLog recognizes the skimmer quality tags but consolidates them for consistency 
with other cluster nodes' quality tags and to minimize confusion when mixing spot flows. 
The legend is:

: '''?''' means a spot with ? This is an unreliable spot.
: '''P''' means a spot with Q or B with correction. This is a fairly reliable spot.
: '''V''' means a spot with V. This spot is considered validated.

This basic policy can be modified by using additional filters at the cluster node end. Some examples are:

: <tt>'''SET DX FILTER NOT SKIMBUSTED'''</tt> - Do not send busted spots at all
: <tt>'''SET DX FILTER NOT SKIMQSY'''</tt> - Do not send QSY spots
: <tt>'''SET DX FILTER SKIMVALID'''</tt> - Only send verified spots
: <tt>'''SET DX FILTER NOT SKIMUNKNOWN'''</tt> - Do not send unreliable spots
: <tt>'''SET DX FILTER SKIMMER'''</tt> - Do not send manual spots

You can also compose more complex filters such as:

: <tt>'''SET DX FILTER SKIMVALID OR SKIMBUSTED OR NOT SKIMMER'''</tt>

This can be a good filter for most contests. It will will only provide valid or busted skimmer spots together with manual spots. 
It is safe to receive busted spots since DXLog will ignore them if there is no corrected callsign included. 

For assisted operation in serious contesting you however need to allow also unknown spots since weak stations spotted 
only by one or a few skimmers may never reach validated status. You do this by adding <tt>'''OR SKIMUNKNOWN'''</tt> to the filter.

Both the bandmap and the DX cluster announcement windows have the option to display the spot quality tag. 
These windows will show two additional tags; L and C. L stands for local spot, created by yourself or one of your team members. 
C stands for corrected, i.e., a B or ? spot where a corrected call has been included in the spot's comment field.

The AR6 filtering syntax offers a lot of flexibility. Another example:

: <tt>'''SET DX FILTER (SKIMVALID OR NOT SKIMMER OR ((SKIMQSY OR SKIMUNKNOWN) AND (CTY <> K AND CONT <> EU )))'''</tt>

will provide only validated and human spots except if they are from outside the US and EU.

If you get lost in the filter settings you can always reset with : <tt>'''SET DX DEFAULT'''</tt>.

Some more guidance on how to work with filters on AR-Cluster nodes can be found in [http://dxlog.net/sw/files/utilities/AR_Cluster_v6_User_Manual.pdf this document].

==Support for DXSpider==

DXSpider is the by far most dominant DX cluster software but has historically not been a good choice for contesters. 
The reasons for this include: Long respotting time, lack of pass function for own spots, and suppression of spots from a single skimmer.

The good news is however that the author Dirk G1TLH has worked hard to address these aspects of the otherwise brilliant software.

From '''version 1.57 release 440''' the respotting time is now 3 minutes and there is a <tt>SET/SEEME</tt> command that passes all spots 
without consolidation of your own callsign.

So if your favorite cluster node is not running this version, ask the owner to upgrade asap.

Yet another reason for its popularity is its extreme resource-efficiency which allows it to run virtually 
any Linux capable hardware, including a $20 Raspberry Pi Zero.

A list of all DX cluster nodes running DX Spider can be found here: [https://www.dxcluster.info/telnet/index.php?software=DX%20Spider DX Spider cluster nodes]

[[image:dxspiderflow.png]]

DXLog recognizes the <tt>Q:#</tt> skimmer quality tag in the comment field and converts them into "CT1BOH-like" quality 
tags that can be displayed in DXLog's bandmap. The legend is:

: '''?''' means a spot with Q:1, i.e. heard by only one skimmer. This is an unreliable spot.
: '''P''' means a spot with Q:2, i.e. heard by only two skimmers. This is a fairly reliable spot.
: '''V''' means a spot with Q:3 or higher, i.e. heard by several skimmers. This spot is considered validated.

Since a DXSpider node currently needs to be specially configured by the owner to publish Q:1 spots, very few do this. 
Also, since DXSpider lacks busted call detection, the the quality of the spot flow will suffer if this is done.

There is a wealth of information to be found on the [http://wiki.dxcluster.org/index.php/Main_Page DXSpider wiki].

==Support for N2WQ Cluster==

Introduced in late 2025, Rudy N2WQ has developed the first new DX cluster node software in decades.

The N2WQ-2 cluster has some unique features like a more advanced callsign validation than 
AR 6 and propagation estimation tags embedded in the spot comments. An example can be seen below.

[[image:n2wpspotflow.png]]

When you connect to dxc.n2wq.com port 8300 and you have set your 4-digit Maidenhead grid (SET GRID), there 
will be a single character just before the DX’s grid locator. This character is the path prediction glyph.

It is a crowdsourced, real-time estimate of how reliable the path is between you and the DX on that band right now, 
based on recent on-air propagation reports from RBN and PSKreporter. Its values and meaning are:

: > High: Strong path. If you can hear them, you should be able to work them.
: = Medium: Decent path. Workable with normal contest/DX technique.
: < Low: Weak path. Possible, but expect repeats, timing, and patience.
: - Unlikely: Marginal. Try only if it’s rare/needed, or you have a strong station advantage.

A missing glyph means insufficient data to estimate the path.

the glyph is mode-aware. A path that looks great for a very sensitive mode (FT8) can look 
more moderate for a less sensitive one (SSB).

You can filter spots by path reliability using the PASS/REJECT PATH command.

It is important to be aware that the glyph does not know:

: Your antenna gain/pattern, height, or takeoff angle
: Your transmit power and duty cycle constraints
: Your operating technique (timing, split discipline, pileup strategy)
: Short-lived phenomena the network has not yet “seen” such as sporadic E or aurora.

The cluster ingests upwards of 50,000 CW, FT, RTTY, and WSPR spots per minute. To compare different modes 
fairly, the system normalizes reports onto a common “FT8-equivalent” scale (so a CW SNR can be compared 
to an FT8 SNR).

Your grid and the DX grid are mapped into small geographic cells and the cluster calculates propagation 
at two levels:

: Fine (local): what’s happening close to your area (~180 miles).
:: On averages there are about 90,000 DE/DX pairs being tracked
: Coarse (regional): what’s happening in the broader region around
:: you (~480 miles). On average, there are about 30,000 DE/DX pairs.

If there isn’t enough local data, the system leans more on regional behavior. 
If there’s plenty of local data, it uses that more heavily.

Sometimes you can hear them better than they can hear you (or the reverse) due to noise 
floors, antennas, geography, or ionospheric effects. The system tracks both:

: Receive direction: DX to you (can you hear them?)
: Transmit direction: you to DX (can they hear you?)

It combines these into one “path reliability” estimate, weighting receive a bit more 
because if you can’t hear them, you can’t work them.

Propagation changes fast, so older reports get discounted using a half-life (data fades 
in influence over time). Typical behavior by band:

: Low bands (160/80m): slower changes (longer half-life)
: Mid bands (40–20m): medium pace
: High bands (15–6m): fast changes (shorter half-life)

In practice, this means glyphs can shift in minutes on 10m/6m, and more slowly on 80m/160m. 
Also, new openings take time to show up. A "insufficient" can simply mean “the path just opened 
and the cluster hasn’t collected enough recent reports yet.”

Your local noise floor heavily affects what you can receive, so the cluster lets you tell 
it what your noise environment is. This mainly tunes the receive-side expectation (DX to you).

Set it with SET NOISE SUBURBAN. Available profiles per ITU:

: QUIET: very low noise, rural/remote
: RURAL: mild noise
: SUBURBAN: typical neighborhood QRM
: URBAN: elevated noise, dense housing
: INDUSTRIAL: severe noise

If you don’t set it, the system may assume a quieter environment than you actually 
have, and your receive-side glyphs can look too optimistic.

Treat the glyph as a real-time probability hint that helps you spend your operating 
time where the odds are best. When you see > on a needed multiplier, move fast. 
When you see -, be intentional about whether it’s worth the time. 
And when you see a space, fall back to classic DX/contest instincts and your own ears.

The N2WQ cluster also offers spot quality tags between the DX grid and the time.

A quality (in terms of callsign reliability) tag can be V, P, S, C, or ? where V means validated, 
P highly likely, S less likely, C corrected, and ? unsure.

The propagation and quality tags can be displayed in the bandmaps and the DX cluster announcement window.

DXLog recognizes the skimmer quality tags but consolidates them before display for consistency 
with other cluster nodes' quality tags and to minimize confusion when mixing spot flows. 
The legend is:

: '''?''' means a spot with ? or S. This is an unreliable spot.
: '''P''' means a spot with P or C. This is a fairly reliable spot.
: '''V''' means a spot with V. This spot is considered verified.

==Interacting with WSJT-X==

Important: When in a DXpedition/multi-station setting, always use local host 127.0.0.1 as the 
broadcast address to prevent packets being picked up by other stations in the network. 
Also, enabling the creation of local spots from decodes may overwhelm DXLog.

DXLog can add QSO performed with WSJT-X to its log. Note that this functionality only works 
for contests with grid as the first and only exchange or for DXPedition type logs.

DXLog can also create local spots from WSJT-X decodes by checking 
<code>Options|Broadcast|Spot WSJT-X decodes</code>.

To enable logging of WSJT-X QSO, set up WSJT-X to broadcast information:

[[image:Wsjt-x-udp.png]]

[[image:Radiobroadcastenable3.png]]

Activate DXLog's UDP listener by checking <code>Options|Broadcast|Receive broadcasts</code> and set 
the same port number as in WSTJ-X in DXLog's network configuration panel.

[[image:Dxlog-udp.png]]

==Using Winkey FSK==

Winkey FSK is not natively supported by DXLog's digital mode engines MMVARI or MMTTY but 
Rafal EI6LA has developed a plugin for MMTTY that makes this possible.

You can find it [https://github.com/RafalLukawiecki/WinKeyerMMTY here].

==Interfacing with LogHX==

Christian F8GHE has prepared a guide on how to do this.

You can find it [http://dxlog.net/sw/files/utilities/DXLOG-LogHX_UDP-config_v2.pdf here].

==Self-spotting==

More and more contests allow spotting your own station on the DX cluster.

DXLog supports this, even when operating unassisted, as long as you connect to the cluster.

DXLog has three mechanics for self-spotting.

DXLog blocks self spotting unless specifically allowed in the contest rules. 
Should you find that DXLog incorrectly allows or blocks self-spotting, please make 
the development team aware via the support reflector.

* The <tt>$SPOTME</tt> macro command. This macro will create a cluster spot of the station's
: call at the earliest 15 seconds after being invoked the first time on a new frequency.
: Thereafter it will spot as frequent as allowed by the contest. If the contest rules do not
: specify a minimum period, 10 minutes will be used.

* Checking the menu option <code>Tools|Data entry|Run F1 message self-spots when permitted</code>.
: Works exactly like the <tt>$SPOTME</tt> macro command but is triggered by sending the
: Run F1 message which happens when pressing <code>[Enter]</code> with an empty entry line
: in Run, pressing <code>[F1]</code> in Run, or with Auto-CQ.

* Clicking the menu item <code>Commands|Self-spot</code> or pressing its shortcut key <code>[Ctrl][S]</code>.
: This will immediately create a spot of the station's call but no more often than
: every two seconds to avoid accidental multiple spots.

==DXpedition use==

DXLog is a popular choice for top tier dxpeditions. Below we have collected advice based on experience 
on how to best use DXLog in a dxpedition setting.

* Use client/server networking between stations. Never use UDP over Wi-Fi or WAN links.
* Use the "Minimal data" option in ADIF export to save on satellite link cost.
* For Club Log real time upload, use [https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads Club Log's upload app]
* Club Log truncate QSO time to minutes so to avoid creating dupes when mixing manual and real time upload to Club Log, check ''QSO time in minutes'' when doing ADIF export.
* Use the "Minimal data" option in ADIF export to save on satellite link cost.
* Follow [[Additional_Information#Interacting_with_WSJT-X|the instructions]] to log QSO made with WSJT-X and MSHV.
* Check <code>Options|Broadcast|Spot WSJT-X decodes</code> to make decoded calls appear in e.g., DX cluster announcements.
* You can extend the number of digits in the QSO count with <code>Options|Log|QSO number digits</code>

==Beacon spots on DX cluster==

Although propagation measurements based on FT8 communications has reduced the 
value of beacons, there are still hundreds of them in operation.

Identifying with CW, they are typically reported on reported on the DX cluster.

When beacon spots are received by DXLog, they are always displayed in the bandmap. 
In DXLog, beacon spots are recognized by having a trailing <tt>/B</tt>.

The DX cluster announcement window never shows or counts beacon spots.

Beacon spots can be enabled and disabled in the cluster node.

For CC Cluster, the commands are <tt>SET/BEACON</tt> and <tt>UNSET/BEACON</tt>.

For DXSpider, command is part of the <tt>SET/SKIMMER</tt> command where <tt>SET/SKIMMER</tt> 
or e.g., <tt>SET/SKIMMER CW BCN FT RTTY</tt> will pass beacon spots and <tt>UNSET/SKIMMER</tt> 
or any <tt>SET/SKIMMER</tt> listing modes but not BCN will block them.

AR 6 cluster nodes always pass beacon spots when skimmer spots are enabled. They cannot be disabled.

==Using Piper text-to-speech synthesis==

James M0DST has prepared 7 sample scripts that can be mapped to F keys.

James' comments on the scripts are:

This is just an extended proof of concept. Feel free to play using your own scripts. 
There is a lot of code duplication across the scripts. I may simplify some of this in the future. 
I tried base classes, but the current script engine would need some rework to support that. 
Repeat isn't supported. You will need to press the key manually. 
Multiple op voices are not supported currently. You could hack this in with little effort. 
There is no documentation at present. This feature is experimental whilst I decide how I want 
to move it forward (if at all). If you want to adjust the speed, you can do it per script. 
See SpeakingRate in the F2 script. Lower number is faster.

You can visit https://rhasspy.github.io/piper-samples/ to hear the voices. Set the model in the script.

Any comments or thoughts on anything related to this should be sent to me directly or on the list.

I really suggest training your own voice. I haven't done it yet, but I will when I have time. 
Using common amateur radio phrases in the training data will help teach it to sound more like a ham.

If you improve the scripts, please send them to me and I will update the files behind this link. 
Once everything is stable and formalized I will pass the links to Bjorn for the website, and we 
will add some real documentation.

Experimental scripts:

[[https://drive.google.com/file/d/1EhfOpxsL57yuf-1WorASnGf-SBsmfqu7/view?usp=drive_link F1]]
[[https://drive.google.com/file/d/1MgviBec7HCXIOJZtDZXl0qXlrU-TwMoD/view?usp=drive_link F2]]
[[https://drive.google.com/file/d/1yAgY5E-KdOcmToXMJQ2lRNhjBIQrJIb9/view?usp=drive_link F3]]
[[https://drive.google.com/file/d/1-ftWUhFlc4-quwGPIVmNujQ4q-J5E3EZ/view?usp=drive_link F4]]
[[https://drive.google.com/file/d/1h3C_kLl9C4CEH6kATGAZbfDkfY6KlgqB/view?usp=drive_link F5]]
[[https://drive.google.com/file/d/1e4tAHz-_dU92RybaFeSuLCd0V7Gk_lWy/view?usp=drive_link F6]]
[[https://drive.google.com/file/d/1UGxgOpqOjOzl7yFTjrVaml9m5o8gBq5y/view?usp=drive_link F7]]

Additional Information

2026-04-01T07:08:53Z

Sm7iun:

==Using alternative configurations==

Window positions, coloring and general look and feel is saved in each log file but all other settings such as 
radio control, keying, and networking is saved in a common, contest-independent configuration file.

By default, the configuration file name is <tt>DXLog.net.config</tt> and it is located in the <tt>%appdata%\DXLog.net</tt> configuration folder.

This folder is also reachable via the <code>File|Open configuration folder</code> menu item.

[[image:configfolder.png]]

DXLog can be made to use an alternative configuration file with the command line option <tt>-cfg=<filename></tt>.

A convenient way to use this option is to create a separate Windows desktop shortcut including the command line option 
and give it a meaningful name.

[[image:Desktopshortcut.png]]

The command line option is simply added to the end of the Target text box in the shortcut's properties. 
Double-clicking the icon will start DXLog with the alternative configuration which will also be remembered between sessions. 
In the picture below the target of the shortcut is

[[image:Desktopshortcutconfig.png]]

'''Important:''' If you want to use an alternative configuration, do not just modify the desktop shortcut created at installation 
since this shortcut will be deleted when you upgrade DXLog. Instead make a copy, rename, and add the command line option. 
You should keep the command line option outside the apostrophes, like this

<tt>"C:\Program Files (x86)\DXLog.net\DXLog.net.exe" -cfg=SO2R.config</tt>

==Using a number server==

For contests involving serial numbers you need to secure that the sent number and the (slightly later) 
logged serial numbers are the same. In a straightforward SO1R or SO2V scenario, serial numbers are simply 
chronological but in more complex station configurations such as Multi-single or Multi-2 with inband, and 
advanced SO2R, QSO can be interleaved and requires a central source source of serial numbers together 
with a mechanic to protect an already sent serial number from re-use by another radio.

In DXLog this is achieved with a central number server. A number server can be used either 
by a single instance of DXLog (for SO2R) or by multiple stations on the same LAN.

The use of a number server involves three, natural, steps:

* Activating the server on a single station
* Making sure all stations use it
* Verifying functionality, making sure serial numbers are correctly reserved

The number server is activated in the <code>Options|Configure network</code> panel, described [[Menu_Options#Configure_network|HERE]].

[[image:startnumberserver.png]]

Since the server uses a networking socket, <code>Options|Networking</code> must be enabled '''also''' when 
using a single computer in SO2R. In the case of multiple stations, UDP networking or Client-Server 
networking must also be enabled to transfer the numbers over the LAN. For SO2R, this is however not 
necessary. When using Client-Server networking, a client cannot be number server.

There must only be one number server in a local network and all stations using it must have 
<code>Options|Networking|Use number server</code> checked like in the picture below.

'''Important:''' The number client/server functionality is not very robust. 
If you have stations joining/leaving your network or being rebooted, it is 
best to restart DXLog on all stations to guarantee correct function.

[[image:usenumberserver.png]]

The option <code>Block logging if serial number reservation is unsuccessful</code> can be used as an extra precaution 
but is not necessary in SO2R since the communication with the number server does not leave the computer.

There are three methods for reserving a number from the server:

* Checking <code>Tools|Data entry|Space key reserves serial number</code> and using the space key to reserve serial numbers. This is typically used on phone or when operating "old school" with F-keys.
* Checking <code>Tools|Data entry|Insert and F2 messages reserve serial number</code> and letting DXLog automatically reserve a serial number right before $SERIAL sends it. This is the preferred and most straightforward way for CW and digital.
* Adding the $RESERVENR macro to messages like illustrated below. 

These methods can of course also be combined. 

The $RESERVENR macro is "smart" and will only reserve a serial number if the callsign entry field is not empty and a 
serial number is not already reserved. The same goes for the menu items.

[[image:reservemessages.PNG]]

The sign of a serial number being reserved is that it turns red. It then stays reserved (and red) until the 
QSO is logged or the entry line is cleared with <code>[Alt][W]</code>.

An option that can prove useful is <code>Tools|Data entry|Cancel serial number reservation only if callsign field is empty</code>. 
In the case that you send the exchange and realize you got the other station's callsign call completely wrong, a reflex can be to hit 
<code>[Alt][W]</code> and start typing. If this is your habit, this option will prevent you from releasing the 
already sent serial number, thereby avoiding you the trouble to send a new one to the other station.

[[image:reservednumber.png]]

==Networking over internet==

When, for instance, activating a special event callsign it is possible to network multiple DXLog stations over the internet.

'''Pro tip:''' Consider displaying the callsign, message ID, Message text, etc. fields in the ''Network status'' 
window when operating a distributed station. Also, learn to use the gab <code>[Alt][G]</code> and <code>[Alt][J]</code> function.

===VLAN/VPN Solution===

The most secure way for remote networking is to rely on a VLAN (virtual LAN) software. There are several available such as:

ZeroTier https://www.zerotier.com/ 
FreeLan http://www.freelan.org/ 
Player.me https://player.me/ 
OpenVPN https://openvpn.net/

Each VLAN solutions have their own particular set up which is covered in their respective documentations. 
With a VLAN solution, all DXLog configurations are the same as when operating in a regular LAN however with a few exceptions.

One weakness with connections over the internet (a.k.a. WAN), including VLAN solutions, is that they are prone to packet loss. 
Packet loss is disastrous to DXLog's (or any logger's) "standard" UDP networking.

It is therefore essential to use '''only client/server networking over a VLAN'''. 
'''This also means you should never use interlock over an internet connection unless you use a zero packet loss VPN tunnel.'''

ZeroTier is particularly popular since it is free.

Since DXLog is able to mix TCP (client/server) and UDP (peer-to-peer) networking, a distributed station set up should be configured to rely on TCP 
for the wide-area network and UDP for the local network at each station location. Below you will find the station 
set up for the Swedish HQ station SE9HQ in the 2019 IARU HF Championship. The DXLog.net.DXC cluster client was run 
on SK3W-A which distributed spots to all stations over the network. Inband interlock was also used at the SK3W location.

[[image:SE9HQ-network-eng.png|800px]]

Important to note:

* For the server as well as the main clients, ''Server IP'' should be set to the server's VLAN IP address, '''not''' its LAN address.
* The '''server''' should check both "Act as network server" and "UDP network broadcast for multiple stations".
* The '''main clients''' should check both "Connect to network server" and "UDP network broadcast for multiple stations".
* The '''sub clients''' should check only "UDP networking for multiple stations".
* Interlock (which is UDP-based) over VLAN does not work reliably because of packet loss.
: Therefore, it is important to configure any interlock to '''only''' consider relevant operating positions,
: which all must be local. Use the possibility to only consider named stations for the interlock in the software 
: interlock set up. <code>Options|Networking|Software interlock</code> "Custom station ID(s)"
* For a large set-up with many stations connecting as clients to a central server you may overload the server if you also
: distribute spots via all client-server connections. In this case, check the "No spots via client/server" option
: on all stations and use '''local DX cluster connections''' via UDP at each location.
: '''Important:''' Limitations in Windows networking makes client/server networking unreliable beyond 10 station locations.
* Make sure to check <code>Options->Load contest at startup</code> to avoid opening the wrong log after a restart.
* '''Remote commands are not forwarded''' in the network but are executed in the station where they arrive.
: Thus, to clear all logs, disconnect networking on each main client, execute the remote command CLEARLOGNOW on each main client
: to clear the logs of all sub clients and do not reconnect until the server and all other main clients have done the same.

===Port forwarding Solution===

If you are less worried about competitors or government agencies listening in on your contest data, 
it is possible to route the traffic directly over the internet using port forwarding at the server.

'''Important security notice: This solution is not without risk. It offers no security or authentication. 
Any DXLog station running the same contest configuration, knowing the URL or IP address and IP port of the 
server can connect to the server station. There are no means to disconnect a station by force.'''

Also note the comment about '''remote commands''' in the section above.

With a port forwarding solution, the following must be observed:

* '''Server configuration'''
:* Only one of the stations should be configured as the '''server'''.
:* "Connect to network server" should not be checked on this station and
:: "UDP networking for multiple stations" should only be enabled if it is used to
:: communicate with a cluster client or other stations locally on the same LAN.
:: Either use a central cluster connection (uncheck "No spots via client/server")
:: or use one cluster connection per station location (check "No spots via client/server").
:: If one cluster connection per station location is used, make sure they
:: all use different SSID to prevent disconnects, such as E7HQ-1, E7HQ-2, etc.
:: This will ensure the cluster node regards all connections as having the same callsign
:: which is essential for e.g., correctly receiving own spots.
:* The PC acting as server must be configured for a fixed LAN IP address. This is done
:: either by manually configuring the networking settings in the PC to use a fixed
:: LAN IP address, or by setting up the router in the server's LAN to to always allocate
:: the same IP address to it.
:* The internet connection used by the server PC must ''either'' have a fixed public IP address ''or''
:: use dynamic DNS. Otherwise clients will not be able to reliable connect over the internet.
:* The server's TCP/IP port (e.g., <code>9888</code>) must be forwarded to the server by the server LAN's router.
:: Only TCP traffic should be forwarded. DXLog UDP traffic is not carried well over the internet.

:: [[image:serverconfig.png|600px]]
:: '''Example configuration for server for networking over internet'''

::[[image:portforwarding.png|600px]]
::'''Example of port forwarding UI in router'''

* '''All other stations'''
:* All other PC in the multi-station set up should be set up as clients.
:* Over the internet, "Server:" is either the static, public IP address of the server's internet
:: connection (e.g. <code>5.140.211.42</code>) or the dynamic DNS address (e.g. <code>hq.sm7iun.se</code>).
:: Clients connecting over the internet does not have to enable UDP networking and ''should not''
:: enable a server.
:* A client may connect via UDP if it is on the same LAN as the server ''or'' a "main client".
:: A "main client" is a client that connects to the server using the "Connect to network server" option in
:: the networking set up panel. A "main client" acts as a UDP gateway which means that if
:: several computers on a LAN are part of the same multi station set up but the server is located
:: elsewhere, only one computer in that LAN needs to connect as a client and the rest can use UDP.
:* Software interlock is UDP-based and can only reliably be used locally. Never over the internet.
:: If used, make sure the interlock is explicitly limited to local stations. See above for more details.

::[[image:clientconfig.png|600px]]
::'''Example configuration of client for networking over internet'''

* In a multi-station setting it is recommended to enable
: <code>Options|Networking|Block standard messages if no operator is logged on</code>
* Make sure <code>Options|Enable network</code> is checked.
* It is also a very good idea to check <code>Options|Load contest at startup</code> to reduce the
: risk of the wrong contest log file being loaded by any stations.

==Real time upload to Club Log Live Stream==

'''Important:''' Club Log truncates QSO time to minutes which means that if you mix real time upload 
with manual upload, make sure to check "QSO time in minutes" when creating ADIF export files.

The author of Club Log, Michael Wall, G7VJR, has developed a very powerful agent for real time uploads. 
It works with all the three major loggers, DXLog, N1MM Logger+, and Win-Test.

It can either be used as is, with a command line user interface, or with an optional user interface front end.

Information on how to download and configure it can be found [[https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads HERE]]

The Club Log Gateway can either listen to DXLog's native multi-station networking protocol or to N1MM style XML broadcast.

To use DXLog's networking protocol, make sure the same port (default 9888) is used in the gateway and DXLog 
and that UDP networking is enabled in DXLog. Do not enable QSO broadcast.

Although this works, it is recommended to use N1MM style broadcast since it contains information like logged on operator, etc.

To use this make sure the port (default 12060) is the same in N1MM port setting in the gateway and in the 
QSO broadcast port settings in DXLog's network configuration. Also make sure to se the DXLog port number 
in the gateway is not the same as that used in DXLog to avoid QSO duplication.

Also set:

<code>Options|Broadcast|QSOs</code> 
<code>Options|Broadcast|QSOs</code> 
<code>Options|Broadcast|Use N1MM QSO format</code> 
<code>Options|Broadcast|QSO time in minutes only</code>

'''Important:''' If you are going to also upload exported ADIF files to Club Log, it is important to also 
check "QSO time in minutes" in the ADIF export configuration to avoid creating virtual dupes, since Club 
Log does not know seconds.

==Diversity reception==

Diversity means receiving the same signal through two different receive chains, including antenna. 
With two antennas having different characteristics this can give substantial benefits in receiving 
fading and/or weak signals or separating calls in a large pile-up. Particularly on low bands.

DXLog supports diversity operation on a selected number of radio models.

For the supported radios, diversity operation can be toggled on and off using <code>[Ctrl][-]</code> or <code>[Ctrl][Keypad -]</code>.

If enabled via the radio's controls, DXLog will automatically detect diversity operation and enable 
the necessary mechanics. Diversity operation is indicated by a small DIV icon in the frequency 
counter box for the radio's band map.

'''Yaesu FTDX101D

Yaesu calls this feature "Sync" and it has a dedicated button up and left of the main VFO knob. 
Enabling this will make DXLog update both VFO with the same information when grabbing spots. 
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO. 
Since both VFO are kept on the same frequency, split operation is not supported.

'''ICOM IC-7851 and IC-7610

ICOM calls this feature "Tracking" and it can be enabled either via a menu entry or a long press on the "MAIN/SUB" button. 
Enabling this will make DXLog update both VFO with the same information when grabbing spots. 
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO. 
Since both VFO are kept on the same frequency, split operation is not supported.

'''Elecraft K3/K3S/K4

Elecraft calls this feature by its proper name. It is enabled by a long press on the "Sub" button. 
It should be noted that Elecraft's implementation where the main VFO controls both the main and 
sub receivers allows for split operation, i.e. transmitting on a different frequency using VFO B.

==UDP broadcast==

For interaction with other applications, DXLog can broadcast useful information as 
XML datagrams over UDP. 

There are five types of broadcast messages produced by DXLog:

* QSO information. Sent when logging.
* Radio information. Sent at changes as well as periodically.
* Antenna direction information. Sent when rotor control is invoked.
* Callsign look-up information
* Spots

QSO can be broadcasted in traditional DXLog format or in a more N1MM-like format.

Radio information can report SO2V as a single physical radio or as two physical radios, like N1MM.

There is an option to truncate the broadcasted QSO time to full minutes for better 
interoperability with some online services and software such as MSHV.

In addition, DXLog can also recognize QSY commands from Waterfall Bandmap and log QSO done as well as create 
local spots from decodes broadcasted by WSJT-X and its forks.

The broadcasting of QSO and radio related data is enabled using the <code>Options|Broadcast</code> submenu.

The broadcasting of spots is enabled by checking <code>Options|DX Cluster|Send spots to SmartSDR</code>.

[[image:radiobroadcastenable3.png]]

[[image:sendspotstosmartsdr.png]]

UDP broadcast parameters are configured in the <code>Options|Network configuration</code> panel. 
Please note that up to three ports can be specified for each broadcast, thereby supporting 
multiple receivers of the information.

[[image:Networksettingsbroadcast3.png]]

If you are writing a C# application to make use of these datagrams, there is a very nice online tool 
for creating an object from a sample XML datagram here https://xmltocsharp.azurewebsites.net/ 

In C# parsing is easily done using Linq. One example of XML parsing and deserialization using Linq 
can be found here https://github.com/bjornekelund/ICOMautomagic

===QSO information===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program
|-
| qsoid
| A unique string for this QSO. If this QSO is edited another contactinfo message will be sent with the same qsoid. Note that the qsoid is only unique within one instance of DXLog. If the computer is networked to others running DXLog the different computers may have a different qsoid for the same QSO.
|-
| contestname
| The name of the contest as it would be written to a Cabrillo file.
|-
| timestamp
| The UTC date and time of the QSO.
|-
| mycall
| The callsign of this station.
|-
| band
| The band on which the QSO was made. In MHz with period as decimal separator.
|-
| txfreq
| The frequency on which the QSO was made.
|-
| operator
| The callsign of the operator if the OPON command was used to set it, otherwise blank.
|-
| mode
| The mode used for the QSO.
|-
| call
| The callsign of the station worked.
|-
| countryprefix
| The DXCC country of the station worked.
|-
| wpxprefix
| The WPX prefix of the station worked.
|-
| snt
| The RST sent. This is always included whether or not the contest exchange contains an RST.
|-
| rcv
| The RST received. This is always included whether or not the contest exchange contains an RST.
|-
| nr
| The number sent if the exchange uses a serial number, otherwise the QSO number from this station.
|-
| exch1
| The first element in the contest exchange if any.
|-
| exch2
| The second element in the contest exchange if any.
|-
| exch3
| The third element in the contest exchange if any.
|-
| exch4
| The fourth element in the contest exchange if any.
|-
| xqso
| True if this QSO should not be counted towards the score.
|-
| invalid
| True if this QSO is invalid, for example a DX QSO in a domestic contest.
|-
| duplicate
| True if this QSO is a dupe (the station has previously been worked).
|-
| rule10broken
| True if this QSO breaks the 10 minute or similar rule. Note that a QSO may not break the 10 minute rule when it is logged but may later if another QSO is edited. This may not cause a broadcast.
|-
| azimuth
| The approximate direction of the station worked, in degrees.
|-
| distance
| The approximate distance of the station worked, in kilometers.
|-
| stationid
| The station ID of the station which made the QSO.
|-
| stationqso
| A unique QSO ID generated by the logging station. The combination of stationid and stationqso forms a unique identifier for the QSO.
|-
| stationtype
| The type of station - R for run, R1 for run 1 etc.
|-
| local
| True if this broadcast is due to this QSO being logged or edited on this computer.
|-
| runqso
| True if QSO logged in Run, false if S&P, and empty if unknown. '''Important:''' Only valid when local is True.
|-
| mult1
| The name of the multiplier if this station is a new multipllier, empty otherwise.
|-
| mult2
| The name of the multiplier if this station is a new multiplier, emtpy otherwise.
|-
| mult3
| The name of the multiplier if this station is a new multiplier, empty otherwise.
|-
| points
| The logged points for the QSO.
|-
| period
| The number of the operating period.
|-
| guid
| The GUID in hex format.
|-
| newqso
| True if a new QSO, False if this message is an update to an existing QSO.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<contactinfo>
<logger>DXLog v2.4.13</logger>
<qsoid>19</qsoid>
<contestname>ARRL-SS-CW</contestname>
<timestamp>2020-01-13 18:28:07</timestamp>
<mycall>SM7IUN</mycall>
<band>3.5</band>
<txfreq>352376</txfreq>
<operator></operator>
<mode>CW</mode>
<call>K4BAI</call>
<countryprefix>K</countryprefix>
<wpxprefix>K4</wpxprefix>
<snt>599</snt>
<rcv>599</rcv>
<nr>19</nr>
<exch1>076</exch1>
<exch2>B</exch2>
<exch3>54</exch3>
<exch4>GA</exch4>
<xqso>False</xqso>
<invalid>False</invalid>
<duplicate>False</duplicate>
<rule10broken>False</rule10broken>
<azimuth>225</azimuth>
<distance>1388</distance>
<stationid>STN1</stationid>
<stationqso>19</stationqso>
<stationtype>R1</stationtype>
<local>True</local>
<runqso>True</local>
<mult1>GA</mult1>
<mult2></mult2>
<mult3></mult3>
<points>3</points>
<period>1</period>
<guid>11223344556677889900aabbccddeeff</newqso>
<newqso>True</newqso>
</contactinfo>
</pre>

Alternative N1MM format

Note that the band name uses the computer's local number format so it may use either comma 
or period as decimal separator. The ID is a number rather than an alphanumeric string.

Also note that IsRunQSO is only valid when IsOriginal is True.

<pre><?xml version="1.0" encoding="utf-8"?>
<contactinfo>
<app>N1MM</app>
<contestname>CWOps</contestname>
<timestamp>2020-01-17 16:43:38</timestamp>
<mycall>SM7IUN</mycall>
<band>3.5</band>
<rxfreq>352519</rxfreq>
<txfreq>352519</txfreq>
<operator></operator>
<mode>CW</mode>
<call>K1XM</call>
<countryprefix>K</countryprefix>
<wpxprefix>K1</wpxprefix>
<stationprefix>K1XM</stationprefix>
<continent>NA</continent>
<snt>599</snt>
<sntnr>5</sntnr>
<rcv>599</rcv>
<misctext></misctext>
<ismultiplier1>1</ismultiplier1>
<ismultiplier2>0</ismultiplier2>
<ismultiplier3>0</ismultiplier3>
<points>l</points>
<radionr>l</radionr>
<run1run2>1<run1run2>
<IsOriginal>False</IsOriginal>
<NetBiosName>DESKTOP-23AB</NetBiosName>
<IsRunQSO>0</IsRunQSO>
<StationName>STATION_B</StationName>
<ID>23</ID>
<IsClaimedQso>true</IsClaimedQso>
</contactinfo>
</pre>

===Radio information===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| The name of the logging program.
|-
| logger
| The name and version of the logging program.
|-
| Station
| The ID of the station.
|-
| RadioNr
| The radio being described.
|-
| Freq
| The receiving frequency.
|-
| TXFreq
| The transmitting frequency
|-
| InactiveFreq
| The frequency of the VFO not receiving.
|-
| Mode
| The reported radio's mode.
|-
| OpCall
| The callsign of the operator if the OPON command was used to set it, otherwise blank.
|-
| mycall
| The callsign of the station.
|-
| IsRunning
| "True" if the station is running, "False" if search and pounce.
|-
| FocusEntry
| The Windows handle for the focused entry window.
|-
| Antenna
| Antenna number.
|-
| Rotors
| Rotators used by selected antenna (not currently used by DXLog).
|-
| FocusRadioNr
| The radio which has keyboard focus. In SO2V with "Report SO2V as two radios" checked, radio 2 is the sub/B VFO.
|-
| IsStereo
| True if headphones are listening to two radios.
|-
| IsSplit
| True if radio is set to split.
|-
| ActiveRadioNr
| The radio which is transmitting, if any.
|-
| Technique
| SO1R, SO2R, SO2R_ADV, or SO2V
|-
| StationType
| Station role: R, M, R1, R2, or R+.
|-
| isTransmitting
| True if a DXLog is transmitting. False if DXLog is not aware of transmission.
|-
| IFFrequency
| Optional element only used with Elecraft K3/K4. Contains the current IF frequency in Hz.
|-
|}

Important note: In SO2V the format differs from some other loggers and is:

: Only physical radio 1 is reported.
: <tt>Freq</tt> and <tt>TXFreq</tt> are the frequency of the currently focused VFO.
: <tt>InactiveFreq</tt> is the frequency of the currently unfocused VFO.
: <tt>ActiveRadio</tt> is always 1.
: <tt>FocusedRadioNr</tt> is 1 when the main/A VFO is focused, 2 otherwise.
: <tt>IsSplit</tt> is always false.

With the option "Report SO2V as two radios" checked, the reporting is similar to some other loggers and is:

: The two VFO are reported as two physical radios.
: <tt>Freq</tt> and <tt>TXFreq</tt> for radio 1 are the frequency of the main/A VFO.
: <tt>Freq</tt> and <tt>TXFreq</tt> for radio 2 are the frequency of the sub/B VFO.
: <tt>InactiveFreq</tt> is the frequency of the other VFO.
: <tt>ActiveRadio</tt> and <tt>FocusedRadioNr</tt> are 1 when the main/A VFO is focused, 2 otherwise.
: <tt>IsSplit</tt> is always false.

Example message:

<pre><?xml version = "1.0"?>
<RadioInfo>
<app>DXLog</app>
<logger>DXLog v2.4.13</logger>
<Station>STN1</Station>
<RadioNr>1</RadioNr>
<Freq>704000</Freq>
<TXFreq>704000</TXFreq>
<InactiveFreq>702500</InactiveFreq>
<Mode>CW</Mode>
<OpCall>K1XM</OpCall>
<mycall>HQ9X</mycall>
<IsRunning>False</IsRunning>
<FocusEntry>591124</FocusEntry>
<Antenna>1</Antenna>
<Rotors>ABC</Rotors>
<FocusRadioNr>1</FocusRadioNr>
<IsStereo>False</IsStereo>
<IsSplit>False</IsSplit>
<ActiveRadioNr>1</ActiveRadioNr>
<Technique>SO2R</Technique>
<StationType>R1</StationType>
<IsTransmitting>False</IsTransmitting>
<IFFrequency>8215000</IFFrequency>
</RadioInfo>
</pre>

===Antenna direction===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program.
|-
| station
| The ID of the station.
|-
| radio
| The radio associated with the rotator.
|-
| go
| True if the rotator should be turned.
|-
| stop
| True if the rotator should be stopped if it is turning.
|-
| azimuth
| The direction to turn the rotator if go is True.
|-
| frequency
| The transmit frequency of the specified radio.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<Rotator>
<logger>DXLog v2.4.13</logger>
<station>STN1</station>
<radio>2</radio>
<go>True</go>
<azimuth>252</azimuth>
<frequency>2800200</frequency>
</Rotator>

</pre>
<pre><?xml version="1.0" encoding="utf-8"?>
<Rotator>
<logger>DXLog v2.4.13</logger>
<station>STN1</station>
<radio>2</radio>
<stop>True</stop>
<frequency>2800200</frequency>
</Rotator>
</pre>

===Callsign lookup===

Sent either when callsign in entry row is changed or when space or tab is pressed.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program.
|-
| contestname
| The name of the contest.
|-
| mycall
| Station's call
|-
| band
| Current band
|-
| txfreq
| Transmitter frequency
|-
| operator
| The call sign of the logged in operator
|-
| mode
| Operating mode
|-
| call
| Call entered in the logging field
|-
| countryprefix
| DXCC entity prefix
|-
| wpxprefix
| WPX prefix
|-
| azimuth
| Short path antenna direction
|-
| distance
| Distance in km
|-
| stationid
| The ID of the station sending the datagram
|-
| stationtype
| The role of the station sending the datagram; R, R1, R2, M, or R+
|-
| period
| Contest period
|-
| reason
| Reason for transmission; SpaceOrTab or CallChanged
|-
|}

Example message:

<pre><?xml version = "1.0"?>
<lookupinfo>
<logger>DXLog v2.4.20</logger>
<contestname>DARC-WAEDC-CW</contestname>
<mycall>K1XM</mycall>
<band>20</band>
<txfreq>1400200</txfreq>
<operator></operator>
<mode>CW</mode>
<call>E7DX</call>
<countryprefix>E7</countryprefix>
<wpxprefix>E7</wpxprefix>
<azimuth>54</azimuth>
<distance>6824</distance>
<stationid></stationid>
<stationtype>R</stationtype>
<period>1</period>
<reason>SpaceOrTab</reason>
</lookupinfo>
</pre>

===Spot===

Sent for every incoming spot from the DX cluster that is valid for the current contest.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| Application sending the message.
|-
| StationName
| The station issuing the broadcast.
|-
| dxcall
| The callsign of the spotted station.
|-
| frequency
| Frequency in kHz with decimal sign of the PC's current locale. (sic)
|-
| spottercall
| The callsign of the spotter. Station name if locally spotted or result of a logging operation.
|-
| timestamp
| Spot time in format yyyy-MM-dd HH:mm:ss
|-
| action
| add or delete.
|-
| mode
| actual or guessed mode of the spot in capitals.
|-
| comment
| The comment section of the spot.
|-
| status
| Spot status. Valid values are "dupe", "double mult", "single mult", and "new qso".
|-
| statuslist
| Same as status
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<spot>
<app>DXLog.net</app>
<StationName>CONTEST-PC</StationName>
<dxcall>E7DX</dxcall>
<frequency>14022.3</frequency>
<spottercall>SM7IUN-#</spottercall>
<timestamp>2O23-07-15 14:29:37</timestamp>
<action>add</action>
<mode>CW</mode>
<comment>CW 31 DB 42 WPM CQ</comment>
<status>single mult</status>
<statuslist>single mult</statuslist>
</spot></pre>

===Broadcast listener===

DXLog also listens for commands over UDP.

Currently only one command is implemented, <code><radio_setfrequency></code>, which is a QSY command.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| Application sending the command
|-
| radionr
| The radio to be changed. In SO2V radio 2 means VFO B. Optional as of DXLog 2.5.20.
|-
| frequency
| Requested frequency. Both period and comma is accepted as decimal separator.
|-
| mousebutton
| Which mouse button was used to create message, if any. Optional.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<radio_setfrequency>
<app>WaterfallBandmap</app>
<radionr>1</radionr>
<frequency>21022.194</frequency>
<mousebutton>Left</mousebutton>
</radio_setfrequency>
</pre>

==SDR integration==

===HDSDR, OmniRig, and microHAM===

''Contributed by Ingo SM5AJV/SE5E''

Until DXLog offers SDR integration there are still ways to get a waterfall/spectrum display with DXLog.

I have integrated the free SDR software [http://www.hdsdr.de/ HDSDR] with DXLog using
[http://www.microham.com Microham Device Router], 
[http://dxatlas.com/OmniRig/ OmniRig]
and [https://www.autohotkey.com/ AutoHotkey].

As illustrated below I place the HDSDR window at the very top of the desktop with DXLog right below.

I share my transceiver's (an Elecraft K3) antenna with the SDR. The receiver antenna signal from my 
K3's RX-ANT OUT is connected to the input of a 3dB power splitter. The two outputs from the splitter 
are connected RX-ANT IN on the K3 and the SDR Receiver antenna input, respectively. On a K3 you 
need to enable the RX-antenna input to make this to work. An additional benefit with this method 
is that the SDR is protected during transmission. It is a widely used method and is e.g. described 
by Bob N6TV in this
[http://dxlog.net/sw/files/utilities/Adding%20an%20SDR%20to%20an%20SO2R%20Station.pdf presentation].

'''Screenshot of my desktop:

[[Image:Sdrdesktop.png|800px]]

Since both DXLog and HDSDR need to communicate with the radio, you need to "split" 
the CAT communication. microHAM's USB Device Router provides a second, independent, 
CAT port that can be used via HDSDR's omniRig interface.

'''"PORT" Tab on microHamRouter:

[[Image:Sdrmicrohamrouter.png|800px]]

'''OmniRig settings in HDSDR:

[[Image:Sdromnirig.png|200px]]

With this set up, the radio, DxLog, and HDSDR will be fully synchronized. For instance, you can 
click in the waterfall to make the radio QSY, and it is easy to quickly find a clean frequency.

To make the integration even better I use a small AutoHotkey script. The script pulls entry focus 
back to DxLog after clicking on the HDSDR waterfall and in DXLog it allows you to use hotkeys to 
control HDSDR. <code>[Ctrl][Alt]+</code> and <code>[Ctrl][Alt]-</code> zooms the waterfall/spectrum 
in and out, and <code>[Ctrl][Alt]C</code> centers it.

'''AutoHotkey script:

SetTitleMatchMode, 2
#InstallKeybdHook
#IfWinActive, HDSDR
{
F4:: return ; disable F4
~LButton Up::
sleep, 1
Winactivate, DXLog
return
}
#IfWinActive, DXLog
{
^!+:: ControlSend ,, ^{+}, HDSDR
^!-:: ControlSend ,, ^{-}, HDSDR
^!c:: ControlSend ,, {c}, HDSDR
}

The script can be downloaded [http://DXLog/sw/files/utilities/dxlog_hdsr.ahk here].

If you start two instances of HDSDR with two different SDR you can even have two waterfalls 
running at the same time.

I have not yet found a way to display cluster spots in the HDSDR spectrum panel. 
But I still find it very useful to check band activity and it allows me to easily find 
a new Run frequency on a crowded band.

===Waterfall Bandmap===

The free waterfall/spot display utility "Waterfall Bandmap" by Steve N2IC is supported by DXLog.

Waterfall Bandmap supports almost any SDR that produce I/Q output either via ExtIO.DLL or a 
sound card; SDRPlay, FunCubeProPlus, HackRF, SDR-IQ, RTLSDR, SoftRock, etc.

A zip file with an executable binary and a Microsoft word document with installation and 
configuration instructions can be found here: https://groups.io/g/waterfallbandmap/files

If you are not a member of the support forum group, you need to apply for membership to download. 
Membership is free.

[[Image:Waterfallbandmap.png]]

The SDR can be connected either to a separate receive antenna, an external receiver output on 
your transceiver or to an IF output, should your transceiver have one. If connected to an antenna, 
keep in mind that you may need protection from the transmitter such as a T/R relay or a passive level limiter.

Please refer to Waterfall Bandmap's documentation for setting it up with your SDR.

Waterfall Bandmap needs two information feeds over UDP: Radio information and spot information. 
Both are provided as UDP broadcast by DXLog.

The default port for both is 13063 and this needs to be set in DXLog's Network configuration panel. 
If Waterfall Bandmap runs on the same computer as DXLog, the broadcast address can be left at the default 127.0.0.1.

[[Image:Setbroadcastportsforwfbandmap.png]]

Clicking on the waterfall display can set the frequency of DXLog. (Left click sets VFO A, right click sets VFO B.) 
To enable this functionality, check the option <code>Options|Broadcast|Receive Broadcasts</code> 
Also make sure "UDP broadcast listener" includes port 13064 in the network settings panel.

The radio information feed needs to be enabled by checking the <code>Options|Broadcast|Radio information</code> option

[[Image:radiobroadcastenable2.png]]

and the spot feed needs to be enabled by checking the <code>Options|DX Cluster|Send spots to SmartSDR</code> option.

[[Image:Enablesendspotstosmartsdr.png]]

==Time synchronization==

In a multi-station setting, the time needs to be accurately synchronized across all networked PC.

Windows' built in time synchronization is very crude and for a PC with poor clock stability the 
inaccuracy of the clock may be up to a minute. Which of course is not acceptable for contesting.

DXLog has built in support for time synchronization as described in the [[Menu Options#Configure network|Configure network section]].

Due to Windows' security system, this however requires all except the PC running as time server to 
run DXLog with elevated permissions. There is unfortunately no way around this inconvenience.

An equally accurate and less intrusive method is to use a standalone time synchronization application on each networked PC. 
This will keep each PC's clock accurate within a fraction of a second.

Contrary to a solution built into a logger it also has the great benefit of being an "install and forget" solution.

A popular application is Dimension 4 by Thinking Man Software. It is free for personal use and 
can be downloaded here: https://dxlog.net/sw/files/utilities/d4time531.msi

It runs in the background and only shows up as a tiny icon in your system tray. 
You hover the mouse above the icon to check status and right-click to open and change settings.

:::[[image:dimension4tray.png|50px]]

After installation a brief configuration is required.

First of all, allow the application to disable Windows' time service and to modify your system clock.

For maximum accuracy, select a time server geographically close to your location. 
When in doubt, you can always add the global server "pool.ntp.org" to the list and use that. 

There are also national and continental pools of time servers. You can find them here https://www.ntppool.org.

[[image:dimension4b.png]]

Make sure the check boxes "Load Dimension 4 at startup", "Start minimized", "Hide when minimized", 
and "Display icon in tray" are all checked.

[[image:dimension4advanced.png]]

Click the Advanced button and also make sure the option "Use the selected server" is selected.

Make sure the application reports a successful connection to the selected time server. 
From here on, you can basically forget the application. 
It will silently start with your PC and always keep its time accurate.

==Disabling USB power management==

In the interest of saving energy, Windows habitually power down USB interfaces 
when it believes there is inactivity. Some USB-to-serial and USB audio devices 
respond poorly to being suspended or powered down so as a rule this "feature" should 
be disabled when used in a ham radio environment.

There are two places where this functionality needs to be disabled; the device driver 
and Windows' energy management.

To disable it for each USB interface and device, open Windows settings. (Click the Windows 
icon in the lower left corner and then chose the cogwheel.) Type ''device manager'' and
select the result.

[[image:devicemanager-c.png|none|frame]]

This opens up a new window, Windows' Device Manager.

[[image:devicemanager2b.png|none|frame]]

For '''every''' USB interface component (there may be many), COM-port, and audio device, 
and '''uncheck''' the option ''Allow the computer to turn this device off to save power''.

The devices you are looking for are in the categories: ''Ports (COM & LPT)'', 
''Sound, video and game controllers'', ''Universal serial bus controllers'',

Note that some devices may not have a ''Power Management'' tab.

[[image:usbdevicemanager.png|none|frame]]

The next step is to disable Windows ''Selective suspend'' feature for USB interfaces.

Go back to Windows Settings and type ''edit power'', click the appearing ''Edit power plan'' menu entry.

[[image:editpowerplan2.png|none|frame]]

This should open the window below, the plan editing panel.

[[image:editplansettings.png|none|frame]]

Click ''Change advanced power settings''. Scroll down to ''USB settings'' and make 
sure ''USB selective suspend setting'' is '''disabled''' for all situations.

[[image:Advancedsettings.png|none|frame]]

To prevent audio devices from becoming unreachable or going into sleep mode you should also 
disable exclusive access. While changing this, also make sure all audio enhancements are disabled.

You reach the detailed audio device settings by entering Windows settings, search for Control panel, 
and in the Control panel view, select Hardware and audio, and then Sound.

[[image:Audiodevice.png]]

Reboot your computer to make sure all settings are recognized by Windows.

==Interlock and inband operation==

In contest station terminology, the term ''Interlock'' refers to a technical solution preventing 
more than one station from using a shared resource, typically an antenna, at the same time.

The most common use for interlock is for inband operation. Inband operation means to have multiple 
transmitters on a single band, interleaving their transmissions. Sometimes on a split-second basis.

As long as you never have more than one transmitter active at any time, the majority of contests allow 
an unlimited number of transmitters and receivers on a single band for multi-operator categories. 
This fact is used by most big contest stations.

For an inband solution to be effective, each station must be able to receive while the 
other station transmits. This means it requires a separate, high performance receive antenna 
with very good isolation from the transmitter antenna. The most common way to 
achieve this is physical separation and geographic orientation to minimize the situations 
when they will radiate/listen in the direction of the other antenna.

For a station operating in the M/M, M/S, or M/2 category, inband operation can boost the points 
per hour performance significantly. It is also a lot more fun.

However, as with everything else, it comes at a cost. An efficient inband solution has:

* A high performance receive antenna for each operated band(s) with very good isolation from the transmitter antenna.
* A fail-safe antenna switching hardware.
* Interlock-capable keyers and/or station controllers.
* An interlock-capable contest logging software

A typical inband configuration can be seen in the illustration below.

[[image:inbandconcept-trx.jpg|800px]]

DXLog offers a software-based interlock which can be configured in a variety of ways, e.g. based on frequency 
band, operating mode, or station role. It supports an unlimited number of stations interlocking each other 
using a great variety of strategies.

The interlock relies on UDP networking and is overlaid on the communication for multi-station logging. 
UDP networking has the benefit of speed and low latency but is, unlike TCP, susceptible to packet loss. 
This means that a '''wired LAN''' is a necessity for any station using interlock. 
For the same reason, it is also not recommended to run interlock over e.g. VLAN/VPN link for 
geographically distributed stations.

A software interlock is not 100% reliable. Computer or software malfunction, networking issues such as packet 
loss, etc. can cause interlock to fail, even if only momentarily.

For this reason it is necessary to also accompany a software interlock with a fail-safe '''hardware''' interlock. 
Without hardware supported interlock you run the risk of not only violating contest rules but also cause serious equipment damage. 
Some contests, such as CQ WW, explicitly requires hardware interlock when using multiple stations on the same band.

There are many designs and even commercial products available for hardware interlock. 
One example of a simple but effective two station hardware interlock which also supports 
power amplifier sharing can be found [https://sm7iun.se/contest/inband/ HERE].

The purpose of this section is to describe steps of setting up a basic two station in-band solution with 
DXLog and microHAM keyers. The microHAM keyers are not mandatory but offers a much better user experience 
and removes the need for additional hardware.

'''Pro tip:''' Consider checking <code>Options|Networking|Allow other stations to abort sending</code> 
which will allow your partner station to interrupt your transmission with <code>[Shift][Esc]</code> in 
critical situations. Be careful though, the use of this function requires good judgment to avoid violence.

===Networking===

Open the networking configuration panel with <code>Options|Configure network</code> and make sure each 
station has a unique name and that only UDP networking is enabled.

Make sure the two stations use the same broadcast IP address and that it is in line with your LAN's 
configuration. Pressing the <tt>Default</tt> button is a good way to ensure this.

Make sure the menu option <code>Options|Enable network</code> has a checkmark.

[[image:inbandnetworkrun.png|left|frame]][[image:inbandnetworkinband.png|none|frame]] 

===DXLog Interlock configuration===

First of all, make sure that the <code>Options|Interface specific options|Prevent TX if another radio is on same band</code> 
is '''not''' enabled. This option completely prevents transmission if more than one networked station is set to the same band 
and the whole idea with inband is to have exactly that.

Next, activate software interlock on both stations using the menu option <code>Options|Networking|Software interlock</code> 
or by typing the commmand <tt>ILOCKON</tt>.

[[image:inbandinterlock2.png|none|frame]]

There are multiple options for configuring the interlock. In a simple set up with only two stations, the topmost 
option ''Same band from status list'' is a good choice. This option will prevent more than one station transmitting 
on the same band, regardless of mode.

In an environment with many stations (such as a multi-operator-multi-transmitter station) it is 
recommended to use the bottom option to only interlock with one or several named stations. 
This will reduce both LAN traffic and inband operation latency. This is particularly important when 
running parts of the DXLog network over high latency links such as VLAN/VPN or if some stations (albeit not 
part of the interlock cluster) are connected via Wi-Fi.

For more advanced scenarios you can also use interlock based on mode or station type (e.g. Run 1, Run 2, Mult, etc.).

The "status list" listing the networked DXLog stations is displayed in the ''Status Window'' which is opened 
with <code>Windows|Status window</code> or <code>[Alt][J]</code>.

[[image:inbandstatuslist2.png]]

DXLog also offers great flexibility when it comes to interlock strategy. The most straightforward and 
most commonly used is ''First one wins''. This is also typically the behavior of "unintelligent" 
hardware solutions when not assisted by software. With this strategy, the station starting to transmit 
first can not be interrupted and always gets to finish its transmission.

[[image:inbandinterlockoptions.png]]

With a ''Last one wins'' strategy, the transmitting station can be interrupted. A carte blanche permission 
to interrupt all transmissions by the other station may however be counterproductive in a real contest situation.

For this reason, DXLog offers additional control of which transmit actions can be interrupted and which can not. 
This is a powerful tool but requires both operators to be aware of it and may require 
practice before fully effective.

[[image:inbandstrategyexceptions.png]]

''F1'' through ''F7'', ''PLUS'' and ''INS'' refers to DXLog's standard messages. ''KEYB'' means a free text transmission 
from the keyboard using the <code>[Alt][K]</code> function and ''MAN'' means manual transmission using either paddle 
break-in or a footswitch.

For CW, DXLog recognizes paddle break in from a K1EL Winkey-compatible keyer as described in the [[Menu_Options#Winkey_Configuration|Winkey configuration section]].

Since DXLog recognizes a footswitch connected to a microHAM device, this is a recommended approach for phone. 
It is also possible to connect a footswitch to the DSR pin (pin 6) on a physical COM-port on the PC, but today 
few PC have such a port and it also requires additional circuitry.
Details on how to do this is available [[Additional_Information#Connecting_a_footswitch|HERE]].

===microHAM configuration===

Open the microHAM device configuration panel with <code>Options|microHAM device configuration</code>.

[[image:Mk2r-new9.png|none|frame]]

Check the option ''Enable TX lock/unlock''. This will do two things; it will enable DXLog to prevent 
transmission and and it will make DXLog aware of the microHAM device's PTT status. The latter is particularly 
important since it means DXLog will recognize PTT assertion not only by a footswitch connected to the 
microHAM device but also by the built-in Winkeyer (requires microHAM USB Device Router version 9.3.0 or later) 
'''Paddle-based break-in in an inband solution is currently unique for microHAM with DXLog.'''

'''Important:''' Making DXLog "PTT aware" means that care has to be taken in how PTT is set up. If you, for instance, 
enable DXLog PTT for the voice keyer, this will create a self-reinforcing feedback loop and PTT will thus never drop.

Check the option ''Dual radio device'' if you are using a u2R, MK2R, or MK2R+, otherwise, leave this unchecked.

Check the option ''Device without CAT interface'' if the device lacks a CAT interface (like the u2R) 
or if its CAT interface is not connected to the radio. This option will make sure the e.g. keying and 
audio routing is always set correctly in line with the operating mode (Voice, CW, or RTTY).

===Operating===

Inband operation requires a fair amount of training and it is a good idea to define and agree 
on general rules for operation, such as hand signals for challenging QSO, beforehand.

There are more than enough YouTube videos of inband operators yelling at each other.

The operating tactics may have to be adjusted during the contest. If Run is slow, 
doing S&P on the inband station can increase the points per minute significantly. 
However, if Run is strong, an overly active inband operator doing S&P, but not working 
multipliers, may actually reduce the station's points per minute significantly.

Real-time interlock status is shown in the ''Radio status'' window, which is opened with 
<code>Windows|Radio status</code>.

[[image:inbandblocking.png]] [[image:inbandblocked.png]]

For Phone contesting, you typically rely on footswitches for PTT and the option 
<code>Options|Networking|Show QSO status when blocking</code> makes the blocking 
station send a more helpful blocking cause than ''MAN''.

With this option enabled, the blocking station will instead send ''CQ'', ''QSO'', or ''EXCHANGE'' 
as blocking cause, determined by cursor location and entry field content at the locking station.

Further reading can be found in the [[Menu_Options#microHAM_device_configuration|microHAM device configuration]] and [[Menu_Options#Networking|Networking]] sections.

==Connecting a footswitch==

To free up both hands in Phone contesting, a footswitch PTT is a great help.

Also, to use interlock in Phone contesting, a footswitch is mandatory.

There are two basic ways to interface a footswitch with DXLog; via a microHAM device (which is the recommended solution) 
or directly connected to a physical serial port on the PC (which very few PC have today).

The connection of a footswitch to a microHAM device is very straightforward and by checking the ''Enable TX lock/unlock'' 
in the ''microHAM device configuration'' panel, it is recognized by DXLog.

Lacking a microHAM device, it is also possible to use the computer's DB9 RS-232 serial port connector, providing it has one.

The required steps to do this are:
* Connect a 10k resistor between DB9 pin 6 and pin 7.
* In the port's settings (<code>Options|Configure interfaces</code>) set DTR (pin 4) to ''Always On'' and RTS (pin 7) to ''Always Off'' for the port.
* Connect the footswitch between DB9 pins 4 and pin 6. '''Important:''' Neither pole on the footswitch must be connected to ground.
* In the radio's configuration panel, check ''use CAT PTT command on Phone'' and set ''Footswitch (pin 6)'' to ''PTT''

==Support for CC Cluster==

CC Cluster is today the main choice for contest use.

It offers a high quality, database-verified, flow of skimmer spots and a rapid 3-minute respotting period for skimmer spots.

It also publishes unique spots from less common locations which are valuable for DX chasers or as contest multipliers.

To make use of the display of own spot in the world map, make sure to issue the command '''<tt>SET/OWN</tt>''' to the cluster node. 
This setting is persistent and only needs to be done once.

A list of cluster nodes that runs CC Cluster can be found here: [https://www.dxcluster.info/telnet/index.php?software=CC%20Cluster CC Cluster nodes]

A description of the command line syntax can be found here: [http://bcdxc.org/ve7cc/ccc/CCC_Commands.htm CC Cluster command syntax]

A convenient software for setting up filters etc. can be found here [http://www.bcdxc.org/ve7cc/default.htm#prog CC User]

[[Image:Ccclustersspotflow.png]]

==Support for AR Cluster 6==

With the author tragically SK, AR Cluster is no longer under development but still available as an executable binary.

In its standard configuration, AR Cluster offers no consolidation of skimmer spots meaning a very high flow of spots 
that can become extreme during a major contest weekend.

With the advent of skimmers, the traffic on the DX Cluster has risen dramatically. Even though CW skimmers are generally 
quite reliable, the absolute number of busted spots can be quite high during a busy contest.

Jose CT1BOH has developed an algorithm for evaluating spot quality which is included in version 6 of AR Cluster. 
Today many cluster nodes runs this version and thereby offer this mechanic. 
A complete list can be found here: [http://www.dxcluster.info/telnet/index.php?software=AR-Cluster AR Cluster nodes]

To enable the functionality on a cluster node running AR Cluster 6, the command

<tt>'''SET DX EXTENSION SKIMMERQUALITY'''</tt>

needs to be issued to the cluster node. The easiest way to do this in DXLog is via <code>[Alt][T]</code>. 
This setting will be remembered at subsequent logins.

The quality of the spots is indicated by a character ("tag") in the last column of the comment field and, 
in some cases, a corrected callsign within parenthesis. This syntax is recognized by DXLog and can reduce the 
number of bad spots in your bandmap.

The CT1BOH skimmer quality algorithm is based on three parts:

; Validation : When a callsign is first spotted, it is tagged with "?" in the last column of the spot's comment field. If the callsign of an unverified spot closely resembles an already verified one on the same frequency, the verified callsign is provided within parenthesis in the spot's comment field. When two or more skimmers agree on the spot, it is considered verified and the tag becomes "V".

; Frequency : When a verified spot appears more than 0.35kHz off its verified frequency, the spot is tagged "Q" for QSY. Once verified, this becomes the new verified frequency and it is tagged "V".

; Probability : The algorithm checks uncertain spots for resemblance with already verified spots and spots at or near the same frequency. If the resemblance is high enough, the spot is considered busted "B" and the corrected callsign is provided within parenthesis in the spot's comment field.

Below you can see an example of the spot flow from W9PA-4 with skimmer quality enabled. 
The flow contains one unverified and one busted spot.

[[image:spotquality.png]]

DXLog's policy for spots with CT1BOH skimmer quality tags is the following:

: '''V''' - Accept spot.
: '''Q''' - Accept spot.
: '''?''' - Accept spot. Use corrected call when provided.
: '''B''' - Accept spot if corrected call provided. Else ignore.

DXLog recognizes the skimmer quality tags but consolidates them for consistency 
with other cluster nodes' quality tags and to minimize confusion when mixing spot flows. 
The legend is:

: '''?''' means a spot with ? This is an unreliable spot.
: '''P''' means a spot with Q or B with correction. This is a fairly reliable spot.
: '''V''' means a spot with V. This spot is considered validated.

This basic policy can be modified by using additional filters at the cluster node end. Some examples are:

: <tt>'''SET DX FILTER NOT SKIMBUSTED'''</tt> - Do not send busted spots at all
: <tt>'''SET DX FILTER NOT SKIMQSY'''</tt> - Do not send QSY spots
: <tt>'''SET DX FILTER SKIMVALID'''</tt> - Only send verified spots
: <tt>'''SET DX FILTER NOT SKIMUNKNOWN'''</tt> - Do not send unreliable spots
: <tt>'''SET DX FILTER SKIMMER'''</tt> - Do not send manual spots

You can also compose more complex filters such as:

: <tt>'''SET DX FILTER SKIMVALID OR SKIMBUSTED OR NOT SKIMMER'''</tt>

This can be a good filter for most contests. It will will only provide valid or busted skimmer spots together with manual spots. 
It is safe to receive busted spots since DXLog will ignore them if there is no corrected callsign included. 

For assisted operation in serious contesting you however need to allow also unknown spots since weak stations spotted 
only by one or a few skimmers may never reach validated status. You do this by adding <tt>'''OR SKIMUNKNOWN'''</tt> to the filter.

Both the bandmap and the DX cluster announcement windows have the option to display the spot quality tag. 
These windows will show two additional tags; L and C. L stands for local spot, created by yourself or one of your team members. 
C stands for corrected, i.e., a B or ? spot where a corrected call has been included in the spot's comment field.

The AR6 filtering syntax offers a lot of flexibility. Another example:

: <tt>'''SET DX FILTER (SKIMVALID OR NOT SKIMMER OR ((SKIMQSY OR SKIMUNKNOWN) AND (CTY <> K AND CONT <> EU )))'''</tt>

will provide only validated and human spots except if they are from outside the US and EU.

If you get lost in the filter settings you can always reset with : <tt>'''SET DX DEFAULT'''</tt>.

Some more guidance on how to work with filters on AR-Cluster nodes can be found in [http://dxlog.net/sw/files/utilities/AR_Cluster_v6_User_Manual.pdf this document].

==Support for DXSpider==

DXSpider is the by far most dominant DX cluster software but has historically not been a good choice for contesters. 
The reasons for this include: Long respotting time, lack of pass function for own spots, and suppression of spots from a single skimmer.

The good news is however that the author Dirk G1TLH has worked hard to address these aspects of the otherwise brilliant software.

From '''version 1.57 release 440''' the respotting time is now 3 minutes and there is a <tt>SET/SEEME</tt> command that passes all spots 
without consolidation of your own callsign.

So if your favorite cluster node is not running this version, ask the owner to upgrade asap.

Yet another reason for its popularity is its extreme resource-efficiency which allows it to run virtually 
any Linux capable hardware, including a $20 Raspberry Pi Zero.

A list of all DX cluster nodes running DX Spider can be found here: [https://www.dxcluster.info/telnet/index.php?software=DX%20Spider DX Spider cluster nodes]

[[image:dxspiderflow.png]]

DXLog recognizes the <tt>Q:#</tt> skimmer quality tag in the comment field and converts them into "CT1BOH-like" quality 
tags that can be displayed in DXLog's bandmap. The legend is:

: '''?''' means a spot with Q:1, i.e. heard by only one skimmer. This is an unreliable spot.
: '''P''' means a spot with Q:2, i.e. heard by only two skimmers. This is a fairly reliable spot.
: '''V''' means a spot with Q:3 or higher, i.e. heard by several skimmers. This spot is considered validated.

Since a DXSpider node currently needs to be specially configured by the owner to publish Q:1 spots, very few do this. 
Also, since DXSpider lacks busted call detection, the the quality of the spot flow will suffer if this is done.

There is a wealth of information to be found on the [http://wiki.dxcluster.org/index.php/Main_Page DXSpider wiki].

==Support for N2WQ Cluster==

Introduced in late 2025, Rudy N2WQ has developed the first new DX cluster node software in decades.

The N2WQ-2 cluster has some unique features like a more advanced callsign validation than 
AR 6 and propagation estimation tags embedded in the spot comments. An example can be seen below.

[[image:n2wpspotflow.png]]

When you connect to dxc.n2wq.com port 8300 and you have set your 4-digit Maidenhead grid (SET GRID), there 
will be a single character just before the DX’s grid locator. This character is the path prediction glyph.

It is a crowdsourced, real-time estimate of how reliable the path is between you and the DX on that band right now, 
based on recent on-air propagation reports from RBN and PSKreporter. Its values and meaning are:

: > High: Strong path. If you can hear them, you should be able to work them.
: = Medium: Decent path. Workable with normal contest/DX technique.
: < Low: Weak path. Possible, but expect repeats, timing, and patience.
: - Unlikely: Marginal. Try only if it’s rare/needed, or you have a strong station advantage.

A missing glyph means insufficient data to estimate the path.

the glyph is mode-aware. A path that looks great for a very sensitive mode (FT8) can look 
more moderate for a less sensitive one (SSB).

You can filter spots by path reliability using the PASS/REJECT PATH command.

It is important to be aware that the glyph does not know:

: Your antenna gain/pattern, height, or takeoff angle
: Your transmit power and duty cycle constraints
: Your operating technique (timing, split discipline, pileup strategy)
: Short-lived phenomena the network has not yet “seen” such as sporadic E or aurora.

The cluster ingests upwards of 50,000 CW, FT, RTTY, and WSPR spots per minute. To compare different modes 
fairly, the system normalizes reports onto a common “FT8-equivalent” scale (so a CW SNR can be compared 
to an FT8 SNR).

Your grid and the DX grid are mapped into small geographic cells and the cluster calculates propagation 
at two levels:

: Fine (local): what’s happening close to your area (~180 miles).
:: On averages there are about 90,000 DE/DX pairs being tracked
: Coarse (regional): what’s happening in the broader region around
:: you (~480 miles). On average, there are about 30,000 DE/DX pairs.

If there isn’t enough local data, the system leans more on regional behavior. 
If there’s plenty of local data, it uses that more heavily.

Sometimes you can hear them better than they can hear you (or the reverse) due to noise 
floors, antennas, geography, or ionospheric effects. The system tracks both:

: Receive direction: DX to you (can you hear them?)
: Transmit direction: you to DX (can they hear you?)

It combines these into one “path reliability” estimate, weighting receive a bit more 
because if you can’t hear them, you can’t work them.

Propagation changes fast, so older reports get discounted using a half-life (data fades 
in influence over time). Typical behavior by band:

: Low bands (160/80m): slower changes (longer half-life)
: Mid bands (40–20m): medium pace
: High bands (15–6m): fast changes (shorter half-life)

In practice, this means glyphs can shift in minutes on 10m/6m, and more slowly on 80m/160m. 
Also, new openings take time to show up. A "insufficient" can simply mean “the path just opened 
and the cluster hasn’t collected enough recent reports yet.”

Your local noise floor heavily affects what you can receive, so the cluster lets you tell 
it what your noise environment is. This mainly tunes the receive-side expectation (DX to you).

Set it with SET NOISE SUBURBAN. Available profiles per ITU:

: QUIET: very low noise, rural/remote
: RURAL: mild noise
: SUBURBAN: typical neighborhood QRM
: URBAN: elevated noise, dense housing
: INDUSTRIAL: severe noise

If you don’t set it, the system may assume a quieter environment than you actually 
have, and your receive-side glyphs can look too optimistic.

Treat the glyph as a real-time probability hint that helps you spend your operating 
time where the odds are best. When you see > on a needed multiplier, move fast. 
When you see -, be intentional about whether it’s worth the time. 
And when you see a space, fall back to classic DX/contest instincts and your own ears.

The N2WQ cluster also offers spot quality tags between the DX grid and the time.

A quality (in terms of callsign reliability) tag can be V, P, S, C, or ? where V means validated, 
P highly likely, S less likely, C corrected, and ? unsure.

The propagation and quality tags can be displayed in the bandmaps and the DX cluster announcement window.

DXLog recognizes the skimmer quality tags but consolidates them before display for consistency 
with other cluster nodes' quality tags and to minimize confusion when mixing spot flows. 
The legend is:

: '''?''' means a spot with ? or S. This is an unreliable spot.
: '''P''' means a spot with P or C. This is a fairly reliable spot.
: '''V''' means a spot with V. This spot is considered verified.

==Interacting with WSJT-X==

Important: When in a DXpedition/multi-station setting, always use local host 127.0.0.1 as the 
broadcast address to prevent packets being picked up by other stations in the network. 
Also, enabling the creation of local spots from decodes may overwhelm DXLog.

DXLog can add QSO performed with WSJT-X to its log. Note that this functionality only works 
for contests with grid as the first and only exchange or for DXPedition type logs.

DXLog can also create local spots from WSJT-X decodes by checking 
<code>Options|Broadcast|Spot WSJT-X decodes</code>.

To enable logging of WSJT-X QSO, set up WSJT-X to broadcast information:

[[image:Wsjt-x-udp.png]]

[[image:Radiobroadcastenable3.png]]

Activate DXLog's UDP listener by checking <code>Options|Broadcast|Receive broadcasts</code> and set 
the same port number as in WSTJ-X in DXLog's network configuration panel.

[[image:Dxlog-udp.png]]

==Using Winkey FSK==

Winkey FSK is not natively supported by DXLog's digital mode engines MMVARI or MMTTY but 
Rafal EI6LA has developed a plugin for MMTTY that makes this possible.

You can find it [https://github.com/RafalLukawiecki/WinKeyerMMTY here].

==Interfacing with LogHX==

Christian F8GHE has prepared a guide on how to do this.

You can find it [http://dxlog.net/sw/files/utilities/DXLOG-LogHX_UDP-config_v2.pdf here].

==Self-spotting==

More and more contests allow spotting your own station on the DX cluster.

DXLog supports this, even when operating unassisted, as long as you connect to the cluster.

DXLog has three mechanics for self-spotting.

DXLog blocks self spotting unless specifically allowed in the contest rules. 
Should you find that DXLog incorrectly allows or blocks self-spotting, please make 
the development team aware via the support reflector.

* The <tt>$SPOTME</tt> macro command. This macro will create a cluster spot of the station's
: call at the earliest 15 seconds after being invoked the first time on a new frequency.
: Thereafter it will spot as frequent as allowed by the contest. If the contest rules do not
: specify a minimum period, 10 minutes will be used.

* Checking the menu option <code>Tools|Data entry|Run F1 message self-spots when permitted</code>.
: Works exactly like the <tt>$SPOTME</tt> macro command but is triggered by sending the
: Run F1 message which happens when pressing <code>[Enter]</code> with an empty entry line
: in Run, pressing <code>[F1]</code> in Run, or with Auto-CQ.

* Clicking the menu item <code>Commands|Self-spot</code> or pressing its shortcut key <code>[Ctrl][S]</code>.
: This will immediately create a spot of the station's call but no more often than
: every two seconds to avoid accidental multiple spots.

==DXpedition use==

DXLog is a popular choice for top tier dxpeditions. Below we have collected advice based on experience 
on how to best use DXLog in a dxpedition setting.

* Use client/server networking between stations. Never use UDP over Wi-Fi or WAN links.
* Use the "Minimal data" option in ADIF export to save on satellite link cost.
* For Club Log real time upload, use [[https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads Club Log's upload app]]
* Club Log truncate QSO time to minutes so to avoid creating dupes when mixing manual and real time upload to Club Log, check ''QSO time in minutes'' when doing ADIF export.
* Use the "Minimal data" option in ADIF export to save on satellite link cost.
* Follow [[Additional_Information#Interacting_with_WSJT-X|the instructions]] to log QSO made with WSJT-X and MSHV.
* Check <code>Options|Broadcast|Spot WSJT-X decodes</code> to make decoded calls appear in e.g., DX cluster announcements.
* You can extend the number of digits in the QSO count with <code>Options|Log|QSO number digits</code>

==Beacon spots on DX cluster==

Although propagation measurements based on FT8 communications has reduced the 
value of beacons, there are still hundreds of them in operation.

Identifying with CW, they are typically reported on reported on the DX cluster.

When beacon spots are received by DXLog, they are always displayed in the bandmap. 
In DXLog, beacon spots are recognized by having a trailing <tt>/B</tt>.

The DX cluster announcement window never shows or counts beacon spots.

Beacon spots can be enabled and disabled in the cluster node.

For CC Cluster, the commands are <tt>SET/BEACON</tt> and <tt>UNSET/BEACON</tt>.

For DXSpider, command is part of the <tt>SET/SKIMMER</tt> command where <tt>SET/SKIMMER</tt> 
or e.g., <tt>SET/SKIMMER CW BCN FT RTTY</tt> will pass beacon spots and <tt>UNSET/SKIMMER</tt> 
or any <tt>SET/SKIMMER</tt> listing modes but not BCN will block them.

AR 6 cluster nodes always pass beacon spots when skimmer spots are enabled. They cannot be disabled.

==Using Piper text-to-speech synthesis==

James M0DST has prepared 7 sample scripts that can be mapped to F keys.

James' comments on the scripts are:

This is just an extended proof of concept. Feel free to play using your own scripts. 
There is a lot of code duplication across the scripts. I may simplify some of this in the future. 
I tried base classes, but the current script engine would need some rework to support that. 
Repeat isn't supported. You will need to press the key manually. 
Multiple op voices are not supported currently. You could hack this in with little effort. 
There is no documentation at present. This feature is experimental whilst I decide how I want 
to move it forward (if at all). If you want to adjust the speed, you can do it per script. 
See SpeakingRate in the F2 script. Lower number is faster.

You can visit https://rhasspy.github.io/piper-samples/ to hear the voices. Set the model in the script.

Any comments or thoughts on anything related to this should be sent to me directly or on the list.

I really suggest training your own voice. I haven't done it yet, but I will when I have time. 
Using common amateur radio phrases in the training data will help teach it to sound more like a ham.

If you improve the scripts, please send them to me and I will update the files behind this link. 
Once everything is stable and formalized I will pass the links to Bjorn for the website, and we 
will add some real documentation.

Experimental scripts:

[[https://drive.google.com/file/d/1EhfOpxsL57yuf-1WorASnGf-SBsmfqu7/view?usp=drive_link F1]]
[[https://drive.google.com/file/d/1MgviBec7HCXIOJZtDZXl0qXlrU-TwMoD/view?usp=drive_link F2]]
[[https://drive.google.com/file/d/1yAgY5E-KdOcmToXMJQ2lRNhjBIQrJIb9/view?usp=drive_link F3]]
[[https://drive.google.com/file/d/1-ftWUhFlc4-quwGPIVmNujQ4q-J5E3EZ/view?usp=drive_link F4]]
[[https://drive.google.com/file/d/1h3C_kLl9C4CEH6kATGAZbfDkfY6KlgqB/view?usp=drive_link F5]]
[[https://drive.google.com/file/d/1e4tAHz-_dU92RybaFeSuLCd0V7Gk_lWy/view?usp=drive_link F6]]
[[https://drive.google.com/file/d/1UGxgOpqOjOzl7yFTjrVaml9m5o8gBq5y/view?usp=drive_link F7]]

Additional Information

2026-04-01T07:00:13Z

Sm7iun: /* DXpedition use */

==Using alternative configurations==

Window positions, coloring and general look and feel is saved in each log file but all other settings such as 
radio control, keying, and networking is saved in a common, contest-independent configuration file.

By default, the configuration file name is <tt>DXLog.net.config</tt> and it is located in the <tt>%appdata%\DXLog.net</tt> configuration folder.

This folder is also reachable via the <code>File|Open configuration folder</code> menu item.

[[image:configfolder.png]]

DXLog can be made to use an alternative configuration file with the command line option <tt>-cfg=<filename></tt>.

A convenient way to use this option is to create a separate Windows desktop shortcut including the command line option 
and give it a meaningful name.

[[image:Desktopshortcut.png]]

The command line option is simply added to the end of the Target text box in the shortcut's properties. 
Double-clicking the icon will start DXLog with the alternative configuration which will also be remembered between sessions. 
In the picture below the target of the shortcut is

[[image:Desktopshortcutconfig.png]]

'''Important:''' If you want to use an alternative configuration, do not just modify the desktop shortcut created at installation 
since this shortcut will be deleted when you upgrade DXLog. Instead make a copy, rename, and add the command line option. 
You should keep the command line option outside the apostrophes, like this

<tt>"C:\Program Files (x86)\DXLog.net\DXLog.net.exe" -cfg=SO2R.config</tt>

==Using a number server==

For contests involving serial numbers you need to secure that the sent number and the (slightly later) 
logged serial numbers are the same. In a straightforward SO1R or SO2V scenario, serial numbers are simply 
chronological but in more complex station configurations such as Multi-single or Multi-2 with inband, and 
advanced SO2R, QSO can be interleaved and requires a central source source of serial numbers together 
with a mechanic to protect an already sent serial number from re-use by another radio.

In DXLog this is achieved with a central number server. A number server can be used either 
by a single instance of DXLog (for SO2R) or by multiple stations on the same LAN.

The use of a number server involves three, natural, steps:

* Activating the server on a single station
* Making sure all stations use it
* Verifying functionality, making sure serial numbers are correctly reserved

The number server is activated in the <code>Options|Configure network</code> panel, described [[Menu_Options#Configure_network|HERE]].

[[image:startnumberserver.png]]

Since the server uses a networking socket, <code>Options|Networking</code> must be enabled '''also''' when 
using a single computer in SO2R. In the case of multiple stations, UDP networking or Client-Server 
networking must also be enabled to transfer the numbers over the LAN. For SO2R, this is however not 
necessary. When using Client-Server networking, a client cannot be number server.

There must only be one number server in a local network and all stations using it must have 
<code>Options|Networking|Use number server</code> checked like in the picture below.

'''Important:''' The number client/server functionality is not very robust. 
If you have stations joining/leaving your network or being rebooted, it is 
best to restart DXLog on all stations to guarantee correct function.

[[image:usenumberserver.png]]

The option <code>Block logging if serial number reservation is unsuccessful</code> can be used as an extra precaution 
but is not necessary in SO2R since the communication with the number server does not leave the computer.

There are three methods for reserving a number from the server:

* Checking <code>Tools|Data entry|Space key reserves serial number</code> and using the space key to reserve serial numbers. This is typically used on phone or when operating "old school" with F-keys.
* Checking <code>Tools|Data entry|Insert and F2 messages reserve serial number</code> and letting DXLog automatically reserve a serial number right before $SERIAL sends it. This is the preferred and most straightforward way for CW and digital.
* Adding the $RESERVENR macro to messages like illustrated below. 

These methods can of course also be combined. 

The $RESERVENR macro is "smart" and will only reserve a serial number if the callsign entry field is not empty and a 
serial number is not already reserved. The same goes for the menu items.

[[image:reservemessages.PNG]]

The sign of a serial number being reserved is that it turns red. It then stays reserved (and red) until the 
QSO is logged or the entry line is cleared with <code>[Alt][W]</code>.

An option that can prove useful is <code>Tools|Data entry|Cancel serial number reservation only if callsign field is empty</code>. 
In the case that you send the exchange and realize you got the other station's callsign call completely wrong, a reflex can be to hit 
<code>[Alt][W]</code> and start typing. If this is your habit, this option will prevent you from releasing the 
already sent serial number, thereby avoiding you the trouble to send a new one to the other station.

[[image:reservednumber.png]]

==Networking over internet==

When, for instance, activating a special event callsign it is possible to network multiple DXLog stations over the internet.

'''Pro tip:''' Consider displaying the callsign, message ID, Message text, etc. fields in the ''Network status'' 
window when operating a distributed station. Also, learn to use the gab <code>[Alt][G]</code> and <code>[Alt][J]</code> function.

===VLAN/VPN Solution===

The most secure way for remote networking is to rely on a VLAN (virtual LAN) software. There are several available such as:

ZeroTier https://www.zerotier.com/ 
FreeLan http://www.freelan.org/ 
Player.me https://player.me/ 
OpenVPN https://openvpn.net/

Each VLAN solutions have their own particular set up which is covered in their respective documentations. 
With a VLAN solution, all DXLog configurations are the same as when operating in a regular LAN however with a few exceptions.

One weakness with connections over the internet (a.k.a. WAN), including VLAN solutions, is that they are prone to packet loss. 
Packet loss is disastrous to DXLog's (or any logger's) "standard" UDP networking.

It is therefore essential to use '''only client/server networking over a VLAN'''. 
'''This also means you should never use interlock over an internet connection unless you use a zero packet loss VPN tunnel.'''

ZeroTier is particularly popular since it is free.

Since DXLog is able to mix TCP (client/server) and UDP (peer-to-peer) networking, a distributed station set up should be configured to rely on TCP 
for the wide-area network and UDP for the local network at each station location. Below you will find the station 
set up for the Swedish HQ station SE9HQ in the 2019 IARU HF Championship. The DXLog.net.DXC cluster client was run 
on SK3W-A which distributed spots to all stations over the network. Inband interlock was also used at the SK3W location.

[[image:SE9HQ-network-eng.png|800px]]

Important to note:

* For the server as well as the main clients, ''Server IP'' should be set to the server's VLAN IP address, '''not''' its LAN address.
* The '''server''' should check both "Act as network server" and "UDP network broadcast for multiple stations".
* The '''main clients''' should check both "Connect to network server" and "UDP network broadcast for multiple stations".
* The '''sub clients''' should check only "UDP networking for multiple stations".
* Interlock (which is UDP-based) over VLAN does not work reliably because of packet loss.
: Therefore, it is important to configure any interlock to '''only''' consider relevant operating positions,
: which all must be local. Use the possibility to only consider named stations for the interlock in the software 
: interlock set up. <code>Options|Networking|Software interlock</code> "Custom station ID(s)"
* For a large set-up with many stations connecting as clients to a central server you may overload the server if you also
: distribute spots via all client-server connections. In this case, check the "No spots via client/server" option
: on all stations and use '''local DX cluster connections''' via UDP at each location.
: '''Important:''' Limitations in Windows networking makes client/server networking unreliable beyond 10 station locations.
* Make sure to check <code>Options->Load contest at startup</code> to avoid opening the wrong log after a restart.
* '''Remote commands are not forwarded''' in the network but are executed in the station where they arrive.
: Thus, to clear all logs, disconnect networking on each main client, execute the remote command CLEARLOGNOW on each main client
: to clear the logs of all sub clients and do not reconnect until the server and all other main clients have done the same.

===Port forwarding Solution===

If you are less worried about competitors or government agencies listening in on your contest data, 
it is possible to route the traffic directly over the internet using port forwarding at the server.

'''Important security notice: This solution is not without risk. It offers no security or authentication. 
Any DXLog station running the same contest configuration, knowing the URL or IP address and IP port of the 
server can connect to the server station. There are no means to disconnect a station by force.'''

Also note the comment about '''remote commands''' in the section above.

With a port forwarding solution, the following must be observed:

* '''Server configuration'''
:* Only one of the stations should be configured as the '''server'''.
:* "Connect to network server" should not be checked on this station and
:: "UDP networking for multiple stations" should only be enabled if it is used to
:: communicate with a cluster client or other stations locally on the same LAN.
:: Either use a central cluster connection (uncheck "No spots via client/server")
:: or use one cluster connection per station location (check "No spots via client/server").
:: If one cluster connection per station location is used, make sure they
:: all use different SSID to prevent disconnects, such as E7HQ-1, E7HQ-2, etc.
:: This will ensure the cluster node regards all connections as having the same callsign
:: which is essential for e.g., correctly receiving own spots.
:* The PC acting as server must be configured for a fixed LAN IP address. This is done
:: either by manually configuring the networking settings in the PC to use a fixed
:: LAN IP address, or by setting up the router in the server's LAN to to always allocate
:: the same IP address to it.
:* The internet connection used by the server PC must ''either'' have a fixed public IP address ''or''
:: use dynamic DNS. Otherwise clients will not be able to reliable connect over the internet.
:* The server's TCP/IP port (e.g., <code>9888</code>) must be forwarded to the server by the server LAN's router.
:: Only TCP traffic should be forwarded. DXLog UDP traffic is not carried well over the internet.

:: [[image:serverconfig.png|600px]]
:: '''Example configuration for server for networking over internet'''

::[[image:portforwarding.png|600px]]
::'''Example of port forwarding UI in router'''

* '''All other stations'''
:* All other PC in the multi-station set up should be set up as clients.
:* Over the internet, "Server:" is either the static, public IP address of the server's internet
:: connection (e.g. <code>5.140.211.42</code>) or the dynamic DNS address (e.g. <code>hq.sm7iun.se</code>).
:: Clients connecting over the internet does not have to enable UDP networking and ''should not''
:: enable a server.
:* A client may connect via UDP if it is on the same LAN as the server ''or'' a "main client".
:: A "main client" is a client that connects to the server using the "Connect to network server" option in
:: the networking set up panel. A "main client" acts as a UDP gateway which means that if
:: several computers on a LAN are part of the same multi station set up but the server is located
:: elsewhere, only one computer in that LAN needs to connect as a client and the rest can use UDP.
:* Software interlock is UDP-based and can only reliably be used locally. Never over the internet.
:: If used, make sure the interlock is explicitly limited to local stations. See above for more details.

::[[image:clientconfig.png|600px]]
::'''Example configuration of client for networking over internet'''

* In a multi-station setting it is recommended to enable
: <code>Options|Networking|Block standard messages if no operator is logged on</code>
* Make sure <code>Options|Enable network</code> is checked.
* It is also a very good idea to check <code>Options|Load contest at startup</code> to reduce the
: risk of the wrong contest log file being loaded by any stations.

==Real time upload to Club Log Live Stream==

'''Important:''' Club Log truncates QSO time to minutes which means that if you mix real time upload 
with manual upload, make sure to check "QSO time in minutes" when creating ADIF export files.

The author of Club Log, Michael Wall, G7VJR, has developed a very powerful agent for real time uploads. 
It works with all the three major loggers, DXLog, N1MM Logger+, and Win-Test.

It can either be used as is, with a command line user interface, or with an optional user interface front end.

Information on how to download and configure it can be found [[https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads HERE]]

The Club Log Gateway can either listen to DXLog's native multi-station networking protocol or to N1MM style XML broadcast.

To use DXLog's networking protocol, make sure the same port (default 9888) is used in the gateway and DXLog 
and that UDP networking is enabled in DXLog. Do not enable QSO broadcast.

Although this works, it is recommended to use N1MM style broadcast since it contains information like logged on operator, etc.

To use this make sure the port (default 12060) is the same in N1MM port setting in the gateway and in the 
QSO broadcast port settings in DXLog's network configuration. Also make sure to se the DXLog port number 
in the gateway is not the same as that used in DXLog to avoid QSO duplication.

Also set:

<code>Options|Broadcast|QSOs</code> 
<code>Options|Broadcast|QSOs</code> 
<code>Options|Broadcast|Use N1MM QSO format</code> 
<code>Options|Broadcast|QSO time in minutes only</code>

'''Important:''' If you are going to also upload exported ADIF files to Club Log, it is important to also 
check "QSO time in minutes" in the ADIF export configuration to avoid creating virtual dupes, since Club 
Log does not know seconds.

==Diversity reception==

Diversity means receiving the same signal through two different receive chains, including antenna. 
With two antennas having different characteristics this can give substantial benefits in receiving 
fading and/or weak signals or separating calls in a large pile-up. Particularly on low bands.

DXLog supports diversity operation on a selected number of radio models.

For the supported radios, diversity operation can be toggled on and off using <code>[Ctrl][-]</code> or <code>[Ctrl][Keypad -]</code>.

If enabled via the radio's controls, DXLog will automatically detect diversity operation and enable 
the necessary mechanics. Diversity operation is indicated by a small DIV icon in the frequency 
counter box for the radio's band map.

'''Yaesu FTDX101D

Yaesu calls this feature "Sync" and it has a dedicated button up and left of the main VFO knob. 
Enabling this will make DXLog update both VFO with the same information when grabbing spots. 
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO. 
Since both VFO are kept on the same frequency, split operation is not supported.

'''ICOM IC-7851 and IC-7610

ICOM calls this feature "Tracking" and it can be enabled either via a menu entry or a long press on the "MAIN/SUB" button. 
Enabling this will make DXLog update both VFO with the same information when grabbing spots. 
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO. 
Since both VFO are kept on the same frequency, split operation is not supported.

'''Elecraft K3/K3S/K4

Elecraft calls this feature by its proper name. It is enabled by a long press on the "Sub" button. 
It should be noted that Elecraft's implementation where the main VFO controls both the main and 
sub receivers allows for split operation, i.e. transmitting on a different frequency using VFO B.

==UDP broadcast==

For interaction with other applications, DXLog can broadcast useful information as 
XML datagrams over UDP. 

There are five types of broadcast messages produced by DXLog:

* QSO information. Sent when logging.
* Radio information. Sent at changes as well as periodically.
* Antenna direction information. Sent when rotor control is invoked.
* Callsign look-up information
* Spots

QSO can be broadcasted in traditional DXLog format or in a more N1MM-like format.

Radio information can report SO2V as a single physical radio or as two physical radios, like N1MM.

There is an option to truncate the broadcasted QSO time to full minutes for better 
interoperability with some online services and software such as MSHV.

In addition, DXLog can also recognize QSY commands from Waterfall Bandmap and log QSO done as well as create 
local spots from decodes broadcasted by WSJT-X and its forks.

The broadcasting of QSO and radio related data is enabled using the <code>Options|Broadcast</code> submenu.

The broadcasting of spots is enabled by checking <code>Options|DX Cluster|Send spots to SmartSDR</code>.

[[image:radiobroadcastenable3.png]]

[[image:sendspotstosmartsdr.png]]

UDP broadcast parameters are configured in the <code>Options|Network configuration</code> panel. 
Please note that up to three ports can be specified for each broadcast, thereby supporting 
multiple receivers of the information.

[[image:Networksettingsbroadcast3.png]]

If you are writing a C# application to make use of these datagrams, there is a very nice online tool 
for creating an object from a sample XML datagram here https://xmltocsharp.azurewebsites.net/ 

In C# parsing is easily done using Linq. One example of XML parsing and deserialization using Linq 
can be found here https://github.com/bjornekelund/ICOMautomagic

===QSO information===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program
|-
| qsoid
| A unique string for this QSO. If this QSO is edited another contactinfo message will be sent with the same qsoid. Note that the qsoid is only unique within one instance of DXLog. If the computer is networked to others running DXLog the different computers may have a different qsoid for the same QSO.
|-
| contestname
| The name of the contest as it would be written to a Cabrillo file.
|-
| timestamp
| The UTC date and time of the QSO.
|-
| mycall
| The callsign of this station.
|-
| band
| The band on which the QSO was made. In MHz with period as decimal separator.
|-
| txfreq
| The frequency on which the QSO was made.
|-
| operator
| The callsign of the operator if the OPON command was used to set it, otherwise blank.
|-
| mode
| The mode used for the QSO.
|-
| call
| The callsign of the station worked.
|-
| countryprefix
| The DXCC country of the station worked.
|-
| wpxprefix
| The WPX prefix of the station worked.
|-
| snt
| The RST sent. This is always included whether or not the contest exchange contains an RST.
|-
| rcv
| The RST received. This is always included whether or not the contest exchange contains an RST.
|-
| nr
| The number sent if the exchange uses a serial number, otherwise the QSO number from this station.
|-
| exch1
| The first element in the contest exchange if any.
|-
| exch2
| The second element in the contest exchange if any.
|-
| exch3
| The third element in the contest exchange if any.
|-
| exch4
| The fourth element in the contest exchange if any.
|-
| xqso
| True if this QSO should not be counted towards the score.
|-
| invalid
| True if this QSO is invalid, for example a DX QSO in a domestic contest.
|-
| duplicate
| True if this QSO is a dupe (the station has previously been worked).
|-
| rule10broken
| True if this QSO breaks the 10 minute or similar rule. Note that a QSO may not break the 10 minute rule when it is logged but may later if another QSO is edited. This may not cause a broadcast.
|-
| azimuth
| The approximate direction of the station worked, in degrees.
|-
| distance
| The approximate distance of the station worked, in kilometers.
|-
| stationid
| The station ID of the station which made the QSO.
|-
| stationqso
| A unique QSO ID generated by the logging station. The combination of stationid and stationqso forms a unique identifier for the QSO.
|-
| stationtype
| The type of station - R for run, R1 for run 1 etc.
|-
| local
| True if this broadcast is due to this QSO being logged or edited on this computer.
|-
| runqso
| True if QSO logged in Run, false if S&P, and empty if unknown. '''Important:''' Only valid when local is True.
|-
| mult1
| The name of the multiplier if this station is a new multipllier, empty otherwise.
|-
| mult2
| The name of the multiplier if this station is a new multiplier, emtpy otherwise.
|-
| mult3
| The name of the multiplier if this station is a new multiplier, empty otherwise.
|-
| points
| The logged points for the QSO.
|-
| period
| The number of the operating period.
|-
| guid
| The GUID in hex format.
|-
| newqso
| True if a new QSO, False if this message is an update to an existing QSO.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<contactinfo>
<logger>DXLog v2.4.13</logger>
<qsoid>19</qsoid>
<contestname>ARRL-SS-CW</contestname>
<timestamp>2020-01-13 18:28:07</timestamp>
<mycall>SM7IUN</mycall>
<band>3.5</band>
<txfreq>352376</txfreq>
<operator></operator>
<mode>CW</mode>
<call>K4BAI</call>
<countryprefix>K</countryprefix>
<wpxprefix>K4</wpxprefix>
<snt>599</snt>
<rcv>599</rcv>
<nr>19</nr>
<exch1>076</exch1>
<exch2>B</exch2>
<exch3>54</exch3>
<exch4>GA</exch4>
<xqso>False</xqso>
<invalid>False</invalid>
<duplicate>False</duplicate>
<rule10broken>False</rule10broken>
<azimuth>225</azimuth>
<distance>1388</distance>
<stationid>STN1</stationid>
<stationqso>19</stationqso>
<stationtype>R1</stationtype>
<local>True</local>
<runqso>True</local>
<mult1>GA</mult1>
<mult2></mult2>
<mult3></mult3>
<points>3</points>
<period>1</period>
<guid>11223344556677889900aabbccddeeff</newqso>
<newqso>True</newqso>
</contactinfo>
</pre>

Alternative N1MM format

Note that the band name uses the computer's local number format so it may use either comma 
or period as decimal separator. The ID is a number rather than an alphanumeric string.

Also note that IsRunQSO is only valid when IsOriginal is True.

<pre><?xml version="1.0" encoding="utf-8"?>
<contactinfo>
<app>N1MM</app>
<contestname>CWOps</contestname>
<timestamp>2020-01-17 16:43:38</timestamp>
<mycall>SM7IUN</mycall>
<band>3.5</band>
<rxfreq>352519</rxfreq>
<txfreq>352519</txfreq>
<operator></operator>
<mode>CW</mode>
<call>K1XM</call>
<countryprefix>K</countryprefix>
<wpxprefix>K1</wpxprefix>
<stationprefix>K1XM</stationprefix>
<continent>NA</continent>
<snt>599</snt>
<sntnr>5</sntnr>
<rcv>599</rcv>
<misctext></misctext>
<ismultiplier1>1</ismultiplier1>
<ismultiplier2>0</ismultiplier2>
<ismultiplier3>0</ismultiplier3>
<points>l</points>
<radionr>l</radionr>
<run1run2>1<run1run2>
<IsOriginal>False</IsOriginal>
<NetBiosName>DESKTOP-23AB</NetBiosName>
<IsRunQSO>0</IsRunQSO>
<StationName>STATION_B</StationName>
<ID>23</ID>
<IsClaimedQso>true</IsClaimedQso>
</contactinfo>
</pre>

===Radio information===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| The name of the logging program.
|-
| logger
| The name and version of the logging program.
|-
| Station
| The ID of the station.
|-
| RadioNr
| The radio being described.
|-
| Freq
| The receiving frequency.
|-
| TXFreq
| The transmitting frequency
|-
| InactiveFreq
| The frequency of the VFO not receiving.
|-
| Mode
| The reported radio's mode.
|-
| OpCall
| The callsign of the operator if the OPON command was used to set it, otherwise blank.
|-
| mycall
| The callsign of the station.
|-
| IsRunning
| "True" if the station is running, "False" if search and pounce.
|-
| FocusEntry
| The Windows handle for the focused entry window.
|-
| Antenna
| Antenna number.
|-
| Rotors
| Rotators used by selected antenna (not currently used by DXLog).
|-
| FocusRadioNr
| The radio which has keyboard focus. In SO2V with "Report SO2V as two radios" checked, radio 2 is the sub/B VFO.
|-
| IsStereo
| True if headphones are listening to two radios.
|-
| IsSplit
| True if radio is set to split.
|-
| ActiveRadioNr
| The radio which is transmitting, if any.
|-
| Technique
| SO1R, SO2R, SO2R_ADV, or SO2V
|-
| StationType
| Station role: R, M, R1, R2, or R+.
|-
| isTransmitting
| True if a DXLog is transmitting. False if DXLog is not aware of transmission.
|-
| IFFrequency
| Optional element only used with Elecraft K3/K4. Contains the current IF frequency in Hz.
|-
|}

Important note: In SO2V the format differs from some other loggers and is:

: Only physical radio 1 is reported.
: <tt>Freq</tt> and <tt>TXFreq</tt> are the frequency of the currently focused VFO.
: <tt>InactiveFreq</tt> is the frequency of the currently unfocused VFO.
: <tt>ActiveRadio</tt> is always 1.
: <tt>FocusedRadioNr</tt> is 1 when the main/A VFO is focused, 2 otherwise.
: <tt>IsSplit</tt> is always false.

With the option "Report SO2V as two radios" checked, the reporting is similar to some other loggers and is:

: The two VFO are reported as two physical radios.
: <tt>Freq</tt> and <tt>TXFreq</tt> for radio 1 are the frequency of the main/A VFO.
: <tt>Freq</tt> and <tt>TXFreq</tt> for radio 2 are the frequency of the sub/B VFO.
: <tt>InactiveFreq</tt> is the frequency of the other VFO.
: <tt>ActiveRadio</tt> and <tt>FocusedRadioNr</tt> are 1 when the main/A VFO is focused, 2 otherwise.
: <tt>IsSplit</tt> is always false.

Example message:

<pre><?xml version = "1.0"?>
<RadioInfo>
<app>DXLog</app>
<logger>DXLog v2.4.13</logger>
<Station>STN1</Station>
<RadioNr>1</RadioNr>
<Freq>704000</Freq>
<TXFreq>704000</TXFreq>
<InactiveFreq>702500</InactiveFreq>
<Mode>CW</Mode>
<OpCall>K1XM</OpCall>
<mycall>HQ9X</mycall>
<IsRunning>False</IsRunning>
<FocusEntry>591124</FocusEntry>
<Antenna>1</Antenna>
<Rotors>ABC</Rotors>
<FocusRadioNr>1</FocusRadioNr>
<IsStereo>False</IsStereo>
<IsSplit>False</IsSplit>
<ActiveRadioNr>1</ActiveRadioNr>
<Technique>SO2R</Technique>
<StationType>R1</StationType>
<IsTransmitting>False</IsTransmitting>
<IFFrequency>8215000</IFFrequency>
</RadioInfo>
</pre>

===Antenna direction===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program.
|-
| station
| The ID of the station.
|-
| radio
| The radio associated with the rotator.
|-
| go
| True if the rotator should be turned.
|-
| stop
| True if the rotator should be stopped if it is turning.
|-
| azimuth
| The direction to turn the rotator if go is True.
|-
| frequency
| The transmit frequency of the specified radio.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<Rotator>
<logger>DXLog v2.4.13</logger>
<station>STN1</station>
<radio>2</radio>
<go>True</go>
<azimuth>252</azimuth>
<frequency>2800200</frequency>
</Rotator>

</pre>
<pre><?xml version="1.0" encoding="utf-8"?>
<Rotator>
<logger>DXLog v2.4.13</logger>
<station>STN1</station>
<radio>2</radio>
<stop>True</stop>
<frequency>2800200</frequency>
</Rotator>
</pre>

===Callsign lookup===

Sent either when callsign in entry row is changed or when space or tab is pressed.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program.
|-
| contestname
| The name of the contest.
|-
| mycall
| Station's call
|-
| band
| Current band
|-
| txfreq
| Transmitter frequency
|-
| operator
| The call sign of the logged in operator
|-
| mode
| Operating mode
|-
| call
| Call entered in the logging field
|-
| countryprefix
| DXCC entity prefix
|-
| wpxprefix
| WPX prefix
|-
| azimuth
| Short path antenna direction
|-
| distance
| Distance in km
|-
| stationid
| The ID of the station sending the datagram
|-
| stationtype
| The role of the station sending the datagram; R, R1, R2, M, or R+
|-
| period
| Contest period
|-
| reason
| Reason for transmission; SpaceOrTab or CallChanged
|-
|}

Example message:

<pre><?xml version = "1.0"?>
<lookupinfo>
<logger>DXLog v2.4.20</logger>
<contestname>DARC-WAEDC-CW</contestname>
<mycall>K1XM</mycall>
<band>20</band>
<txfreq>1400200</txfreq>
<operator></operator>
<mode>CW</mode>
<call>E7DX</call>
<countryprefix>E7</countryprefix>
<wpxprefix>E7</wpxprefix>
<azimuth>54</azimuth>
<distance>6824</distance>
<stationid></stationid>
<stationtype>R</stationtype>
<period>1</period>
<reason>SpaceOrTab</reason>
</lookupinfo>
</pre>

===Spot===

Sent for every incoming spot from the DX cluster that is valid for the current contest.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| Application sending the message.
|-
| StationName
| The station issuing the broadcast.
|-
| dxcall
| The callsign of the spotted station.
|-
| frequency
| Frequency in kHz with decimal sign of the PC's current locale. (sic)
|-
| spottercall
| The callsign of the spotter. Station name if locally spotted or result of a logging operation.
|-
| timestamp
| Spot time in format yyyy-MM-dd HH:mm:ss
|-
| action
| add or delete.
|-
| mode
| actual or guessed mode of the spot in capitals.
|-
| comment
| The comment section of the spot.
|-
| status
| Spot status. Valid values are "dupe", "double mult", "single mult", and "new qso".
|-
| statuslist
| Same as status
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<spot>
<app>DXLog.net</app>
<StationName>CONTEST-PC</StationName>
<dxcall>E7DX</dxcall>
<frequency>14022.3</frequency>
<spottercall>SM7IUN-#</spottercall>
<timestamp>2O23-07-15 14:29:37</timestamp>
<action>add</action>
<mode>CW</mode>
<comment>CW 31 DB 42 WPM CQ</comment>
<status>single mult</status>
<statuslist>single mult</statuslist>
</spot></pre>

===Broadcast listener===

DXLog also listens for commands over UDP.

Currently only one command is implemented, <code><radio_setfrequency></code>, which is a QSY command.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| Application sending the command
|-
| radionr
| The radio to be changed. In SO2V radio 2 means VFO B. Optional as of DXLog 2.5.20.
|-
| frequency
| Requested frequency. Both period and comma is accepted as decimal separator.
|-
| mousebutton
| Which mouse button was used to create message, if any. Optional.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<radio_setfrequency>
<app>WaterfallBandmap</app>
<radionr>1</radionr>
<frequency>21022.194</frequency>
<mousebutton>Left</mousebutton>
</radio_setfrequency>
</pre>

==SDR integration==

===HDSDR, OmniRig, and microHAM===

''Contributed by Ingo SM5AJV/SE5E''

Until DXLog offers SDR integration there are still ways to get a waterfall/spectrum display with DXLog.

I have integrated the free SDR software [http://www.hdsdr.de/ HDSDR] with DXLog using
[http://www.microham.com Microham Device Router], 
[http://dxatlas.com/OmniRig/ OmniRig]
and [https://www.autohotkey.com/ AutoHotkey].

As illustrated below I place the HDSDR window at the very top of the desktop with DXLog right below.

I share my transceiver's (an Elecraft K3) antenna with the SDR. The receiver antenna signal from my 
K3's RX-ANT OUT is connected to the input of a 3dB power splitter. The two outputs from the splitter 
are connected RX-ANT IN on the K3 and the SDR Receiver antenna input, respectively. On a K3 you 
need to enable the RX-antenna input to make this to work. An additional benefit with this method 
is that the SDR is protected during transmission. It is a widely used method and is e.g. described 
by Bob N6TV in this
[http://dxlog.net/sw/files/utilities/Adding%20an%20SDR%20to%20an%20SO2R%20Station.pdf presentation].

'''Screenshot of my desktop:

[[Image:Sdrdesktop.png|800px]]

Since both DXLog and HDSDR need to communicate with the radio, you need to "split" 
the CAT communication. microHAM's USB Device Router provides a second, independent, 
CAT port that can be used via HDSDR's omniRig interface.

'''"PORT" Tab on microHamRouter:

[[Image:Sdrmicrohamrouter.png|800px]]

'''OmniRig settings in HDSDR:

[[Image:Sdromnirig.png|200px]]

With this set up, the radio, DxLog, and HDSDR will be fully synchronized. For instance, you can 
click in the waterfall to make the radio QSY, and it is easy to quickly find a clean frequency.

To make the integration even better I use a small AutoHotkey script. The script pulls entry focus 
back to DxLog after clicking on the HDSDR waterfall and in DXLog it allows you to use hotkeys to 
control HDSDR. <code>[Ctrl][Alt]+</code> and <code>[Ctrl][Alt]-</code> zooms the waterfall/spectrum 
in and out, and <code>[Ctrl][Alt]C</code> centers it.

'''AutoHotkey script:

SetTitleMatchMode, 2
#InstallKeybdHook
#IfWinActive, HDSDR
{
F4:: return ; disable F4
~LButton Up::
sleep, 1
Winactivate, DXLog
return
}
#IfWinActive, DXLog
{
^!+:: ControlSend ,, ^{+}, HDSDR
^!-:: ControlSend ,, ^{-}, HDSDR
^!c:: ControlSend ,, {c}, HDSDR
}

The script can be downloaded [http://DXLog/sw/files/utilities/dxlog_hdsr.ahk here].

If you start two instances of HDSDR with two different SDR you can even have two waterfalls 
running at the same time.

I have not yet found a way to display cluster spots in the HDSDR spectrum panel. 
But I still find it very useful to check band activity and it allows me to easily find 
a new Run frequency on a crowded band.

===Waterfall Bandmap===

The free waterfall/spot display utility "Waterfall Bandmap" by Steve N2IC is supported by DXLog.

Waterfall Bandmap supports almost any SDR that produce I/Q output either via ExtIO.DLL or a 
sound card; SDRPlay, FunCubeProPlus, HackRF, SDR-IQ, RTLSDR, SoftRock, etc.

A zip file with an executable binary and a Microsoft word document with installation and 
configuration instructions can be found here: https://groups.io/g/waterfallbandmap/files

If you are not a member of the support forum group, you need to apply for membership to download. 
Membership is free.

[[Image:Waterfallbandmap.png]]

The SDR can be connected either to a separate receive antenna, an external receiver output on 
your transceiver or to an IF output, should your transceiver have one. If connected to an antenna, 
keep in mind that you may need protection from the transmitter such as a T/R relay or a passive level limiter.

Please refer to Waterfall Bandmap's documentation for setting it up with your SDR.

Waterfall Bandmap needs two information feeds over UDP: Radio information and spot information. 
Both are provided as UDP broadcast by DXLog.

The default port for both is 13063 and this needs to be set in DXLog's Network configuration panel. 
If Waterfall Bandmap runs on the same computer as DXLog, the broadcast address can be left at the default 127.0.0.1.

[[Image:Setbroadcastportsforwfbandmap.png]]

Clicking on the waterfall display can set the frequency of DXLog. (Left click sets VFO A, right click sets VFO B.) 
To enable this functionality, check the option <code>Options|Broadcast|Receive Broadcasts</code> 
Also make sure "UDP broadcast listener" includes port 13064 in the network settings panel.

The radio information feed needs to be enabled by checking the <code>Options|Broadcast|Radio information</code> option

[[Image:radiobroadcastenable2.png]]

and the spot feed needs to be enabled by checking the <code>Options|DX Cluster|Send spots to SmartSDR</code> option.

[[Image:Enablesendspotstosmartsdr.png]]

==Time synchronization==

In a multi-station setting, the time needs to be accurately synchronized across all networked PC.

Windows' built in time synchronization is very crude and for a PC with poor clock stability the 
inaccuracy of the clock may be up to a minute. Which of course is not acceptable for contesting.

DXLog has built in support for time synchronization as described in the [[Menu Options#Configure network|Configure network section]].

Due to Windows' security system, this however requires all except the PC running as time server to 
run DXLog with elevated permissions. There is unfortunately no way around this inconvenience.

An equally accurate and less intrusive method is to use a standalone time synchronization application on each networked PC. 
This will keep each PC's clock accurate within a fraction of a second.

Contrary to a solution built into a logger it also has the great benefit of being an "install and forget" solution.

A popular application is Dimension 4 by Thinking Man Software. It is free for personal use and 
can be downloaded here: https://dxlog.net/sw/files/utilities/d4time531.msi

It runs in the background and only shows up as a tiny icon in your system tray. 
You hover the mouse above the icon to check status and right-click to open and change settings.

:::[[image:dimension4tray.png|50px]]

After installation a brief configuration is required.

First of all, allow the application to disable Windows' time service and to modify your system clock.

For maximum accuracy, select a time server geographically close to your location. 
When in doubt, you can always add the global server "pool.ntp.org" to the list and use that. 

There are also national and continental pools of time servers. You can find them here https://www.ntppool.org.

[[image:dimension4b.png]]

Make sure the check boxes "Load Dimension 4 at startup", "Start minimized", "Hide when minimized", 
and "Display icon in tray" are all checked.

[[image:dimension4advanced.png]]

Click the Advanced button and also make sure the option "Use the selected server" is selected.

Make sure the application reports a successful connection to the selected time server. 
From here on, you can basically forget the application. 
It will silently start with your PC and always keep its time accurate.

==Disabling USB power management==

In the interest of saving energy, Windows habitually power down USB interfaces 
when it believes there is inactivity. Some USB-to-serial and USB audio devices 
respond poorly to being suspended or powered down so as a rule this "feature" should 
be disabled when used in a ham radio environment.

There are two places where this functionality needs to be disabled; the device driver 
and Windows' energy management.

To disable it for each USB interface and device, open Windows settings. (Click the Windows 
icon in the lower left corner and then chose the cogwheel.) Type ''device manager'' and
select the result.

[[image:devicemanager-c.png|none|frame]]

This opens up a new window, Windows' Device Manager.

[[image:devicemanager2b.png|none|frame]]

For '''every''' USB interface component (there may be many), COM-port, and audio device, 
and '''uncheck''' the option ''Allow the computer to turn this device off to save power''.

The devices you are looking for are in the categories: ''Ports (COM & LPT)'', 
''Sound, video and game controllers'', ''Universal serial bus controllers'',

Note that some devices may not have a ''Power Management'' tab.

[[image:usbdevicemanager.png|none|frame]]

The next step is to disable Windows ''Selective suspend'' feature for USB interfaces.

Go back to Windows Settings and type ''edit power'', click the appearing ''Edit power plan'' menu entry.

[[image:editpowerplan2.png|none|frame]]

This should open the window below, the plan editing panel.

[[image:editplansettings.png|none|frame]]

Click ''Change advanced power settings''. Scroll down to ''USB settings'' and make 
sure ''USB selective suspend setting'' is '''disabled''' for all situations.

[[image:Advancedsettings.png|none|frame]]

To prevent audio devices from becoming unreachable or going into sleep mode you should also 
disable exclusive access. While changing this, also make sure all audio enhancements are disabled.

You reach the detailed audio device settings by entering Windows settings, search for Control panel, 
and in the Control panel view, select Hardware and audio, and then Sound.

[[image:Audiodevice.png]]

Reboot your computer to make sure all settings are recognized by Windows.

==Interlock and inband operation==

In contest station terminology, the term ''Interlock'' refers to a technical solution preventing 
more than one station from using a shared resource, typically an antenna, at the same time.

The most common use for interlock is for inband operation. Inband operation means to have multiple 
transmitters on a single band, interleaving their transmissions. Sometimes on a split-second basis.

As long as you never have more than one transmitter active at any time, the majority of contests allow 
an unlimited number of transmitters and receivers on a single band for multi-operator categories. 
This fact is used by most big contest stations.

For an inband solution to be effective, each station must be able to receive while the 
other station transmits. This means it requires a separate, high performance receive antenna 
with very good isolation from the transmitter antenna. The most common way to 
achieve this is physical separation and geographic orientation to minimize the situations 
when they will radiate/listen in the direction of the other antenna.

For a station operating in the M/M, M/S, or M/2 category, inband operation can boost the points 
per hour performance significantly. It is also a lot more fun.

However, as with everything else, it comes at a cost. An efficient inband solution has:

* A high performance receive antenna for each operated band(s) with very good isolation from the transmitter antenna.
* A fail-safe antenna switching hardware.
* Interlock-capable keyers and/or station controllers.
* An interlock-capable contest logging software

A typical inband configuration can be seen in the illustration below.

[[image:inbandconcept-trx.jpg|800px]]

DXLog offers a software-based interlock which can be configured in a variety of ways, e.g. based on frequency 
band, operating mode, or station role. It supports an unlimited number of stations interlocking each other 
using a great variety of strategies.

The interlock relies on UDP networking and is overlaid on the communication for multi-station logging. 
UDP networking has the benefit of speed and low latency but is, unlike TCP, susceptible to packet loss. 
This means that a '''wired LAN''' is a necessity for any station using interlock. 
For the same reason, it is also not recommended to run interlock over e.g. VLAN/VPN link for 
geographically distributed stations.

A software interlock is not 100% reliable. Computer or software malfunction, networking issues such as packet 
loss, etc. can cause interlock to fail, even if only momentarily.

For this reason it is necessary to also accompany a software interlock with a fail-safe '''hardware''' interlock. 
Without hardware supported interlock you run the risk of not only violating contest rules but also cause serious equipment damage. 
Some contests, such as CQ WW, explicitly requires hardware interlock when using multiple stations on the same band.

There are many designs and even commercial products available for hardware interlock. 
One example of a simple but effective two station hardware interlock which also supports 
power amplifier sharing can be found [https://sm7iun.se/contest/inband/ HERE].

The purpose of this section is to describe steps of setting up a basic two station in-band solution with 
DXLog and microHAM keyers. The microHAM keyers are not mandatory but offers a much better user experience 
and removes the need for additional hardware.

'''Pro tip:''' Consider checking <code>Options|Networking|Allow other stations to abort sending</code> 
which will allow your partner station to interrupt your transmission with <code>[Shift][Esc]</code> in 
critical situations. Be careful though, the use of this function requires good judgment to avoid violence.

===Networking===

Open the networking configuration panel with <code>Options|Configure network</code> and make sure each 
station has a unique name and that only UDP networking is enabled.

Make sure the two stations use the same broadcast IP address and that it is in line with your LAN's 
configuration. Pressing the <tt>Default</tt> button is a good way to ensure this.

Make sure the menu option <code>Options|Enable network</code> has a checkmark.

[[image:inbandnetworkrun.png|left|frame]][[image:inbandnetworkinband.png|none|frame]] 

===DXLog Interlock configuration===

First of all, make sure that the <code>Options|Interface specific options|Prevent TX if another radio is on same band</code> 
is '''not''' enabled. This option completely prevents transmission if more than one networked station is set to the same band 
and the whole idea with inband is to have exactly that.

Next, activate software interlock on both stations using the menu option <code>Options|Networking|Software interlock</code> 
or by typing the commmand <tt>ILOCKON</tt>.

[[image:inbandinterlock2.png|none|frame]]

There are multiple options for configuring the interlock. In a simple set up with only two stations, the topmost 
option ''Same band from status list'' is a good choice. This option will prevent more than one station transmitting 
on the same band, regardless of mode.

In an environment with many stations (such as a multi-operator-multi-transmitter station) it is 
recommended to use the bottom option to only interlock with one or several named stations. 
This will reduce both LAN traffic and inband operation latency. This is particularly important when 
running parts of the DXLog network over high latency links such as VLAN/VPN or if some stations (albeit not 
part of the interlock cluster) are connected via Wi-Fi.

For more advanced scenarios you can also use interlock based on mode or station type (e.g. Run 1, Run 2, Mult, etc.).

The "status list" listing the networked DXLog stations is displayed in the ''Status Window'' which is opened 
with <code>Windows|Status window</code> or <code>[Alt][J]</code>.

[[image:inbandstatuslist2.png]]

DXLog also offers great flexibility when it comes to interlock strategy. The most straightforward and 
most commonly used is ''First one wins''. This is also typically the behavior of "unintelligent" 
hardware solutions when not assisted by software. With this strategy, the station starting to transmit 
first can not be interrupted and always gets to finish its transmission.

[[image:inbandinterlockoptions.png]]

With a ''Last one wins'' strategy, the transmitting station can be interrupted. A carte blanche permission 
to interrupt all transmissions by the other station may however be counterproductive in a real contest situation.

For this reason, DXLog offers additional control of which transmit actions can be interrupted and which can not. 
This is a powerful tool but requires both operators to be aware of it and may require 
practice before fully effective.

[[image:inbandstrategyexceptions.png]]

''F1'' through ''F7'', ''PLUS'' and ''INS'' refers to DXLog's standard messages. ''KEYB'' means a free text transmission 
from the keyboard using the <code>[Alt][K]</code> function and ''MAN'' means manual transmission using either paddle 
break-in or a footswitch.

For CW, DXLog recognizes paddle break in from a K1EL Winkey-compatible keyer as described in the [[Menu_Options#Winkey_Configuration|Winkey configuration section]].

Since DXLog recognizes a footswitch connected to a microHAM device, this is a recommended approach for phone. 
It is also possible to connect a footswitch to the DSR pin (pin 6) on a physical COM-port on the PC, but today 
few PC have such a port and it also requires additional circuitry.
Details on how to do this is available [[Additional_Information#Connecting_a_footswitch|HERE]].

===microHAM configuration===

Open the microHAM device configuration panel with <code>Options|microHAM device configuration</code>.

[[image:Mk2r-new9.png|none|frame]]

Check the option ''Enable TX lock/unlock''. This will do two things; it will enable DXLog to prevent 
transmission and and it will make DXLog aware of the microHAM device's PTT status. The latter is particularly 
important since it means DXLog will recognize PTT assertion not only by a footswitch connected to the 
microHAM device but also by the built-in Winkeyer (requires microHAM USB Device Router version 9.3.0 or later) 
'''Paddle-based break-in in an inband solution is currently unique for microHAM with DXLog.'''

'''Important:''' Making DXLog "PTT aware" means that care has to be taken in how PTT is set up. If you, for instance, 
enable DXLog PTT for the voice keyer, this will create a self-reinforcing feedback loop and PTT will thus never drop.

Check the option ''Dual radio device'' if you are using a u2R, MK2R, or MK2R+, otherwise, leave this unchecked.

Check the option ''Device without CAT interface'' if the device lacks a CAT interface (like the u2R) 
or if its CAT interface is not connected to the radio. This option will make sure the e.g. keying and 
audio routing is always set correctly in line with the operating mode (Voice, CW, or RTTY).

===Operating===

Inband operation requires a fair amount of training and it is a good idea to define and agree 
on general rules for operation, such as hand signals for challenging QSO, beforehand.

There are more than enough YouTube videos of inband operators yelling at each other.

The operating tactics may have to be adjusted during the contest. If Run is slow, 
doing S&P on the inband station can increase the points per minute significantly. 
However, if Run is strong, an overly active inband operator doing S&P, but not working 
multipliers, may actually reduce the station's points per minute significantly.

Real-time interlock status is shown in the ''Radio status'' window, which is opened with 
<code>Windows|Radio status</code>.

[[image:inbandblocking.png]] [[image:inbandblocked.png]]

For Phone contesting, you typically rely on footswitches for PTT and the option 
<code>Options|Networking|Show QSO status when blocking</code> makes the blocking 
station send a more helpful blocking cause than ''MAN''.

With this option enabled, the blocking station will instead send ''CQ'', ''QSO'', or ''EXCHANGE'' 
as blocking cause, determined by cursor location and entry field content at the locking station.

Further reading can be found in the [[Menu_Options#microHAM_device_configuration|microHAM device configuration]] and [[Menu_Options#Networking|Networking]] sections.

==Connecting a footswitch==

To free up both hands in Phone contesting, a footswitch PTT is a great help.

Also, to use interlock in Phone contesting, a footswitch is mandatory.

There are two basic ways to interface a footswitch with DXLog; via a microHAM device (which is the recommended solution) 
or directly connected to a physical serial port on the PC (which very few PC have today).

The connection of a footswitch to a microHAM device is very straightforward and by checking the ''Enable TX lock/unlock'' 
in the ''microHAM device configuration'' panel, it is recognized by DXLog.

Lacking a microHAM device, it is also possible to use the computer's DB9 RS-232 serial port connector, providing it has one.

The required steps to do this are:
* Connect a 10k resistor between DB9 pin 6 and pin 7.
* In the port's settings (<code>Options|Configure interfaces</code>) set DTR (pin 4) to ''Always On'' and RTS (pin 7) to ''Always Off'' for the port.
* Connect the footswitch between DB9 pins 4 and pin 6. '''Important:''' Neither pole on the footswitch must be connected to ground.
* In the radio's configuration panel, check ''use CAT PTT command on Phone'' and set ''Footswitch (pin 6)'' to ''PTT''

==Support for CC Cluster==

CC Cluster is today the main choice for contest use.

It offers a high quality, database-verified, flow of skimmer spots and a rapid 3-minute respotting period for skimmer spots.

It also publishes unique spots from less common locations which are valuable for DX chasers or as contest multipliers.

To make use of the display of own spot in the world map, make sure to issue the command '''<tt>SET/OWN</tt>''' to the cluster node. 
This setting is persistent and only needs to be done once.

A list of cluster nodes that runs CC Cluster can be found here: [https://www.dxcluster.info/telnet/index.php?software=CC%20Cluster CC Cluster nodes]

A description of the command line syntax can be found here: [http://bcdxc.org/ve7cc/ccc/CCC_Commands.htm CC Cluster command syntax]

A convenient software for setting up filters etc. can be found here [http://www.bcdxc.org/ve7cc/default.htm#prog CC User]

[[Image:Ccclustersspotflow.png]]

==Support for AR Cluster 6==

With the author tragically SK, AR Cluster is no longer under development but still available as an executable binary.

In its standard configuration, AR Cluster offers no consolidation of skimmer spots meaning a very high flow of spots 
that can become extreme during a major contest weekend.

With the advent of skimmers, the traffic on the DX Cluster has risen dramatically. Even though CW skimmers are generally 
quite reliable, the absolute number of busted spots can be quite high during a busy contest.

Jose CT1BOH has developed an algorithm for evaluating spot quality which is included in version 6 of AR Cluster. 
Today many cluster nodes runs this version and thereby offer this mechanic. 
A complete list can be found here: [http://www.dxcluster.info/telnet/index.php?software=AR-Cluster AR Cluster nodes]

To enable the functionality on a cluster node running AR Cluster 6, the command

<tt>'''SET DX EXTENSION SKIMMERQUALITY'''</tt>

needs to be issued to the cluster node. The easiest way to do this in DXLog is via <code>[Alt][T]</code>. 
This setting will be remembered at subsequent logins.

The quality of the spots is indicated by a character ("tag") in the last column of the comment field and, 
in some cases, a corrected callsign within parenthesis. This syntax is recognized by DXLog and can reduce the 
number of bad spots in your bandmap.

The CT1BOH skimmer quality algorithm is based on three parts:

; Validation : When a callsign is first spotted, it is tagged with "?" in the last column of the spot's comment field. If the callsign of an unverified spot closely resembles an already verified one on the same frequency, the verified callsign is provided within parenthesis in the spot's comment field. When two or more skimmers agree on the spot, it is considered verified and the tag becomes "V".

; Frequency : When a verified spot appears more than 0.35kHz off its verified frequency, the spot is tagged "Q" for QSY. Once verified, this becomes the new verified frequency and it is tagged "V".

; Probability : The algorithm checks uncertain spots for resemblance with already verified spots and spots at or near the same frequency. If the resemblance is high enough, the spot is considered busted "B" and the corrected callsign is provided within parenthesis in the spot's comment field.

Below you can see an example of the spot flow from W9PA-4 with skimmer quality enabled. 
The flow contains one unverified and one busted spot.

[[image:spotquality.png]]

DXLog's policy for spots with CT1BOH skimmer quality tags is the following:

: '''V''' - Accept spot.
: '''Q''' - Accept spot.
: '''?''' - Accept spot. Use corrected call when provided.
: '''B''' - Accept spot if corrected call provided. Else ignore.

DXLog recognizes the skimmer quality tags but consolidates them for consistency 
with other cluster nodes' quality tags and to minimize confusion when mixing spot flows. 
The legend is:

: '''?''' means a spot with ? This is an unreliable spot.
: '''P''' means a spot with Q or B with correction. This is a fairly reliable spot.
: '''V''' means a spot with V. This spot is considered validated.

This basic policy can be modified by using additional filters at the cluster node end. Some examples are:

: <tt>'''SET DX FILTER NOT SKIMBUSTED'''</tt> - Do not send busted spots at all
: <tt>'''SET DX FILTER NOT SKIMQSY'''</tt> - Do not send QSY spots
: <tt>'''SET DX FILTER SKIMVALID'''</tt> - Only send verified spots
: <tt>'''SET DX FILTER NOT SKIMUNKNOWN'''</tt> - Do not send unreliable spots
: <tt>'''SET DX FILTER SKIMMER'''</tt> - Do not send manual spots

You can also compose more complex filters such as:

: <tt>'''SET DX FILTER SKIMVALID OR SKIMBUSTED OR NOT SKIMMER'''</tt>

This can be a good filter for most contests. It will will only provide valid or busted skimmer spots together with manual spots. 
It is safe to receive busted spots since DXLog will ignore them if there is no corrected callsign included. 

For assisted operation in serious contesting you however need to allow also unknown spots since weak stations spotted 
only by one or a few skimmers may never reach validated status. You do this by adding <tt>'''OR SKIMUNKNOWN'''</tt> to the filter.

Both the bandmap and the DX cluster announcement windows have the option to display the spot quality tag. 
These windows will show two additional tags; L and C. L stands for local spot, created by yourself or one of your team members. 
C stands for corrected, i.e., a B or ? spot where a corrected call has been included in the spot's comment field.

The AR6 filtering syntax offers a lot of flexibility. Another example:

: <tt>'''SET DX FILTER (SKIMVALID OR NOT SKIMMER OR ((SKIMQSY OR SKIMUNKNOWN) AND (CTY <> K AND CONT <> EU )))'''</tt>

will provide only validated and human spots except if they are from outside the US and EU.

If you get lost in the filter settings you can always reset with : <tt>'''SET DX DEFAULT'''</tt>.

Some more guidance on how to work with filters on AR-Cluster nodes can be found in [http://dxlog.net/sw/files/utilities/AR_Cluster_v6_User_Manual.pdf this document].

==Support for DXSpider==

DXSpider is the by far most dominant DX cluster software but has historically not been a good choice for contesters. 
The reasons for this include: Long respotting time, lack of pass function for own spots, and suppression of spots from a single skimmer.

The good news is however that the author Dirk G1TLH has worked hard to address these aspects of the otherwise brilliant software.

From '''version 1.57 release 440''' the respotting time is now 3 minutes and there is a <tt>SET/SEEME</tt> command that passes all spots 
without consolidation of your own callsign.

So if your favorite cluster node is not running this version, ask the owner to upgrade asap.

Yet another reason for its popularity is its extreme resource-efficiency which allows it to run virtually 
any Linux capable hardware, including a $20 Raspberry Pi Zero.

A list of all DX cluster nodes running DX Spider can be found here: [https://www.dxcluster.info/telnet/index.php?software=DX%20Spider DX Spider cluster nodes]

[[image:dxspiderflow.png]]

DXLog recognizes the <tt>Q:#</tt> skimmer quality tag in the comment field and converts them into "CT1BOH-like" quality 
tags that can be displayed in DXLog's bandmap. The legend is:

: '''?''' means a spot with Q:1, i.e. heard by only one skimmer. This is an unreliable spot.
: '''P''' means a spot with Q:2, i.e. heard by only two skimmers. This is a fairly reliable spot.
: '''V''' means a spot with Q:3 or higher, i.e. heard by several skimmers. This spot is considered validated.

Since a DXSpider node currently needs to be specially configured by the owner to publish Q:1 spots, very few do this. 
Also, since DXSpider lacks busted call detection, the the quality of the spot flow will suffer if this is done.

There is a wealth of information to be found on the [http://wiki.dxcluster.org/index.php/Main_Page DXSpider wiki].

==Support for N2WQ Cluster==

Introduced in late 2025, Rudy N2WQ has developed the first new DX cluster node software in decades.

The N2WQ-2 cluster has some unique features like a more advanced callsign validation than 
AR 6 and propagation estimation tags embedded in the spot comments. An example can be seen below.

[[image:n2wpspotflow.png]]

When you connect to dxc.n2wq.com port 8300 and you have set your 4-digit Maidenhead grid (SET GRID), there 
will be a single character just before the DX’s grid locator. This character is the path prediction glyph.

It is a crowdsourced, real-time estimate of how reliable the path is between you and the DX on that band right now, 
based on recent on-air propagation reports from RBN and PSKreporter. Its values and meaning are:

: > High: Strong path. If you can hear them, you should be able to work them.
: = Medium: Decent path. Workable with normal contest/DX technique.
: < Low: Weak path. Possible, but expect repeats, timing, and patience.
: - Unlikely: Marginal. Try only if it’s rare/needed, or you have a strong station advantage.

A missing glyph means insufficient data to estimate the path.

the glyph is mode-aware. A path that looks great for a very sensitive mode (FT8) can look 
more moderate for a less sensitive one (SSB).

You can filter spots by path reliability using the PASS/REJECT PATH command.

It is important to be aware that the glyph does not know:

: Your antenna gain/pattern, height, or takeoff angle
: Your transmit power and duty cycle constraints
: Your operating technique (timing, split discipline, pileup strategy)
: Short-lived phenomena the network has not yet “seen” such as sporadic E or aurora.

The cluster ingests upwards of 50,000 CW, FT, RTTY, and WSPR spots per minute. To compare different modes 
fairly, the system normalizes reports onto a common “FT8-equivalent” scale (so a CW SNR can be compared 
to an FT8 SNR).

Your grid and the DX grid are mapped into small geographic cells and the cluster calculates propagation 
at two levels:

: Fine (local): what’s happening close to your area (~180 miles).
:: On averages there are about 90,000 DE/DX pairs being tracked
: Coarse (regional): what’s happening in the broader region around
:: you (~480 miles). On average, there are about 30,000 DE/DX pairs.

If there isn’t enough local data, the system leans more on regional behavior. 
If there’s plenty of local data, it uses that more heavily.

Sometimes you can hear them better than they can hear you (or the reverse) due to noise 
floors, antennas, geography, or ionospheric effects. The system tracks both:

: Receive direction: DX to you (can you hear them?)
: Transmit direction: you to DX (can they hear you?)

It combines these into one “path reliability” estimate, weighting receive a bit more 
because if you can’t hear them, you can’t work them.

Propagation changes fast, so older reports get discounted using a half-life (data fades 
in influence over time). Typical behavior by band:

: Low bands (160/80m): slower changes (longer half-life)
: Mid bands (40–20m): medium pace
: High bands (15–6m): fast changes (shorter half-life)

In practice, this means glyphs can shift in minutes on 10m/6m, and more slowly on 80m/160m. 
Also, new openings take time to show up. A "insufficient" can simply mean “the path just opened 
and the cluster hasn’t collected enough recent reports yet.”

Your local noise floor heavily affects what you can receive, so the cluster lets you tell 
it what your noise environment is. This mainly tunes the receive-side expectation (DX to you).

Set it with SET NOISE SUBURBAN. Available profiles per ITU:

: QUIET: very low noise, rural/remote
: RURAL: mild noise
: SUBURBAN: typical neighborhood QRM
: URBAN: elevated noise, dense housing
: INDUSTRIAL: severe noise

If you don’t set it, the system may assume a quieter environment than you actually 
have, and your receive-side glyphs can look too optimistic.

Treat the glyph as a real-time probability hint that helps you spend your operating 
time where the odds are best. When you see > on a needed multiplier, move fast. 
When you see -, be intentional about whether it’s worth the time. 
And when you see a space, fall back to classic DX/contest instincts and your own ears.

The N2WQ cluster also offers spot quality tags between the DX grid and the time.

A quality (in terms of callsign reliability) tag can be V, P, S, C, or ? where V means validated, 
P highly likely, S less likely, C corrected, and ? unsure.

The propagation and quality tags can be displayed in the bandmaps and the DX cluster announcement window.

DXLog recognizes the skimmer quality tags but consolidates them before display for consistency 
with other cluster nodes' quality tags and to minimize confusion when mixing spot flows. 
The legend is:

: '''?''' means a spot with ? or S. This is an unreliable spot.
: '''P''' means a spot with P or C. This is a fairly reliable spot.
: '''V''' means a spot with V. This spot is considered verified.

==Interacting with WSJT-X==

Important: When in a DXpedition/multi-station setting, always use local host 127.0.0.1 as the 
broadcast address to prevent packets being picked up by other stations in the network. 
Also, enabling the creation of local spots from decodes may overwhelm DXLog.

DXLog can add QSO performed with WSJT-X to its log. Note that this functionality only works 
for contests with grid as the first and only exchange or for DXPedition type logs.

DXLog can also create local spots from WSJT-X decodes by checking 
<code>Options|Broadcast|Spot WSJT-X decodes</code>.

To enable logging of WSJT-X QSO, set up WSJT-X to broadcast information:

[[image:Wsjt-x-udp.png]]

[[image:Radiobroadcastenable3.png]]

Activate DXLog's UDP listener by checking <code>Options|Broadcast|Receive broadcasts</code> and set 
the same port number as in WSTJ-X in DXLog's network configuration panel.

[[image:Dxlog-udp.png]]

==Using Winkey FSK==

Winkey FSK is not natively supported by DXLog's digital mode engines MMVARI or MMTTY but 
Rafal EI6LA has developed a plugin for MMTTY that makes this possible.

You can find it [https://github.com/RafalLukawiecki/WinKeyerMMTY here].

==Interfacing with LogHX==

Christian F8GHE has prepared a guide on how to do this.

You can find it [http://dxlog.net/sw/files/utilities/DXLOG-LogHX_UDP-config_v2.pdf here].

==Self-spotting==

More and more contests allow spotting your own station on the DX cluster.

DXLog supports this, even when operating unassisted, as long as you connect to the cluster.

DXLog has three mechanics for self-spotting.

DXLog blocks self spotting unless specifically allowed in the contest rules. 
Should you find that DXLog incorrectly allows or blocks self-spotting, please make 
the development team aware via the support reflector.

* The <tt>$SPOTME</tt> macro command. This macro will create a cluster spot of the station's
: call at the earliest 15 seconds after being invoked the first time on a new frequency.
: Thereafter it will spot as frequent as allowed by the contest. If the contest rules do not
: specify a minimum period, 10 minutes will be used.

* Checking the menu option <code>Tools|Data entry|Run F1 message self-spots when permitted</code>.
: Works exactly like the <tt>$SPOTME</tt> macro command but is triggered by sending the
: Run F1 message which happens when pressing <code>[Enter]</code> with an empty entry line
: in Run, pressing <code>[F1]</code> in Run, or with Auto-CQ.

* Clicking the menu item <code>Commands|Self-spot</code> or pressing its shortcut key <code>[Ctrl][S]</code>.
: This will immediately create a spot of the station's call but no more often than
: every two seconds to avoid accidental multiple spots.

==DXpedition use==

DXLog is a popular choice for top tier dxpeditions. Below we have collected advice based on experience 
on how to best use DXLog in a dxpedition setting.

* Use client/server networking between stations. Never use UDP over Wi-Fi or WAN links.
* Use the "Minimal data" option in ADIF export to save on satellite link cost.
* For Club Log real time upload, use [[https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads Club Log's upload app]]
* Club Log truncate QSO time to minutes so to avoid creating dupes when mixing manual and real time upload to Club Log, check ''QSO time in minutes'' when doing ADIF export.
* Use the "Minimal data" option in ADIF export to save on satellite link cost.
* Follow [[Additional_Information#Interacting_with_WSJT-X|the instructions]] to log QSO made with WSJT-X and MSHV.
* Check <code>Options|Broadcast|Spot WSJT-X decodes</code> to make decoded calls appear in e.g., DX cluster announcements.
* You can extend the number of digits in the QSO count with <code>Options|Log|QSO number digits</code>

==Beacon spots on DX cluster==

Although propagation measurements based on FT8 communications has reduced the 
value of beacons, there are still hundreds of them in operation.

Identifying with CW, they are typically reported on reported on the DX cluster.

When beacon spots are received by DXLog, they are always displayed in the bandmap. 
In DXLog, beacon spots are recognized by having a trailing <tt>/B</tt>.

The DX cluster announcement window never shows or counts beacon spots.

Beacon spots can be enabled and disabled in the cluster node.

For CC Cluster, the commands are <tt>SET/BEACON</tt> and <tt>UNSET/BEACON</tt>.

For DXSpider, command is part of the <tt>SET/SKIMMER</tt> command where <tt>SET/SKIMMER</tt> 
or e.g., <tt>SET/SKIMMER CW BCN FT RTTY</tt> will pass beacon spots and <tt>UNSET/SKIMMER</tt> 
or any <tt>SET/SKIMMER</tt> listing modes but not BCN will block them.

AR 6 cluster nodes always pass beacon spots when skimmer spots are enabled. They cannot be disabled.

Additional Information

2026-04-01T06:59:18Z

Sm7iun: /* DXpedition use */

==Using alternative configurations==

Window positions, coloring and general look and feel is saved in each log file but all other settings such as 
radio control, keying, and networking is saved in a common, contest-independent configuration file.

By default, the configuration file name is <tt>DXLog.net.config</tt> and it is located in the <tt>%appdata%\DXLog.net</tt> configuration folder.

This folder is also reachable via the <code>File|Open configuration folder</code> menu item.

[[image:configfolder.png]]

DXLog can be made to use an alternative configuration file with the command line option <tt>-cfg=<filename></tt>.

A convenient way to use this option is to create a separate Windows desktop shortcut including the command line option 
and give it a meaningful name.

[[image:Desktopshortcut.png]]

The command line option is simply added to the end of the Target text box in the shortcut's properties. 
Double-clicking the icon will start DXLog with the alternative configuration which will also be remembered between sessions. 
In the picture below the target of the shortcut is

[[image:Desktopshortcutconfig.png]]

'''Important:''' If you want to use an alternative configuration, do not just modify the desktop shortcut created at installation 
since this shortcut will be deleted when you upgrade DXLog. Instead make a copy, rename, and add the command line option. 
You should keep the command line option outside the apostrophes, like this

<tt>"C:\Program Files (x86)\DXLog.net\DXLog.net.exe" -cfg=SO2R.config</tt>

==Using a number server==

For contests involving serial numbers you need to secure that the sent number and the (slightly later) 
logged serial numbers are the same. In a straightforward SO1R or SO2V scenario, serial numbers are simply 
chronological but in more complex station configurations such as Multi-single or Multi-2 with inband, and 
advanced SO2R, QSO can be interleaved and requires a central source source of serial numbers together 
with a mechanic to protect an already sent serial number from re-use by another radio.

In DXLog this is achieved with a central number server. A number server can be used either 
by a single instance of DXLog (for SO2R) or by multiple stations on the same LAN.

The use of a number server involves three, natural, steps:

* Activating the server on a single station
* Making sure all stations use it
* Verifying functionality, making sure serial numbers are correctly reserved

The number server is activated in the <code>Options|Configure network</code> panel, described [[Menu_Options#Configure_network|HERE]].

[[image:startnumberserver.png]]

Since the server uses a networking socket, <code>Options|Networking</code> must be enabled '''also''' when 
using a single computer in SO2R. In the case of multiple stations, UDP networking or Client-Server 
networking must also be enabled to transfer the numbers over the LAN. For SO2R, this is however not 
necessary. When using Client-Server networking, a client cannot be number server.

There must only be one number server in a local network and all stations using it must have 
<code>Options|Networking|Use number server</code> checked like in the picture below.

'''Important:''' The number client/server functionality is not very robust. 
If you have stations joining/leaving your network or being rebooted, it is 
best to restart DXLog on all stations to guarantee correct function.

[[image:usenumberserver.png]]

The option <code>Block logging if serial number reservation is unsuccessful</code> can be used as an extra precaution 
but is not necessary in SO2R since the communication with the number server does not leave the computer.

There are three methods for reserving a number from the server:

* Checking <code>Tools|Data entry|Space key reserves serial number</code> and using the space key to reserve serial numbers. This is typically used on phone or when operating "old school" with F-keys.
* Checking <code>Tools|Data entry|Insert and F2 messages reserve serial number</code> and letting DXLog automatically reserve a serial number right before $SERIAL sends it. This is the preferred and most straightforward way for CW and digital.
* Adding the $RESERVENR macro to messages like illustrated below. 

These methods can of course also be combined. 

The $RESERVENR macro is "smart" and will only reserve a serial number if the callsign entry field is not empty and a 
serial number is not already reserved. The same goes for the menu items.

[[image:reservemessages.PNG]]

The sign of a serial number being reserved is that it turns red. It then stays reserved (and red) until the 
QSO is logged or the entry line is cleared with <code>[Alt][W]</code>.

An option that can prove useful is <code>Tools|Data entry|Cancel serial number reservation only if callsign field is empty</code>. 
In the case that you send the exchange and realize you got the other station's callsign call completely wrong, a reflex can be to hit 
<code>[Alt][W]</code> and start typing. If this is your habit, this option will prevent you from releasing the 
already sent serial number, thereby avoiding you the trouble to send a new one to the other station.

[[image:reservednumber.png]]

==Networking over internet==

When, for instance, activating a special event callsign it is possible to network multiple DXLog stations over the internet.

'''Pro tip:''' Consider displaying the callsign, message ID, Message text, etc. fields in the ''Network status'' 
window when operating a distributed station. Also, learn to use the gab <code>[Alt][G]</code> and <code>[Alt][J]</code> function.

===VLAN/VPN Solution===

The most secure way for remote networking is to rely on a VLAN (virtual LAN) software. There are several available such as:

ZeroTier https://www.zerotier.com/ 
FreeLan http://www.freelan.org/ 
Player.me https://player.me/ 
OpenVPN https://openvpn.net/

Each VLAN solutions have their own particular set up which is covered in their respective documentations. 
With a VLAN solution, all DXLog configurations are the same as when operating in a regular LAN however with a few exceptions.

One weakness with connections over the internet (a.k.a. WAN), including VLAN solutions, is that they are prone to packet loss. 
Packet loss is disastrous to DXLog's (or any logger's) "standard" UDP networking.

It is therefore essential to use '''only client/server networking over a VLAN'''. 
'''This also means you should never use interlock over an internet connection unless you use a zero packet loss VPN tunnel.'''

ZeroTier is particularly popular since it is free.

Since DXLog is able to mix TCP (client/server) and UDP (peer-to-peer) networking, a distributed station set up should be configured to rely on TCP 
for the wide-area network and UDP for the local network at each station location. Below you will find the station 
set up for the Swedish HQ station SE9HQ in the 2019 IARU HF Championship. The DXLog.net.DXC cluster client was run 
on SK3W-A which distributed spots to all stations over the network. Inband interlock was also used at the SK3W location.

[[image:SE9HQ-network-eng.png|800px]]

Important to note:

* For the server as well as the main clients, ''Server IP'' should be set to the server's VLAN IP address, '''not''' its LAN address.
* The '''server''' should check both "Act as network server" and "UDP network broadcast for multiple stations".
* The '''main clients''' should check both "Connect to network server" and "UDP network broadcast for multiple stations".
* The '''sub clients''' should check only "UDP networking for multiple stations".
* Interlock (which is UDP-based) over VLAN does not work reliably because of packet loss.
: Therefore, it is important to configure any interlock to '''only''' consider relevant operating positions,
: which all must be local. Use the possibility to only consider named stations for the interlock in the software 
: interlock set up. <code>Options|Networking|Software interlock</code> "Custom station ID(s)"
* For a large set-up with many stations connecting as clients to a central server you may overload the server if you also
: distribute spots via all client-server connections. In this case, check the "No spots via client/server" option
: on all stations and use '''local DX cluster connections''' via UDP at each location.
: '''Important:''' Limitations in Windows networking makes client/server networking unreliable beyond 10 station locations.
* Make sure to check <code>Options->Load contest at startup</code> to avoid opening the wrong log after a restart.
* '''Remote commands are not forwarded''' in the network but are executed in the station where they arrive.
: Thus, to clear all logs, disconnect networking on each main client, execute the remote command CLEARLOGNOW on each main client
: to clear the logs of all sub clients and do not reconnect until the server and all other main clients have done the same.

===Port forwarding Solution===

If you are less worried about competitors or government agencies listening in on your contest data, 
it is possible to route the traffic directly over the internet using port forwarding at the server.

'''Important security notice: This solution is not without risk. It offers no security or authentication. 
Any DXLog station running the same contest configuration, knowing the URL or IP address and IP port of the 
server can connect to the server station. There are no means to disconnect a station by force.'''

Also note the comment about '''remote commands''' in the section above.

With a port forwarding solution, the following must be observed:

* '''Server configuration'''
:* Only one of the stations should be configured as the '''server'''.
:* "Connect to network server" should not be checked on this station and
:: "UDP networking for multiple stations" should only be enabled if it is used to
:: communicate with a cluster client or other stations locally on the same LAN.
:: Either use a central cluster connection (uncheck "No spots via client/server")
:: or use one cluster connection per station location (check "No spots via client/server").
:: If one cluster connection per station location is used, make sure they
:: all use different SSID to prevent disconnects, such as E7HQ-1, E7HQ-2, etc.
:: This will ensure the cluster node regards all connections as having the same callsign
:: which is essential for e.g., correctly receiving own spots.
:* The PC acting as server must be configured for a fixed LAN IP address. This is done
:: either by manually configuring the networking settings in the PC to use a fixed
:: LAN IP address, or by setting up the router in the server's LAN to to always allocate
:: the same IP address to it.
:* The internet connection used by the server PC must ''either'' have a fixed public IP address ''or''
:: use dynamic DNS. Otherwise clients will not be able to reliable connect over the internet.
:* The server's TCP/IP port (e.g., <code>9888</code>) must be forwarded to the server by the server LAN's router.
:: Only TCP traffic should be forwarded. DXLog UDP traffic is not carried well over the internet.

:: [[image:serverconfig.png|600px]]
:: '''Example configuration for server for networking over internet'''

::[[image:portforwarding.png|600px]]
::'''Example of port forwarding UI in router'''

* '''All other stations'''
:* All other PC in the multi-station set up should be set up as clients.
:* Over the internet, "Server:" is either the static, public IP address of the server's internet
:: connection (e.g. <code>5.140.211.42</code>) or the dynamic DNS address (e.g. <code>hq.sm7iun.se</code>).
:: Clients connecting over the internet does not have to enable UDP networking and ''should not''
:: enable a server.
:* A client may connect via UDP if it is on the same LAN as the server ''or'' a "main client".
:: A "main client" is a client that connects to the server using the "Connect to network server" option in
:: the networking set up panel. A "main client" acts as a UDP gateway which means that if
:: several computers on a LAN are part of the same multi station set up but the server is located
:: elsewhere, only one computer in that LAN needs to connect as a client and the rest can use UDP.
:* Software interlock is UDP-based and can only reliably be used locally. Never over the internet.
:: If used, make sure the interlock is explicitly limited to local stations. See above for more details.

::[[image:clientconfig.png|600px]]
::'''Example configuration of client for networking over internet'''

* In a multi-station setting it is recommended to enable
: <code>Options|Networking|Block standard messages if no operator is logged on</code>
* Make sure <code>Options|Enable network</code> is checked.
* It is also a very good idea to check <code>Options|Load contest at startup</code> to reduce the
: risk of the wrong contest log file being loaded by any stations.

==Real time upload to Club Log Live Stream==

'''Important:''' Club Log truncates QSO time to minutes which means that if you mix real time upload 
with manual upload, make sure to check "QSO time in minutes" when creating ADIF export files.

The author of Club Log, Michael Wall, G7VJR, has developed a very powerful agent for real time uploads. 
It works with all the three major loggers, DXLog, N1MM Logger+, and Win-Test.

It can either be used as is, with a command line user interface, or with an optional user interface front end.

Information on how to download and configure it can be found [[https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads HERE]]

The Club Log Gateway can either listen to DXLog's native multi-station networking protocol or to N1MM style XML broadcast.

To use DXLog's networking protocol, make sure the same port (default 9888) is used in the gateway and DXLog 
and that UDP networking is enabled in DXLog. Do not enable QSO broadcast.

Although this works, it is recommended to use N1MM style broadcast since it contains information like logged on operator, etc.

To use this make sure the port (default 12060) is the same in N1MM port setting in the gateway and in the 
QSO broadcast port settings in DXLog's network configuration. Also make sure to se the DXLog port number 
in the gateway is not the same as that used in DXLog to avoid QSO duplication.

Also set:

<code>Options|Broadcast|QSOs</code> 
<code>Options|Broadcast|QSOs</code> 
<code>Options|Broadcast|Use N1MM QSO format</code> 
<code>Options|Broadcast|QSO time in minutes only</code>

'''Important:''' If you are going to also upload exported ADIF files to Club Log, it is important to also 
check "QSO time in minutes" in the ADIF export configuration to avoid creating virtual dupes, since Club 
Log does not know seconds.

==Diversity reception==

Diversity means receiving the same signal through two different receive chains, including antenna. 
With two antennas having different characteristics this can give substantial benefits in receiving 
fading and/or weak signals or separating calls in a large pile-up. Particularly on low bands.

DXLog supports diversity operation on a selected number of radio models.

For the supported radios, diversity operation can be toggled on and off using <code>[Ctrl][-]</code> or <code>[Ctrl][Keypad -]</code>.

If enabled via the radio's controls, DXLog will automatically detect diversity operation and enable 
the necessary mechanics. Diversity operation is indicated by a small DIV icon in the frequency 
counter box for the radio's band map.

'''Yaesu FTDX101D

Yaesu calls this feature "Sync" and it has a dedicated button up and left of the main VFO knob. 
Enabling this will make DXLog update both VFO with the same information when grabbing spots. 
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO. 
Since both VFO are kept on the same frequency, split operation is not supported.

'''ICOM IC-7851 and IC-7610

ICOM calls this feature "Tracking" and it can be enabled either via a menu entry or a long press on the "MAIN/SUB" button. 
Enabling this will make DXLog update both VFO with the same information when grabbing spots. 
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO. 
Since both VFO are kept on the same frequency, split operation is not supported.

'''Elecraft K3/K3S/K4

Elecraft calls this feature by its proper name. It is enabled by a long press on the "Sub" button. 
It should be noted that Elecraft's implementation where the main VFO controls both the main and 
sub receivers allows for split operation, i.e. transmitting on a different frequency using VFO B.

==UDP broadcast==

For interaction with other applications, DXLog can broadcast useful information as 
XML datagrams over UDP. 

There are five types of broadcast messages produced by DXLog:

* QSO information. Sent when logging.
* Radio information. Sent at changes as well as periodically.
* Antenna direction information. Sent when rotor control is invoked.
* Callsign look-up information
* Spots

QSO can be broadcasted in traditional DXLog format or in a more N1MM-like format.

Radio information can report SO2V as a single physical radio or as two physical radios, like N1MM.

There is an option to truncate the broadcasted QSO time to full minutes for better 
interoperability with some online services and software such as MSHV.

In addition, DXLog can also recognize QSY commands from Waterfall Bandmap and log QSO done as well as create 
local spots from decodes broadcasted by WSJT-X and its forks.

The broadcasting of QSO and radio related data is enabled using the <code>Options|Broadcast</code> submenu.

The broadcasting of spots is enabled by checking <code>Options|DX Cluster|Send spots to SmartSDR</code>.

[[image:radiobroadcastenable3.png]]

[[image:sendspotstosmartsdr.png]]

UDP broadcast parameters are configured in the <code>Options|Network configuration</code> panel. 
Please note that up to three ports can be specified for each broadcast, thereby supporting 
multiple receivers of the information.

[[image:Networksettingsbroadcast3.png]]

If you are writing a C# application to make use of these datagrams, there is a very nice online tool 
for creating an object from a sample XML datagram here https://xmltocsharp.azurewebsites.net/ 

In C# parsing is easily done using Linq. One example of XML parsing and deserialization using Linq 
can be found here https://github.com/bjornekelund/ICOMautomagic

===QSO information===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program
|-
| qsoid
| A unique string for this QSO. If this QSO is edited another contactinfo message will be sent with the same qsoid. Note that the qsoid is only unique within one instance of DXLog. If the computer is networked to others running DXLog the different computers may have a different qsoid for the same QSO.
|-
| contestname
| The name of the contest as it would be written to a Cabrillo file.
|-
| timestamp
| The UTC date and time of the QSO.
|-
| mycall
| The callsign of this station.
|-
| band
| The band on which the QSO was made. In MHz with period as decimal separator.
|-
| txfreq
| The frequency on which the QSO was made.
|-
| operator
| The callsign of the operator if the OPON command was used to set it, otherwise blank.
|-
| mode
| The mode used for the QSO.
|-
| call
| The callsign of the station worked.
|-
| countryprefix
| The DXCC country of the station worked.
|-
| wpxprefix
| The WPX prefix of the station worked.
|-
| snt
| The RST sent. This is always included whether or not the contest exchange contains an RST.
|-
| rcv
| The RST received. This is always included whether or not the contest exchange contains an RST.
|-
| nr
| The number sent if the exchange uses a serial number, otherwise the QSO number from this station.
|-
| exch1
| The first element in the contest exchange if any.
|-
| exch2
| The second element in the contest exchange if any.
|-
| exch3
| The third element in the contest exchange if any.
|-
| exch4
| The fourth element in the contest exchange if any.
|-
| xqso
| True if this QSO should not be counted towards the score.
|-
| invalid
| True if this QSO is invalid, for example a DX QSO in a domestic contest.
|-
| duplicate
| True if this QSO is a dupe (the station has previously been worked).
|-
| rule10broken
| True if this QSO breaks the 10 minute or similar rule. Note that a QSO may not break the 10 minute rule when it is logged but may later if another QSO is edited. This may not cause a broadcast.
|-
| azimuth
| The approximate direction of the station worked, in degrees.
|-
| distance
| The approximate distance of the station worked, in kilometers.
|-
| stationid
| The station ID of the station which made the QSO.
|-
| stationqso
| A unique QSO ID generated by the logging station. The combination of stationid and stationqso forms a unique identifier for the QSO.
|-
| stationtype
| The type of station - R for run, R1 for run 1 etc.
|-
| local
| True if this broadcast is due to this QSO being logged or edited on this computer.
|-
| runqso
| True if QSO logged in Run, false if S&P, and empty if unknown. '''Important:''' Only valid when local is True.
|-
| mult1
| The name of the multiplier if this station is a new multipllier, empty otherwise.
|-
| mult2
| The name of the multiplier if this station is a new multiplier, emtpy otherwise.
|-
| mult3
| The name of the multiplier if this station is a new multiplier, empty otherwise.
|-
| points
| The logged points for the QSO.
|-
| period
| The number of the operating period.
|-
| guid
| The GUID in hex format.
|-
| newqso
| True if a new QSO, False if this message is an update to an existing QSO.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<contactinfo>
<logger>DXLog v2.4.13</logger>
<qsoid>19</qsoid>
<contestname>ARRL-SS-CW</contestname>
<timestamp>2020-01-13 18:28:07</timestamp>
<mycall>SM7IUN</mycall>
<band>3.5</band>
<txfreq>352376</txfreq>
<operator></operator>
<mode>CW</mode>
<call>K4BAI</call>
<countryprefix>K</countryprefix>
<wpxprefix>K4</wpxprefix>
<snt>599</snt>
<rcv>599</rcv>
<nr>19</nr>
<exch1>076</exch1>
<exch2>B</exch2>
<exch3>54</exch3>
<exch4>GA</exch4>
<xqso>False</xqso>
<invalid>False</invalid>
<duplicate>False</duplicate>
<rule10broken>False</rule10broken>
<azimuth>225</azimuth>
<distance>1388</distance>
<stationid>STN1</stationid>
<stationqso>19</stationqso>
<stationtype>R1</stationtype>
<local>True</local>
<runqso>True</local>
<mult1>GA</mult1>
<mult2></mult2>
<mult3></mult3>
<points>3</points>
<period>1</period>
<guid>11223344556677889900aabbccddeeff</newqso>
<newqso>True</newqso>
</contactinfo>
</pre>

Alternative N1MM format

Note that the band name uses the computer's local number format so it may use either comma 
or period as decimal separator. The ID is a number rather than an alphanumeric string.

Also note that IsRunQSO is only valid when IsOriginal is True.

<pre><?xml version="1.0" encoding="utf-8"?>
<contactinfo>
<app>N1MM</app>
<contestname>CWOps</contestname>
<timestamp>2020-01-17 16:43:38</timestamp>
<mycall>SM7IUN</mycall>
<band>3.5</band>
<rxfreq>352519</rxfreq>
<txfreq>352519</txfreq>
<operator></operator>
<mode>CW</mode>
<call>K1XM</call>
<countryprefix>K</countryprefix>
<wpxprefix>K1</wpxprefix>
<stationprefix>K1XM</stationprefix>
<continent>NA</continent>
<snt>599</snt>
<sntnr>5</sntnr>
<rcv>599</rcv>
<misctext></misctext>
<ismultiplier1>1</ismultiplier1>
<ismultiplier2>0</ismultiplier2>
<ismultiplier3>0</ismultiplier3>
<points>l</points>
<radionr>l</radionr>
<run1run2>1<run1run2>
<IsOriginal>False</IsOriginal>
<NetBiosName>DESKTOP-23AB</NetBiosName>
<IsRunQSO>0</IsRunQSO>
<StationName>STATION_B</StationName>
<ID>23</ID>
<IsClaimedQso>true</IsClaimedQso>
</contactinfo>
</pre>

===Radio information===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| The name of the logging program.
|-
| logger
| The name and version of the logging program.
|-
| Station
| The ID of the station.
|-
| RadioNr
| The radio being described.
|-
| Freq
| The receiving frequency.
|-
| TXFreq
| The transmitting frequency
|-
| InactiveFreq
| The frequency of the VFO not receiving.
|-
| Mode
| The reported radio's mode.
|-
| OpCall
| The callsign of the operator if the OPON command was used to set it, otherwise blank.
|-
| mycall
| The callsign of the station.
|-
| IsRunning
| "True" if the station is running, "False" if search and pounce.
|-
| FocusEntry
| The Windows handle for the focused entry window.
|-
| Antenna
| Antenna number.
|-
| Rotors
| Rotators used by selected antenna (not currently used by DXLog).
|-
| FocusRadioNr
| The radio which has keyboard focus. In SO2V with "Report SO2V as two radios" checked, radio 2 is the sub/B VFO.
|-
| IsStereo
| True if headphones are listening to two radios.
|-
| IsSplit
| True if radio is set to split.
|-
| ActiveRadioNr
| The radio which is transmitting, if any.
|-
| Technique
| SO1R, SO2R, SO2R_ADV, or SO2V
|-
| StationType
| Station role: R, M, R1, R2, or R+.
|-
| isTransmitting
| True if a DXLog is transmitting. False if DXLog is not aware of transmission.
|-
| IFFrequency
| Optional element only used with Elecraft K3/K4. Contains the current IF frequency in Hz.
|-
|}

Important note: In SO2V the format differs from some other loggers and is:

: Only physical radio 1 is reported.
: <tt>Freq</tt> and <tt>TXFreq</tt> are the frequency of the currently focused VFO.
: <tt>InactiveFreq</tt> is the frequency of the currently unfocused VFO.
: <tt>ActiveRadio</tt> is always 1.
: <tt>FocusedRadioNr</tt> is 1 when the main/A VFO is focused, 2 otherwise.
: <tt>IsSplit</tt> is always false.

With the option "Report SO2V as two radios" checked, the reporting is similar to some other loggers and is:

: The two VFO are reported as two physical radios.
: <tt>Freq</tt> and <tt>TXFreq</tt> for radio 1 are the frequency of the main/A VFO.
: <tt>Freq</tt> and <tt>TXFreq</tt> for radio 2 are the frequency of the sub/B VFO.
: <tt>InactiveFreq</tt> is the frequency of the other VFO.
: <tt>ActiveRadio</tt> and <tt>FocusedRadioNr</tt> are 1 when the main/A VFO is focused, 2 otherwise.
: <tt>IsSplit</tt> is always false.

Example message:

<pre><?xml version = "1.0"?>
<RadioInfo>
<app>DXLog</app>
<logger>DXLog v2.4.13</logger>
<Station>STN1</Station>
<RadioNr>1</RadioNr>
<Freq>704000</Freq>
<TXFreq>704000</TXFreq>
<InactiveFreq>702500</InactiveFreq>
<Mode>CW</Mode>
<OpCall>K1XM</OpCall>
<mycall>HQ9X</mycall>
<IsRunning>False</IsRunning>
<FocusEntry>591124</FocusEntry>
<Antenna>1</Antenna>
<Rotors>ABC</Rotors>
<FocusRadioNr>1</FocusRadioNr>
<IsStereo>False</IsStereo>
<IsSplit>False</IsSplit>
<ActiveRadioNr>1</ActiveRadioNr>
<Technique>SO2R</Technique>
<StationType>R1</StationType>
<IsTransmitting>False</IsTransmitting>
<IFFrequency>8215000</IFFrequency>
</RadioInfo>
</pre>

===Antenna direction===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program.
|-
| station
| The ID of the station.
|-
| radio
| The radio associated with the rotator.
|-
| go
| True if the rotator should be turned.
|-
| stop
| True if the rotator should be stopped if it is turning.
|-
| azimuth
| The direction to turn the rotator if go is True.
|-
| frequency
| The transmit frequency of the specified radio.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<Rotator>
<logger>DXLog v2.4.13</logger>
<station>STN1</station>
<radio>2</radio>
<go>True</go>
<azimuth>252</azimuth>
<frequency>2800200</frequency>
</Rotator>

</pre>
<pre><?xml version="1.0" encoding="utf-8"?>
<Rotator>
<logger>DXLog v2.4.13</logger>
<station>STN1</station>
<radio>2</radio>
<stop>True</stop>
<frequency>2800200</frequency>
</Rotator>
</pre>

===Callsign lookup===

Sent either when callsign in entry row is changed or when space or tab is pressed.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program.
|-
| contestname
| The name of the contest.
|-
| mycall
| Station's call
|-
| band
| Current band
|-
| txfreq
| Transmitter frequency
|-
| operator
| The call sign of the logged in operator
|-
| mode
| Operating mode
|-
| call
| Call entered in the logging field
|-
| countryprefix
| DXCC entity prefix
|-
| wpxprefix
| WPX prefix
|-
| azimuth
| Short path antenna direction
|-
| distance
| Distance in km
|-
| stationid
| The ID of the station sending the datagram
|-
| stationtype
| The role of the station sending the datagram; R, R1, R2, M, or R+
|-
| period
| Contest period
|-
| reason
| Reason for transmission; SpaceOrTab or CallChanged
|-
|}

Example message:

<pre><?xml version = "1.0"?>
<lookupinfo>
<logger>DXLog v2.4.20</logger>
<contestname>DARC-WAEDC-CW</contestname>
<mycall>K1XM</mycall>
<band>20</band>
<txfreq>1400200</txfreq>
<operator></operator>
<mode>CW</mode>
<call>E7DX</call>
<countryprefix>E7</countryprefix>
<wpxprefix>E7</wpxprefix>
<azimuth>54</azimuth>
<distance>6824</distance>
<stationid></stationid>
<stationtype>R</stationtype>
<period>1</period>
<reason>SpaceOrTab</reason>
</lookupinfo>
</pre>

===Spot===

Sent for every incoming spot from the DX cluster that is valid for the current contest.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| Application sending the message.
|-
| StationName
| The station issuing the broadcast.
|-
| dxcall
| The callsign of the spotted station.
|-
| frequency
| Frequency in kHz with decimal sign of the PC's current locale. (sic)
|-
| spottercall
| The callsign of the spotter. Station name if locally spotted or result of a logging operation.
|-
| timestamp
| Spot time in format yyyy-MM-dd HH:mm:ss
|-
| action
| add or delete.
|-
| mode
| actual or guessed mode of the spot in capitals.
|-
| comment
| The comment section of the spot.
|-
| status
| Spot status. Valid values are "dupe", "double mult", "single mult", and "new qso".
|-
| statuslist
| Same as status
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<spot>
<app>DXLog.net</app>
<StationName>CONTEST-PC</StationName>
<dxcall>E7DX</dxcall>
<frequency>14022.3</frequency>
<spottercall>SM7IUN-#</spottercall>
<timestamp>2O23-07-15 14:29:37</timestamp>
<action>add</action>
<mode>CW</mode>
<comment>CW 31 DB 42 WPM CQ</comment>
<status>single mult</status>
<statuslist>single mult</statuslist>
</spot></pre>

===Broadcast listener===

DXLog also listens for commands over UDP.

Currently only one command is implemented, <code><radio_setfrequency></code>, which is a QSY command.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| Application sending the command
|-
| radionr
| The radio to be changed. In SO2V radio 2 means VFO B. Optional as of DXLog 2.5.20.
|-
| frequency
| Requested frequency. Both period and comma is accepted as decimal separator.
|-
| mousebutton
| Which mouse button was used to create message, if any. Optional.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<radio_setfrequency>
<app>WaterfallBandmap</app>
<radionr>1</radionr>
<frequency>21022.194</frequency>
<mousebutton>Left</mousebutton>
</radio_setfrequency>
</pre>

==SDR integration==

===HDSDR, OmniRig, and microHAM===

''Contributed by Ingo SM5AJV/SE5E''

Until DXLog offers SDR integration there are still ways to get a waterfall/spectrum display with DXLog.

I have integrated the free SDR software [http://www.hdsdr.de/ HDSDR] with DXLog using
[http://www.microham.com Microham Device Router], 
[http://dxatlas.com/OmniRig/ OmniRig]
and [https://www.autohotkey.com/ AutoHotkey].

As illustrated below I place the HDSDR window at the very top of the desktop with DXLog right below.

I share my transceiver's (an Elecraft K3) antenna with the SDR. The receiver antenna signal from my 
K3's RX-ANT OUT is connected to the input of a 3dB power splitter. The two outputs from the splitter 
are connected RX-ANT IN on the K3 and the SDR Receiver antenna input, respectively. On a K3 you 
need to enable the RX-antenna input to make this to work. An additional benefit with this method 
is that the SDR is protected during transmission. It is a widely used method and is e.g. described 
by Bob N6TV in this
[http://dxlog.net/sw/files/utilities/Adding%20an%20SDR%20to%20an%20SO2R%20Station.pdf presentation].

'''Screenshot of my desktop:

[[Image:Sdrdesktop.png|800px]]

Since both DXLog and HDSDR need to communicate with the radio, you need to "split" 
the CAT communication. microHAM's USB Device Router provides a second, independent, 
CAT port that can be used via HDSDR's omniRig interface.

'''"PORT" Tab on microHamRouter:

[[Image:Sdrmicrohamrouter.png|800px]]

'''OmniRig settings in HDSDR:

[[Image:Sdromnirig.png|200px]]

With this set up, the radio, DxLog, and HDSDR will be fully synchronized. For instance, you can 
click in the waterfall to make the radio QSY, and it is easy to quickly find a clean frequency.

To make the integration even better I use a small AutoHotkey script. The script pulls entry focus 
back to DxLog after clicking on the HDSDR waterfall and in DXLog it allows you to use hotkeys to 
control HDSDR. <code>[Ctrl][Alt]+</code> and <code>[Ctrl][Alt]-</code> zooms the waterfall/spectrum 
in and out, and <code>[Ctrl][Alt]C</code> centers it.

'''AutoHotkey script:

SetTitleMatchMode, 2
#InstallKeybdHook
#IfWinActive, HDSDR
{
F4:: return ; disable F4
~LButton Up::
sleep, 1
Winactivate, DXLog
return
}
#IfWinActive, DXLog
{
^!+:: ControlSend ,, ^{+}, HDSDR
^!-:: ControlSend ,, ^{-}, HDSDR
^!c:: ControlSend ,, {c}, HDSDR
}

The script can be downloaded [http://DXLog/sw/files/utilities/dxlog_hdsr.ahk here].

If you start two instances of HDSDR with two different SDR you can even have two waterfalls 
running at the same time.

I have not yet found a way to display cluster spots in the HDSDR spectrum panel. 
But I still find it very useful to check band activity and it allows me to easily find 
a new Run frequency on a crowded band.

===Waterfall Bandmap===

The free waterfall/spot display utility "Waterfall Bandmap" by Steve N2IC is supported by DXLog.

Waterfall Bandmap supports almost any SDR that produce I/Q output either via ExtIO.DLL or a 
sound card; SDRPlay, FunCubeProPlus, HackRF, SDR-IQ, RTLSDR, SoftRock, etc.

A zip file with an executable binary and a Microsoft word document with installation and 
configuration instructions can be found here: https://groups.io/g/waterfallbandmap/files

If you are not a member of the support forum group, you need to apply for membership to download. 
Membership is free.

[[Image:Waterfallbandmap.png]]

The SDR can be connected either to a separate receive antenna, an external receiver output on 
your transceiver or to an IF output, should your transceiver have one. If connected to an antenna, 
keep in mind that you may need protection from the transmitter such as a T/R relay or a passive level limiter.

Please refer to Waterfall Bandmap's documentation for setting it up with your SDR.

Waterfall Bandmap needs two information feeds over UDP: Radio information and spot information. 
Both are provided as UDP broadcast by DXLog.

The default port for both is 13063 and this needs to be set in DXLog's Network configuration panel. 
If Waterfall Bandmap runs on the same computer as DXLog, the broadcast address can be left at the default 127.0.0.1.

[[Image:Setbroadcastportsforwfbandmap.png]]

Clicking on the waterfall display can set the frequency of DXLog. (Left click sets VFO A, right click sets VFO B.) 
To enable this functionality, check the option <code>Options|Broadcast|Receive Broadcasts</code> 
Also make sure "UDP broadcast listener" includes port 13064 in the network settings panel.

The radio information feed needs to be enabled by checking the <code>Options|Broadcast|Radio information</code> option

[[Image:radiobroadcastenable2.png]]

and the spot feed needs to be enabled by checking the <code>Options|DX Cluster|Send spots to SmartSDR</code> option.

[[Image:Enablesendspotstosmartsdr.png]]

==Time synchronization==

In a multi-station setting, the time needs to be accurately synchronized across all networked PC.

Windows' built in time synchronization is very crude and for a PC with poor clock stability the 
inaccuracy of the clock may be up to a minute. Which of course is not acceptable for contesting.

DXLog has built in support for time synchronization as described in the [[Menu Options#Configure network|Configure network section]].

Due to Windows' security system, this however requires all except the PC running as time server to 
run DXLog with elevated permissions. There is unfortunately no way around this inconvenience.

An equally accurate and less intrusive method is to use a standalone time synchronization application on each networked PC. 
This will keep each PC's clock accurate within a fraction of a second.

Contrary to a solution built into a logger it also has the great benefit of being an "install and forget" solution.

A popular application is Dimension 4 by Thinking Man Software. It is free for personal use and 
can be downloaded here: https://dxlog.net/sw/files/utilities/d4time531.msi

It runs in the background and only shows up as a tiny icon in your system tray. 
You hover the mouse above the icon to check status and right-click to open and change settings.

:::[[image:dimension4tray.png|50px]]

After installation a brief configuration is required.

First of all, allow the application to disable Windows' time service and to modify your system clock.

For maximum accuracy, select a time server geographically close to your location. 
When in doubt, you can always add the global server "pool.ntp.org" to the list and use that. 

There are also national and continental pools of time servers. You can find them here https://www.ntppool.org.

[[image:dimension4b.png]]

Make sure the check boxes "Load Dimension 4 at startup", "Start minimized", "Hide when minimized", 
and "Display icon in tray" are all checked.

[[image:dimension4advanced.png]]

Click the Advanced button and also make sure the option "Use the selected server" is selected.

Make sure the application reports a successful connection to the selected time server. 
From here on, you can basically forget the application. 
It will silently start with your PC and always keep its time accurate.

==Disabling USB power management==

In the interest of saving energy, Windows habitually power down USB interfaces 
when it believes there is inactivity. Some USB-to-serial and USB audio devices 
respond poorly to being suspended or powered down so as a rule this "feature" should 
be disabled when used in a ham radio environment.

There are two places where this functionality needs to be disabled; the device driver 
and Windows' energy management.

To disable it for each USB interface and device, open Windows settings. (Click the Windows 
icon in the lower left corner and then chose the cogwheel.) Type ''device manager'' and
select the result.

[[image:devicemanager-c.png|none|frame]]

This opens up a new window, Windows' Device Manager.

[[image:devicemanager2b.png|none|frame]]

For '''every''' USB interface component (there may be many), COM-port, and audio device, 
and '''uncheck''' the option ''Allow the computer to turn this device off to save power''.

The devices you are looking for are in the categories: ''Ports (COM & LPT)'', 
''Sound, video and game controllers'', ''Universal serial bus controllers'',

Note that some devices may not have a ''Power Management'' tab.

[[image:usbdevicemanager.png|none|frame]]

The next step is to disable Windows ''Selective suspend'' feature for USB interfaces.

Go back to Windows Settings and type ''edit power'', click the appearing ''Edit power plan'' menu entry.

[[image:editpowerplan2.png|none|frame]]

This should open the window below, the plan editing panel.

[[image:editplansettings.png|none|frame]]

Click ''Change advanced power settings''. Scroll down to ''USB settings'' and make 
sure ''USB selective suspend setting'' is '''disabled''' for all situations.

[[image:Advancedsettings.png|none|frame]]

To prevent audio devices from becoming unreachable or going into sleep mode you should also 
disable exclusive access. While changing this, also make sure all audio enhancements are disabled.

You reach the detailed audio device settings by entering Windows settings, search for Control panel, 
and in the Control panel view, select Hardware and audio, and then Sound.

[[image:Audiodevice.png]]

Reboot your computer to make sure all settings are recognized by Windows.

==Interlock and inband operation==

In contest station terminology, the term ''Interlock'' refers to a technical solution preventing 
more than one station from using a shared resource, typically an antenna, at the same time.

The most common use for interlock is for inband operation. Inband operation means to have multiple 
transmitters on a single band, interleaving their transmissions. Sometimes on a split-second basis.

As long as you never have more than one transmitter active at any time, the majority of contests allow 
an unlimited number of transmitters and receivers on a single band for multi-operator categories. 
This fact is used by most big contest stations.

For an inband solution to be effective, each station must be able to receive while the 
other station transmits. This means it requires a separate, high performance receive antenna 
with very good isolation from the transmitter antenna. The most common way to 
achieve this is physical separation and geographic orientation to minimize the situations 
when they will radiate/listen in the direction of the other antenna.

For a station operating in the M/M, M/S, or M/2 category, inband operation can boost the points 
per hour performance significantly. It is also a lot more fun.

However, as with everything else, it comes at a cost. An efficient inband solution has:

* A high performance receive antenna for each operated band(s) with very good isolation from the transmitter antenna.
* A fail-safe antenna switching hardware.
* Interlock-capable keyers and/or station controllers.
* An interlock-capable contest logging software

A typical inband configuration can be seen in the illustration below.

[[image:inbandconcept-trx.jpg|800px]]

DXLog offers a software-based interlock which can be configured in a variety of ways, e.g. based on frequency 
band, operating mode, or station role. It supports an unlimited number of stations interlocking each other 
using a great variety of strategies.

The interlock relies on UDP networking and is overlaid on the communication for multi-station logging. 
UDP networking has the benefit of speed and low latency but is, unlike TCP, susceptible to packet loss. 
This means that a '''wired LAN''' is a necessity for any station using interlock. 
For the same reason, it is also not recommended to run interlock over e.g. VLAN/VPN link for 
geographically distributed stations.

A software interlock is not 100% reliable. Computer or software malfunction, networking issues such as packet 
loss, etc. can cause interlock to fail, even if only momentarily.

For this reason it is necessary to also accompany a software interlock with a fail-safe '''hardware''' interlock. 
Without hardware supported interlock you run the risk of not only violating contest rules but also cause serious equipment damage. 
Some contests, such as CQ WW, explicitly requires hardware interlock when using multiple stations on the same band.

There are many designs and even commercial products available for hardware interlock. 
One example of a simple but effective two station hardware interlock which also supports 
power amplifier sharing can be found [https://sm7iun.se/contest/inband/ HERE].

The purpose of this section is to describe steps of setting up a basic two station in-band solution with 
DXLog and microHAM keyers. The microHAM keyers are not mandatory but offers a much better user experience 
and removes the need for additional hardware.

'''Pro tip:''' Consider checking <code>Options|Networking|Allow other stations to abort sending</code> 
which will allow your partner station to interrupt your transmission with <code>[Shift][Esc]</code> in 
critical situations. Be careful though, the use of this function requires good judgment to avoid violence.

===Networking===

Open the networking configuration panel with <code>Options|Configure network</code> and make sure each 
station has a unique name and that only UDP networking is enabled.

Make sure the two stations use the same broadcast IP address and that it is in line with your LAN's 
configuration. Pressing the <tt>Default</tt> button is a good way to ensure this.

Make sure the menu option <code>Options|Enable network</code> has a checkmark.

[[image:inbandnetworkrun.png|left|frame]][[image:inbandnetworkinband.png|none|frame]] 

===DXLog Interlock configuration===

First of all, make sure that the <code>Options|Interface specific options|Prevent TX if another radio is on same band</code> 
is '''not''' enabled. This option completely prevents transmission if more than one networked station is set to the same band 
and the whole idea with inband is to have exactly that.

Next, activate software interlock on both stations using the menu option <code>Options|Networking|Software interlock</code> 
or by typing the commmand <tt>ILOCKON</tt>.

[[image:inbandinterlock2.png|none|frame]]

There are multiple options for configuring the interlock. In a simple set up with only two stations, the topmost 
option ''Same band from status list'' is a good choice. This option will prevent more than one station transmitting 
on the same band, regardless of mode.

In an environment with many stations (such as a multi-operator-multi-transmitter station) it is 
recommended to use the bottom option to only interlock with one or several named stations. 
This will reduce both LAN traffic and inband operation latency. This is particularly important when 
running parts of the DXLog network over high latency links such as VLAN/VPN or if some stations (albeit not 
part of the interlock cluster) are connected via Wi-Fi.

For more advanced scenarios you can also use interlock based on mode or station type (e.g. Run 1, Run 2, Mult, etc.).

The "status list" listing the networked DXLog stations is displayed in the ''Status Window'' which is opened 
with <code>Windows|Status window</code> or <code>[Alt][J]</code>.

[[image:inbandstatuslist2.png]]

DXLog also offers great flexibility when it comes to interlock strategy. The most straightforward and 
most commonly used is ''First one wins''. This is also typically the behavior of "unintelligent" 
hardware solutions when not assisted by software. With this strategy, the station starting to transmit 
first can not be interrupted and always gets to finish its transmission.

[[image:inbandinterlockoptions.png]]

With a ''Last one wins'' strategy, the transmitting station can be interrupted. A carte blanche permission 
to interrupt all transmissions by the other station may however be counterproductive in a real contest situation.

For this reason, DXLog offers additional control of which transmit actions can be interrupted and which can not. 
This is a powerful tool but requires both operators to be aware of it and may require 
practice before fully effective.

[[image:inbandstrategyexceptions.png]]

''F1'' through ''F7'', ''PLUS'' and ''INS'' refers to DXLog's standard messages. ''KEYB'' means a free text transmission 
from the keyboard using the <code>[Alt][K]</code> function and ''MAN'' means manual transmission using either paddle 
break-in or a footswitch.

For CW, DXLog recognizes paddle break in from a K1EL Winkey-compatible keyer as described in the [[Menu_Options#Winkey_Configuration|Winkey configuration section]].

Since DXLog recognizes a footswitch connected to a microHAM device, this is a recommended approach for phone. 
It is also possible to connect a footswitch to the DSR pin (pin 6) on a physical COM-port on the PC, but today 
few PC have such a port and it also requires additional circuitry.
Details on how to do this is available [[Additional_Information#Connecting_a_footswitch|HERE]].

===microHAM configuration===

Open the microHAM device configuration panel with <code>Options|microHAM device configuration</code>.

[[image:Mk2r-new9.png|none|frame]]

Check the option ''Enable TX lock/unlock''. This will do two things; it will enable DXLog to prevent 
transmission and and it will make DXLog aware of the microHAM device's PTT status. The latter is particularly 
important since it means DXLog will recognize PTT assertion not only by a footswitch connected to the 
microHAM device but also by the built-in Winkeyer (requires microHAM USB Device Router version 9.3.0 or later) 
'''Paddle-based break-in in an inband solution is currently unique for microHAM with DXLog.'''

'''Important:''' Making DXLog "PTT aware" means that care has to be taken in how PTT is set up. If you, for instance, 
enable DXLog PTT for the voice keyer, this will create a self-reinforcing feedback loop and PTT will thus never drop.

Check the option ''Dual radio device'' if you are using a u2R, MK2R, or MK2R+, otherwise, leave this unchecked.

Check the option ''Device without CAT interface'' if the device lacks a CAT interface (like the u2R) 
or if its CAT interface is not connected to the radio. This option will make sure the e.g. keying and 
audio routing is always set correctly in line with the operating mode (Voice, CW, or RTTY).

===Operating===

Inband operation requires a fair amount of training and it is a good idea to define and agree 
on general rules for operation, such as hand signals for challenging QSO, beforehand.

There are more than enough YouTube videos of inband operators yelling at each other.

The operating tactics may have to be adjusted during the contest. If Run is slow, 
doing S&P on the inband station can increase the points per minute significantly. 
However, if Run is strong, an overly active inband operator doing S&P, but not working 
multipliers, may actually reduce the station's points per minute significantly.

Real-time interlock status is shown in the ''Radio status'' window, which is opened with 
<code>Windows|Radio status</code>.

[[image:inbandblocking.png]] [[image:inbandblocked.png]]

For Phone contesting, you typically rely on footswitches for PTT and the option 
<code>Options|Networking|Show QSO status when blocking</code> makes the blocking 
station send a more helpful blocking cause than ''MAN''.

With this option enabled, the blocking station will instead send ''CQ'', ''QSO'', or ''EXCHANGE'' 
as blocking cause, determined by cursor location and entry field content at the locking station.

Further reading can be found in the [[Menu_Options#microHAM_device_configuration|microHAM device configuration]] and [[Menu_Options#Networking|Networking]] sections.

==Connecting a footswitch==

To free up both hands in Phone contesting, a footswitch PTT is a great help.

Also, to use interlock in Phone contesting, a footswitch is mandatory.

There are two basic ways to interface a footswitch with DXLog; via a microHAM device (which is the recommended solution) 
or directly connected to a physical serial port on the PC (which very few PC have today).

The connection of a footswitch to a microHAM device is very straightforward and by checking the ''Enable TX lock/unlock'' 
in the ''microHAM device configuration'' panel, it is recognized by DXLog.

Lacking a microHAM device, it is also possible to use the computer's DB9 RS-232 serial port connector, providing it has one.

The required steps to do this are:
* Connect a 10k resistor between DB9 pin 6 and pin 7.
* In the port's settings (<code>Options|Configure interfaces</code>) set DTR (pin 4) to ''Always On'' and RTS (pin 7) to ''Always Off'' for the port.
* Connect the footswitch between DB9 pins 4 and pin 6. '''Important:''' Neither pole on the footswitch must be connected to ground.
* In the radio's configuration panel, check ''use CAT PTT command on Phone'' and set ''Footswitch (pin 6)'' to ''PTT''

==Support for CC Cluster==

CC Cluster is today the main choice for contest use.

It offers a high quality, database-verified, flow of skimmer spots and a rapid 3-minute respotting period for skimmer spots.

It also publishes unique spots from less common locations which are valuable for DX chasers or as contest multipliers.

To make use of the display of own spot in the world map, make sure to issue the command '''<tt>SET/OWN</tt>''' to the cluster node. 
This setting is persistent and only needs to be done once.

A list of cluster nodes that runs CC Cluster can be found here: [https://www.dxcluster.info/telnet/index.php?software=CC%20Cluster CC Cluster nodes]

A description of the command line syntax can be found here: [http://bcdxc.org/ve7cc/ccc/CCC_Commands.htm CC Cluster command syntax]

A convenient software for setting up filters etc. can be found here [http://www.bcdxc.org/ve7cc/default.htm#prog CC User]

[[Image:Ccclustersspotflow.png]]

==Support for AR Cluster 6==

With the author tragically SK, AR Cluster is no longer under development but still available as an executable binary.

In its standard configuration, AR Cluster offers no consolidation of skimmer spots meaning a very high flow of spots 
that can become extreme during a major contest weekend.

With the advent of skimmers, the traffic on the DX Cluster has risen dramatically. Even though CW skimmers are generally 
quite reliable, the absolute number of busted spots can be quite high during a busy contest.

Jose CT1BOH has developed an algorithm for evaluating spot quality which is included in version 6 of AR Cluster. 
Today many cluster nodes runs this version and thereby offer this mechanic. 
A complete list can be found here: [http://www.dxcluster.info/telnet/index.php?software=AR-Cluster AR Cluster nodes]

To enable the functionality on a cluster node running AR Cluster 6, the command

<tt>'''SET DX EXTENSION SKIMMERQUALITY'''</tt>

needs to be issued to the cluster node. The easiest way to do this in DXLog is via <code>[Alt][T]</code>. 
This setting will be remembered at subsequent logins.

The quality of the spots is indicated by a character ("tag") in the last column of the comment field and, 
in some cases, a corrected callsign within parenthesis. This syntax is recognized by DXLog and can reduce the 
number of bad spots in your bandmap.

The CT1BOH skimmer quality algorithm is based on three parts:

; Validation : When a callsign is first spotted, it is tagged with "?" in the last column of the spot's comment field. If the callsign of an unverified spot closely resembles an already verified one on the same frequency, the verified callsign is provided within parenthesis in the spot's comment field. When two or more skimmers agree on the spot, it is considered verified and the tag becomes "V".

; Frequency : When a verified spot appears more than 0.35kHz off its verified frequency, the spot is tagged "Q" for QSY. Once verified, this becomes the new verified frequency and it is tagged "V".

; Probability : The algorithm checks uncertain spots for resemblance with already verified spots and spots at or near the same frequency. If the resemblance is high enough, the spot is considered busted "B" and the corrected callsign is provided within parenthesis in the spot's comment field.

Below you can see an example of the spot flow from W9PA-4 with skimmer quality enabled. 
The flow contains one unverified and one busted spot.

[[image:spotquality.png]]

DXLog's policy for spots with CT1BOH skimmer quality tags is the following:

: '''V''' - Accept spot.
: '''Q''' - Accept spot.
: '''?''' - Accept spot. Use corrected call when provided.
: '''B''' - Accept spot if corrected call provided. Else ignore.

DXLog recognizes the skimmer quality tags but consolidates them for consistency 
with other cluster nodes' quality tags and to minimize confusion when mixing spot flows. 
The legend is:

: '''?''' means a spot with ? This is an unreliable spot.
: '''P''' means a spot with Q or B with correction. This is a fairly reliable spot.
: '''V''' means a spot with V. This spot is considered validated.

This basic policy can be modified by using additional filters at the cluster node end. Some examples are:

: <tt>'''SET DX FILTER NOT SKIMBUSTED'''</tt> - Do not send busted spots at all
: <tt>'''SET DX FILTER NOT SKIMQSY'''</tt> - Do not send QSY spots
: <tt>'''SET DX FILTER SKIMVALID'''</tt> - Only send verified spots
: <tt>'''SET DX FILTER NOT SKIMUNKNOWN'''</tt> - Do not send unreliable spots
: <tt>'''SET DX FILTER SKIMMER'''</tt> - Do not send manual spots

You can also compose more complex filters such as:

: <tt>'''SET DX FILTER SKIMVALID OR SKIMBUSTED OR NOT SKIMMER'''</tt>

This can be a good filter for most contests. It will will only provide valid or busted skimmer spots together with manual spots. 
It is safe to receive busted spots since DXLog will ignore them if there is no corrected callsign included. 

For assisted operation in serious contesting you however need to allow also unknown spots since weak stations spotted 
only by one or a few skimmers may never reach validated status. You do this by adding <tt>'''OR SKIMUNKNOWN'''</tt> to the filter.

Both the bandmap and the DX cluster announcement windows have the option to display the spot quality tag. 
These windows will show two additional tags; L and C. L stands for local spot, created by yourself or one of your team members. 
C stands for corrected, i.e., a B or ? spot where a corrected call has been included in the spot's comment field.

The AR6 filtering syntax offers a lot of flexibility. Another example:

: <tt>'''SET DX FILTER (SKIMVALID OR NOT SKIMMER OR ((SKIMQSY OR SKIMUNKNOWN) AND (CTY <> K AND CONT <> EU )))'''</tt>

will provide only validated and human spots except if they are from outside the US and EU.

If you get lost in the filter settings you can always reset with : <tt>'''SET DX DEFAULT'''</tt>.

Some more guidance on how to work with filters on AR-Cluster nodes can be found in [http://dxlog.net/sw/files/utilities/AR_Cluster_v6_User_Manual.pdf this document].

==Support for DXSpider==

DXSpider is the by far most dominant DX cluster software but has historically not been a good choice for contesters. 
The reasons for this include: Long respotting time, lack of pass function for own spots, and suppression of spots from a single skimmer.

The good news is however that the author Dirk G1TLH has worked hard to address these aspects of the otherwise brilliant software.

From '''version 1.57 release 440''' the respotting time is now 3 minutes and there is a <tt>SET/SEEME</tt> command that passes all spots 
without consolidation of your own callsign.

So if your favorite cluster node is not running this version, ask the owner to upgrade asap.

Yet another reason for its popularity is its extreme resource-efficiency which allows it to run virtually 
any Linux capable hardware, including a $20 Raspberry Pi Zero.

A list of all DX cluster nodes running DX Spider can be found here: [https://www.dxcluster.info/telnet/index.php?software=DX%20Spider DX Spider cluster nodes]

[[image:dxspiderflow.png]]

DXLog recognizes the <tt>Q:#</tt> skimmer quality tag in the comment field and converts them into "CT1BOH-like" quality 
tags that can be displayed in DXLog's bandmap. The legend is:

: '''?''' means a spot with Q:1, i.e. heard by only one skimmer. This is an unreliable spot.
: '''P''' means a spot with Q:2, i.e. heard by only two skimmers. This is a fairly reliable spot.
: '''V''' means a spot with Q:3 or higher, i.e. heard by several skimmers. This spot is considered validated.

Since a DXSpider node currently needs to be specially configured by the owner to publish Q:1 spots, very few do this. 
Also, since DXSpider lacks busted call detection, the the quality of the spot flow will suffer if this is done.

There is a wealth of information to be found on the [http://wiki.dxcluster.org/index.php/Main_Page DXSpider wiki].

==Support for N2WQ Cluster==

Introduced in late 2025, Rudy N2WQ has developed the first new DX cluster node software in decades.

The N2WQ-2 cluster has some unique features like a more advanced callsign validation than 
AR 6 and propagation estimation tags embedded in the spot comments. An example can be seen below.

[[image:n2wpspotflow.png]]

When you connect to dxc.n2wq.com port 8300 and you have set your 4-digit Maidenhead grid (SET GRID), there 
will be a single character just before the DX’s grid locator. This character is the path prediction glyph.

It is a crowdsourced, real-time estimate of how reliable the path is between you and the DX on that band right now, 
based on recent on-air propagation reports from RBN and PSKreporter. Its values and meaning are:

: > High: Strong path. If you can hear them, you should be able to work them.
: = Medium: Decent path. Workable with normal contest/DX technique.
: < Low: Weak path. Possible, but expect repeats, timing, and patience.
: - Unlikely: Marginal. Try only if it’s rare/needed, or you have a strong station advantage.

A missing glyph means insufficient data to estimate the path.

the glyph is mode-aware. A path that looks great for a very sensitive mode (FT8) can look 
more moderate for a less sensitive one (SSB).

You can filter spots by path reliability using the PASS/REJECT PATH command.

It is important to be aware that the glyph does not know:

: Your antenna gain/pattern, height, or takeoff angle
: Your transmit power and duty cycle constraints
: Your operating technique (timing, split discipline, pileup strategy)
: Short-lived phenomena the network has not yet “seen” such as sporadic E or aurora.

The cluster ingests upwards of 50,000 CW, FT, RTTY, and WSPR spots per minute. To compare different modes 
fairly, the system normalizes reports onto a common “FT8-equivalent” scale (so a CW SNR can be compared 
to an FT8 SNR).

Your grid and the DX grid are mapped into small geographic cells and the cluster calculates propagation 
at two levels:

: Fine (local): what’s happening close to your area (~180 miles).
:: On averages there are about 90,000 DE/DX pairs being tracked
: Coarse (regional): what’s happening in the broader region around
:: you (~480 miles). On average, there are about 30,000 DE/DX pairs.

If there isn’t enough local data, the system leans more on regional behavior. 
If there’s plenty of local data, it uses that more heavily.

Sometimes you can hear them better than they can hear you (or the reverse) due to noise 
floors, antennas, geography, or ionospheric effects. The system tracks both:

: Receive direction: DX to you (can you hear them?)
: Transmit direction: you to DX (can they hear you?)

It combines these into one “path reliability” estimate, weighting receive a bit more 
because if you can’t hear them, you can’t work them.

Propagation changes fast, so older reports get discounted using a half-life (data fades 
in influence over time). Typical behavior by band:

: Low bands (160/80m): slower changes (longer half-life)
: Mid bands (40–20m): medium pace
: High bands (15–6m): fast changes (shorter half-life)

In practice, this means glyphs can shift in minutes on 10m/6m, and more slowly on 80m/160m. 
Also, new openings take time to show up. A "insufficient" can simply mean “the path just opened 
and the cluster hasn’t collected enough recent reports yet.”

Your local noise floor heavily affects what you can receive, so the cluster lets you tell 
it what your noise environment is. This mainly tunes the receive-side expectation (DX to you).

Set it with SET NOISE SUBURBAN. Available profiles per ITU:

: QUIET: very low noise, rural/remote
: RURAL: mild noise
: SUBURBAN: typical neighborhood QRM
: URBAN: elevated noise, dense housing
: INDUSTRIAL: severe noise

If you don’t set it, the system may assume a quieter environment than you actually 
have, and your receive-side glyphs can look too optimistic.

Treat the glyph as a real-time probability hint that helps you spend your operating 
time where the odds are best. When you see > on a needed multiplier, move fast. 
When you see -, be intentional about whether it’s worth the time. 
And when you see a space, fall back to classic DX/contest instincts and your own ears.

The N2WQ cluster also offers spot quality tags between the DX grid and the time.

A quality (in terms of callsign reliability) tag can be V, P, S, C, or ? where V means validated, 
P highly likely, S less likely, C corrected, and ? unsure.

The propagation and quality tags can be displayed in the bandmaps and the DX cluster announcement window.

DXLog recognizes the skimmer quality tags but consolidates them before display for consistency 
with other cluster nodes' quality tags and to minimize confusion when mixing spot flows. 
The legend is:

: '''?''' means a spot with ? or S. This is an unreliable spot.
: '''P''' means a spot with P or C. This is a fairly reliable spot.
: '''V''' means a spot with V. This spot is considered verified.

==Interacting with WSJT-X==

Important: When in a DXpedition/multi-station setting, always use local host 127.0.0.1 as the 
broadcast address to prevent packets being picked up by other stations in the network. 
Also, enabling the creation of local spots from decodes may overwhelm DXLog.

DXLog can add QSO performed with WSJT-X to its log. Note that this functionality only works 
for contests with grid as the first and only exchange or for DXPedition type logs.

DXLog can also create local spots from WSJT-X decodes by checking 
<code>Options|Broadcast|Spot WSJT-X decodes</code>.

To enable logging of WSJT-X QSO, set up WSJT-X to broadcast information:

[[image:Wsjt-x-udp.png]]

[[image:Radiobroadcastenable3.png]]

Activate DXLog's UDP listener by checking <code>Options|Broadcast|Receive broadcasts</code> and set 
the same port number as in WSTJ-X in DXLog's network configuration panel.

[[image:Dxlog-udp.png]]

==Using Winkey FSK==

Winkey FSK is not natively supported by DXLog's digital mode engines MMVARI or MMTTY but 
Rafal EI6LA has developed a plugin for MMTTY that makes this possible.

You can find it [https://github.com/RafalLukawiecki/WinKeyerMMTY here].

==Interfacing with LogHX==

Christian F8GHE has prepared a guide on how to do this.

You can find it [http://dxlog.net/sw/files/utilities/DXLOG-LogHX_UDP-config_v2.pdf here].

==Self-spotting==

More and more contests allow spotting your own station on the DX cluster.

DXLog supports this, even when operating unassisted, as long as you connect to the cluster.

DXLog has three mechanics for self-spotting.

DXLog blocks self spotting unless specifically allowed in the contest rules. 
Should you find that DXLog incorrectly allows or blocks self-spotting, please make 
the development team aware via the support reflector.

* The <tt>$SPOTME</tt> macro command. This macro will create a cluster spot of the station's
: call at the earliest 15 seconds after being invoked the first time on a new frequency.
: Thereafter it will spot as frequent as allowed by the contest. If the contest rules do not
: specify a minimum period, 10 minutes will be used.

* Checking the menu option <code>Tools|Data entry|Run F1 message self-spots when permitted</code>.
: Works exactly like the <tt>$SPOTME</tt> macro command but is triggered by sending the
: Run F1 message which happens when pressing <code>[Enter]</code> with an empty entry line
: in Run, pressing <code>[F1]</code> in Run, or with Auto-CQ.

* Clicking the menu item <code>Commands|Self-spot</code> or pressing its shortcut key <code>[Ctrl][S]</code>.
: This will immediately create a spot of the station's call but no more often than
: every two seconds to avoid accidental multiple spots.

==DXpedition use==

DXLog is a popular choice for top tier dxpeditions. Below we have collected advice based on experience 
on how to best use DXLog in a dxpedition setting.

* Use client/server networking between stations. Never use UDP over Wi-Fi or WAN links.
* Use the "Minimal data" option in ADIF export to save on satellite link cost.
* For Club Log real time upload, use [[https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads Club Log's upload app]]
* Club Log truncate QSO time to minutes so to avoid creating dupes when mixing manual and real time
: upload to Club Log, check ''QSO time in minutes'' when doing ADIF export.
* Use the "Minimal data" option in ADIF export to save on satellite link cost.
* Follow [[Additional_Information#Interacting_with_WSJT-X|the instructions]] to log QSO made with WSJT-X and MSHV.
* Check <code>Options|Broadcast|Spot WSJT-X decodes</code> to make decoded calls appear in e.g., DX cluster announcements.
* You can extend the number of digits in the QSO count with <code>Options|Log|QSO number digits</code>

==Beacon spots on DX cluster==

Although propagation measurements based on FT8 communications has reduced the 
value of beacons, there are still hundreds of them in operation.

Identifying with CW, they are typically reported on reported on the DX cluster.

When beacon spots are received by DXLog, they are always displayed in the bandmap. 
In DXLog, beacon spots are recognized by having a trailing <tt>/B</tt>.

The DX cluster announcement window never shows or counts beacon spots.

Beacon spots can be enabled and disabled in the cluster node.

For CC Cluster, the commands are <tt>SET/BEACON</tt> and <tt>UNSET/BEACON</tt>.

For DXSpider, command is part of the <tt>SET/SKIMMER</tt> command where <tt>SET/SKIMMER</tt> 
or e.g., <tt>SET/SKIMMER CW BCN FT RTTY</tt> will pass beacon spots and <tt>UNSET/SKIMMER</tt> 
or any <tt>SET/SKIMMER</tt> listing modes but not BCN will block them.

AR 6 cluster nodes always pass beacon spots when skimmer spots are enabled. They cannot be disabled.

Additional Information

2026-04-01T06:57:49Z

Sm7iun: /* Beacon spots on DX cluster */

==Using alternative configurations==

Window positions, coloring and general look and feel is saved in each log file but all other settings such as 
radio control, keying, and networking is saved in a common, contest-independent configuration file.

By default, the configuration file name is <tt>DXLog.net.config</tt> and it is located in the <tt>%appdata%\DXLog.net</tt> configuration folder.

This folder is also reachable via the <code>File|Open configuration folder</code> menu item.

[[image:configfolder.png]]

DXLog can be made to use an alternative configuration file with the command line option <tt>-cfg=<filename></tt>.

A convenient way to use this option is to create a separate Windows desktop shortcut including the command line option 
and give it a meaningful name.

[[image:Desktopshortcut.png]]

The command line option is simply added to the end of the Target text box in the shortcut's properties. 
Double-clicking the icon will start DXLog with the alternative configuration which will also be remembered between sessions. 
In the picture below the target of the shortcut is

[[image:Desktopshortcutconfig.png]]

'''Important:''' If you want to use an alternative configuration, do not just modify the desktop shortcut created at installation 
since this shortcut will be deleted when you upgrade DXLog. Instead make a copy, rename, and add the command line option. 
You should keep the command line option outside the apostrophes, like this

<tt>"C:\Program Files (x86)\DXLog.net\DXLog.net.exe" -cfg=SO2R.config</tt>

==Using a number server==

For contests involving serial numbers you need to secure that the sent number and the (slightly later) 
logged serial numbers are the same. In a straightforward SO1R or SO2V scenario, serial numbers are simply 
chronological but in more complex station configurations such as Multi-single or Multi-2 with inband, and 
advanced SO2R, QSO can be interleaved and requires a central source source of serial numbers together 
with a mechanic to protect an already sent serial number from re-use by another radio.

In DXLog this is achieved with a central number server. A number server can be used either 
by a single instance of DXLog (for SO2R) or by multiple stations on the same LAN.

The use of a number server involves three, natural, steps:

* Activating the server on a single station
* Making sure all stations use it
* Verifying functionality, making sure serial numbers are correctly reserved

The number server is activated in the <code>Options|Configure network</code> panel, described [[Menu_Options#Configure_network|HERE]].

[[image:startnumberserver.png]]

Since the server uses a networking socket, <code>Options|Networking</code> must be enabled '''also''' when 
using a single computer in SO2R. In the case of multiple stations, UDP networking or Client-Server 
networking must also be enabled to transfer the numbers over the LAN. For SO2R, this is however not 
necessary. When using Client-Server networking, a client cannot be number server.

There must only be one number server in a local network and all stations using it must have 
<code>Options|Networking|Use number server</code> checked like in the picture below.

'''Important:''' The number client/server functionality is not very robust. 
If you have stations joining/leaving your network or being rebooted, it is 
best to restart DXLog on all stations to guarantee correct function.

[[image:usenumberserver.png]]

The option <code>Block logging if serial number reservation is unsuccessful</code> can be used as an extra precaution 
but is not necessary in SO2R since the communication with the number server does not leave the computer.

There are three methods for reserving a number from the server:

* Checking <code>Tools|Data entry|Space key reserves serial number</code> and using the space key to reserve serial numbers. This is typically used on phone or when operating "old school" with F-keys.
* Checking <code>Tools|Data entry|Insert and F2 messages reserve serial number</code> and letting DXLog automatically reserve a serial number right before $SERIAL sends it. This is the preferred and most straightforward way for CW and digital.
* Adding the $RESERVENR macro to messages like illustrated below. 

These methods can of course also be combined. 

The $RESERVENR macro is "smart" and will only reserve a serial number if the callsign entry field is not empty and a 
serial number is not already reserved. The same goes for the menu items.

[[image:reservemessages.PNG]]

The sign of a serial number being reserved is that it turns red. It then stays reserved (and red) until the 
QSO is logged or the entry line is cleared with <code>[Alt][W]</code>.

An option that can prove useful is <code>Tools|Data entry|Cancel serial number reservation only if callsign field is empty</code>. 
In the case that you send the exchange and realize you got the other station's callsign call completely wrong, a reflex can be to hit 
<code>[Alt][W]</code> and start typing. If this is your habit, this option will prevent you from releasing the 
already sent serial number, thereby avoiding you the trouble to send a new one to the other station.

[[image:reservednumber.png]]

==Networking over internet==

When, for instance, activating a special event callsign it is possible to network multiple DXLog stations over the internet.

'''Pro tip:''' Consider displaying the callsign, message ID, Message text, etc. fields in the ''Network status'' 
window when operating a distributed station. Also, learn to use the gab <code>[Alt][G]</code> and <code>[Alt][J]</code> function.

===VLAN/VPN Solution===

The most secure way for remote networking is to rely on a VLAN (virtual LAN) software. There are several available such as:

ZeroTier https://www.zerotier.com/ 
FreeLan http://www.freelan.org/ 
Player.me https://player.me/ 
OpenVPN https://openvpn.net/

Each VLAN solutions have their own particular set up which is covered in their respective documentations. 
With a VLAN solution, all DXLog configurations are the same as when operating in a regular LAN however with a few exceptions.

One weakness with connections over the internet (a.k.a. WAN), including VLAN solutions, is that they are prone to packet loss. 
Packet loss is disastrous to DXLog's (or any logger's) "standard" UDP networking.

It is therefore essential to use '''only client/server networking over a VLAN'''. 
'''This also means you should never use interlock over an internet connection unless you use a zero packet loss VPN tunnel.'''

ZeroTier is particularly popular since it is free.

Since DXLog is able to mix TCP (client/server) and UDP (peer-to-peer) networking, a distributed station set up should be configured to rely on TCP 
for the wide-area network and UDP for the local network at each station location. Below you will find the station 
set up for the Swedish HQ station SE9HQ in the 2019 IARU HF Championship. The DXLog.net.DXC cluster client was run 
on SK3W-A which distributed spots to all stations over the network. Inband interlock was also used at the SK3W location.

[[image:SE9HQ-network-eng.png|800px]]

Important to note:

* For the server as well as the main clients, ''Server IP'' should be set to the server's VLAN IP address, '''not''' its LAN address.
* The '''server''' should check both "Act as network server" and "UDP network broadcast for multiple stations".
* The '''main clients''' should check both "Connect to network server" and "UDP network broadcast for multiple stations".
* The '''sub clients''' should check only "UDP networking for multiple stations".
* Interlock (which is UDP-based) over VLAN does not work reliably because of packet loss.
: Therefore, it is important to configure any interlock to '''only''' consider relevant operating positions,
: which all must be local. Use the possibility to only consider named stations for the interlock in the software 
: interlock set up. <code>Options|Networking|Software interlock</code> "Custom station ID(s)"
* For a large set-up with many stations connecting as clients to a central server you may overload the server if you also
: distribute spots via all client-server connections. In this case, check the "No spots via client/server" option
: on all stations and use '''local DX cluster connections''' via UDP at each location.
: '''Important:''' Limitations in Windows networking makes client/server networking unreliable beyond 10 station locations.
* Make sure to check <code>Options->Load contest at startup</code> to avoid opening the wrong log after a restart.
* '''Remote commands are not forwarded''' in the network but are executed in the station where they arrive.
: Thus, to clear all logs, disconnect networking on each main client, execute the remote command CLEARLOGNOW on each main client
: to clear the logs of all sub clients and do not reconnect until the server and all other main clients have done the same.

===Port forwarding Solution===

If you are less worried about competitors or government agencies listening in on your contest data, 
it is possible to route the traffic directly over the internet using port forwarding at the server.

'''Important security notice: This solution is not without risk. It offers no security or authentication. 
Any DXLog station running the same contest configuration, knowing the URL or IP address and IP port of the 
server can connect to the server station. There are no means to disconnect a station by force.'''

Also note the comment about '''remote commands''' in the section above.

With a port forwarding solution, the following must be observed:

* '''Server configuration'''
:* Only one of the stations should be configured as the '''server'''.
:* "Connect to network server" should not be checked on this station and
:: "UDP networking for multiple stations" should only be enabled if it is used to
:: communicate with a cluster client or other stations locally on the same LAN.
:: Either use a central cluster connection (uncheck "No spots via client/server")
:: or use one cluster connection per station location (check "No spots via client/server").
:: If one cluster connection per station location is used, make sure they
:: all use different SSID to prevent disconnects, such as E7HQ-1, E7HQ-2, etc.
:: This will ensure the cluster node regards all connections as having the same callsign
:: which is essential for e.g., correctly receiving own spots.
:* The PC acting as server must be configured for a fixed LAN IP address. This is done
:: either by manually configuring the networking settings in the PC to use a fixed
:: LAN IP address, or by setting up the router in the server's LAN to to always allocate
:: the same IP address to it.
:* The internet connection used by the server PC must ''either'' have a fixed public IP address ''or''
:: use dynamic DNS. Otherwise clients will not be able to reliable connect over the internet.
:* The server's TCP/IP port (e.g., <code>9888</code>) must be forwarded to the server by the server LAN's router.
:: Only TCP traffic should be forwarded. DXLog UDP traffic is not carried well over the internet.

:: [[image:serverconfig.png|600px]]
:: '''Example configuration for server for networking over internet'''

::[[image:portforwarding.png|600px]]
::'''Example of port forwarding UI in router'''

* '''All other stations'''
:* All other PC in the multi-station set up should be set up as clients.
:* Over the internet, "Server:" is either the static, public IP address of the server's internet
:: connection (e.g. <code>5.140.211.42</code>) or the dynamic DNS address (e.g. <code>hq.sm7iun.se</code>).
:: Clients connecting over the internet does not have to enable UDP networking and ''should not''
:: enable a server.
:* A client may connect via UDP if it is on the same LAN as the server ''or'' a "main client".
:: A "main client" is a client that connects to the server using the "Connect to network server" option in
:: the networking set up panel. A "main client" acts as a UDP gateway which means that if
:: several computers on a LAN are part of the same multi station set up but the server is located
:: elsewhere, only one computer in that LAN needs to connect as a client and the rest can use UDP.
:* Software interlock is UDP-based and can only reliably be used locally. Never over the internet.
:: If used, make sure the interlock is explicitly limited to local stations. See above for more details.

::[[image:clientconfig.png|600px]]
::'''Example configuration of client for networking over internet'''

* In a multi-station setting it is recommended to enable
: <code>Options|Networking|Block standard messages if no operator is logged on</code>
* Make sure <code>Options|Enable network</code> is checked.
* It is also a very good idea to check <code>Options|Load contest at startup</code> to reduce the
: risk of the wrong contest log file being loaded by any stations.

==Real time upload to Club Log Live Stream==

'''Important:''' Club Log truncates QSO time to minutes which means that if you mix real time upload 
with manual upload, make sure to check "QSO time in minutes" when creating ADIF export files.

The author of Club Log, Michael Wall, G7VJR, has developed a very powerful agent for real time uploads. 
It works with all the three major loggers, DXLog, N1MM Logger+, and Win-Test.

It can either be used as is, with a command line user interface, or with an optional user interface front end.

Information on how to download and configure it can be found [[https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads HERE]]

The Club Log Gateway can either listen to DXLog's native multi-station networking protocol or to N1MM style XML broadcast.

To use DXLog's networking protocol, make sure the same port (default 9888) is used in the gateway and DXLog 
and that UDP networking is enabled in DXLog. Do not enable QSO broadcast.

Although this works, it is recommended to use N1MM style broadcast since it contains information like logged on operator, etc.

To use this make sure the port (default 12060) is the same in N1MM port setting in the gateway and in the 
QSO broadcast port settings in DXLog's network configuration. Also make sure to se the DXLog port number 
in the gateway is not the same as that used in DXLog to avoid QSO duplication.

Also set:

<code>Options|Broadcast|QSOs</code> 
<code>Options|Broadcast|QSOs</code> 
<code>Options|Broadcast|Use N1MM QSO format</code> 
<code>Options|Broadcast|QSO time in minutes only</code>

'''Important:''' If you are going to also upload exported ADIF files to Club Log, it is important to also 
check "QSO time in minutes" in the ADIF export configuration to avoid creating virtual dupes, since Club 
Log does not know seconds.

==Diversity reception==

Diversity means receiving the same signal through two different receive chains, including antenna. 
With two antennas having different characteristics this can give substantial benefits in receiving 
fading and/or weak signals or separating calls in a large pile-up. Particularly on low bands.

DXLog supports diversity operation on a selected number of radio models.

For the supported radios, diversity operation can be toggled on and off using <code>[Ctrl][-]</code> or <code>[Ctrl][Keypad -]</code>.

If enabled via the radio's controls, DXLog will automatically detect diversity operation and enable 
the necessary mechanics. Diversity operation is indicated by a small DIV icon in the frequency 
counter box for the radio's band map.

'''Yaesu FTDX101D

Yaesu calls this feature "Sync" and it has a dedicated button up and left of the main VFO knob. 
Enabling this will make DXLog update both VFO with the same information when grabbing spots. 
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO. 
Since both VFO are kept on the same frequency, split operation is not supported.

'''ICOM IC-7851 and IC-7610

ICOM calls this feature "Tracking" and it can be enabled either via a menu entry or a long press on the "MAIN/SUB" button. 
Enabling this will make DXLog update both VFO with the same information when grabbing spots. 
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO. 
Since both VFO are kept on the same frequency, split operation is not supported.

'''Elecraft K3/K3S/K4

Elecraft calls this feature by its proper name. It is enabled by a long press on the "Sub" button. 
It should be noted that Elecraft's implementation where the main VFO controls both the main and 
sub receivers allows for split operation, i.e. transmitting on a different frequency using VFO B.

==UDP broadcast==

For interaction with other applications, DXLog can broadcast useful information as 
XML datagrams over UDP. 

There are five types of broadcast messages produced by DXLog:

* QSO information. Sent when logging.
* Radio information. Sent at changes as well as periodically.
* Antenna direction information. Sent when rotor control is invoked.
* Callsign look-up information
* Spots

QSO can be broadcasted in traditional DXLog format or in a more N1MM-like format.

Radio information can report SO2V as a single physical radio or as two physical radios, like N1MM.

There is an option to truncate the broadcasted QSO time to full minutes for better 
interoperability with some online services and software such as MSHV.

In addition, DXLog can also recognize QSY commands from Waterfall Bandmap and log QSO done as well as create 
local spots from decodes broadcasted by WSJT-X and its forks.

The broadcasting of QSO and radio related data is enabled using the <code>Options|Broadcast</code> submenu.

The broadcasting of spots is enabled by checking <code>Options|DX Cluster|Send spots to SmartSDR</code>.

[[image:radiobroadcastenable3.png]]

[[image:sendspotstosmartsdr.png]]

UDP broadcast parameters are configured in the <code>Options|Network configuration</code> panel. 
Please note that up to three ports can be specified for each broadcast, thereby supporting 
multiple receivers of the information.

[[image:Networksettingsbroadcast3.png]]

If you are writing a C# application to make use of these datagrams, there is a very nice online tool 
for creating an object from a sample XML datagram here https://xmltocsharp.azurewebsites.net/ 

In C# parsing is easily done using Linq. One example of XML parsing and deserialization using Linq 
can be found here https://github.com/bjornekelund/ICOMautomagic

===QSO information===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program
|-
| qsoid
| A unique string for this QSO. If this QSO is edited another contactinfo message will be sent with the same qsoid. Note that the qsoid is only unique within one instance of DXLog. If the computer is networked to others running DXLog the different computers may have a different qsoid for the same QSO.
|-
| contestname
| The name of the contest as it would be written to a Cabrillo file.
|-
| timestamp
| The UTC date and time of the QSO.
|-
| mycall
| The callsign of this station.
|-
| band
| The band on which the QSO was made. In MHz with period as decimal separator.
|-
| txfreq
| The frequency on which the QSO was made.
|-
| operator
| The callsign of the operator if the OPON command was used to set it, otherwise blank.
|-
| mode
| The mode used for the QSO.
|-
| call
| The callsign of the station worked.
|-
| countryprefix
| The DXCC country of the station worked.
|-
| wpxprefix
| The WPX prefix of the station worked.
|-
| snt
| The RST sent. This is always included whether or not the contest exchange contains an RST.
|-
| rcv
| The RST received. This is always included whether or not the contest exchange contains an RST.
|-
| nr
| The number sent if the exchange uses a serial number, otherwise the QSO number from this station.
|-
| exch1
| The first element in the contest exchange if any.
|-
| exch2
| The second element in the contest exchange if any.
|-
| exch3
| The third element in the contest exchange if any.
|-
| exch4
| The fourth element in the contest exchange if any.
|-
| xqso
| True if this QSO should not be counted towards the score.
|-
| invalid
| True if this QSO is invalid, for example a DX QSO in a domestic contest.
|-
| duplicate
| True if this QSO is a dupe (the station has previously been worked).
|-
| rule10broken
| True if this QSO breaks the 10 minute or similar rule. Note that a QSO may not break the 10 minute rule when it is logged but may later if another QSO is edited. This may not cause a broadcast.
|-
| azimuth
| The approximate direction of the station worked, in degrees.
|-
| distance
| The approximate distance of the station worked, in kilometers.
|-
| stationid
| The station ID of the station which made the QSO.
|-
| stationqso
| A unique QSO ID generated by the logging station. The combination of stationid and stationqso forms a unique identifier for the QSO.
|-
| stationtype
| The type of station - R for run, R1 for run 1 etc.
|-
| local
| True if this broadcast is due to this QSO being logged or edited on this computer.
|-
| runqso
| True if QSO logged in Run, false if S&P, and empty if unknown. '''Important:''' Only valid when local is True.
|-
| mult1
| The name of the multiplier if this station is a new multipllier, empty otherwise.
|-
| mult2
| The name of the multiplier if this station is a new multiplier, emtpy otherwise.
|-
| mult3
| The name of the multiplier if this station is a new multiplier, empty otherwise.
|-
| points
| The logged points for the QSO.
|-
| period
| The number of the operating period.
|-
| guid
| The GUID in hex format.
|-
| newqso
| True if a new QSO, False if this message is an update to an existing QSO.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<contactinfo>
<logger>DXLog v2.4.13</logger>
<qsoid>19</qsoid>
<contestname>ARRL-SS-CW</contestname>
<timestamp>2020-01-13 18:28:07</timestamp>
<mycall>SM7IUN</mycall>
<band>3.5</band>
<txfreq>352376</txfreq>
<operator></operator>
<mode>CW</mode>
<call>K4BAI</call>
<countryprefix>K</countryprefix>
<wpxprefix>K4</wpxprefix>
<snt>599</snt>
<rcv>599</rcv>
<nr>19</nr>
<exch1>076</exch1>
<exch2>B</exch2>
<exch3>54</exch3>
<exch4>GA</exch4>
<xqso>False</xqso>
<invalid>False</invalid>
<duplicate>False</duplicate>
<rule10broken>False</rule10broken>
<azimuth>225</azimuth>
<distance>1388</distance>
<stationid>STN1</stationid>
<stationqso>19</stationqso>
<stationtype>R1</stationtype>
<local>True</local>
<runqso>True</local>
<mult1>GA</mult1>
<mult2></mult2>
<mult3></mult3>
<points>3</points>
<period>1</period>
<guid>11223344556677889900aabbccddeeff</newqso>
<newqso>True</newqso>
</contactinfo>
</pre>

Alternative N1MM format

Note that the band name uses the computer's local number format so it may use either comma 
or period as decimal separator. The ID is a number rather than an alphanumeric string.

Also note that IsRunQSO is only valid when IsOriginal is True.

<pre><?xml version="1.0" encoding="utf-8"?>
<contactinfo>
<app>N1MM</app>
<contestname>CWOps</contestname>
<timestamp>2020-01-17 16:43:38</timestamp>
<mycall>SM7IUN</mycall>
<band>3.5</band>
<rxfreq>352519</rxfreq>
<txfreq>352519</txfreq>
<operator></operator>
<mode>CW</mode>
<call>K1XM</call>
<countryprefix>K</countryprefix>
<wpxprefix>K1</wpxprefix>
<stationprefix>K1XM</stationprefix>
<continent>NA</continent>
<snt>599</snt>
<sntnr>5</sntnr>
<rcv>599</rcv>
<misctext></misctext>
<ismultiplier1>1</ismultiplier1>
<ismultiplier2>0</ismultiplier2>
<ismultiplier3>0</ismultiplier3>
<points>l</points>
<radionr>l</radionr>
<run1run2>1<run1run2>
<IsOriginal>False</IsOriginal>
<NetBiosName>DESKTOP-23AB</NetBiosName>
<IsRunQSO>0</IsRunQSO>
<StationName>STATION_B</StationName>
<ID>23</ID>
<IsClaimedQso>true</IsClaimedQso>
</contactinfo>
</pre>

===Radio information===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| The name of the logging program.
|-
| logger
| The name and version of the logging program.
|-
| Station
| The ID of the station.
|-
| RadioNr
| The radio being described.
|-
| Freq
| The receiving frequency.
|-
| TXFreq
| The transmitting frequency
|-
| InactiveFreq
| The frequency of the VFO not receiving.
|-
| Mode
| The reported radio's mode.
|-
| OpCall
| The callsign of the operator if the OPON command was used to set it, otherwise blank.
|-
| mycall
| The callsign of the station.
|-
| IsRunning
| "True" if the station is running, "False" if search and pounce.
|-
| FocusEntry
| The Windows handle for the focused entry window.
|-
| Antenna
| Antenna number.
|-
| Rotors
| Rotators used by selected antenna (not currently used by DXLog).
|-
| FocusRadioNr
| The radio which has keyboard focus. In SO2V with "Report SO2V as two radios" checked, radio 2 is the sub/B VFO.
|-
| IsStereo
| True if headphones are listening to two radios.
|-
| IsSplit
| True if radio is set to split.
|-
| ActiveRadioNr
| The radio which is transmitting, if any.
|-
| Technique
| SO1R, SO2R, SO2R_ADV, or SO2V
|-
| StationType
| Station role: R, M, R1, R2, or R+.
|-
| isTransmitting
| True if a DXLog is transmitting. False if DXLog is not aware of transmission.
|-
| IFFrequency
| Optional element only used with Elecraft K3/K4. Contains the current IF frequency in Hz.
|-
|}

Important note: In SO2V the format differs from some other loggers and is:

: Only physical radio 1 is reported.
: <tt>Freq</tt> and <tt>TXFreq</tt> are the frequency of the currently focused VFO.
: <tt>InactiveFreq</tt> is the frequency of the currently unfocused VFO.
: <tt>ActiveRadio</tt> is always 1.
: <tt>FocusedRadioNr</tt> is 1 when the main/A VFO is focused, 2 otherwise.
: <tt>IsSplit</tt> is always false.

With the option "Report SO2V as two radios" checked, the reporting is similar to some other loggers and is:

: The two VFO are reported as two physical radios.
: <tt>Freq</tt> and <tt>TXFreq</tt> for radio 1 are the frequency of the main/A VFO.
: <tt>Freq</tt> and <tt>TXFreq</tt> for radio 2 are the frequency of the sub/B VFO.
: <tt>InactiveFreq</tt> is the frequency of the other VFO.
: <tt>ActiveRadio</tt> and <tt>FocusedRadioNr</tt> are 1 when the main/A VFO is focused, 2 otherwise.
: <tt>IsSplit</tt> is always false.

Example message:

<pre><?xml version = "1.0"?>
<RadioInfo>
<app>DXLog</app>
<logger>DXLog v2.4.13</logger>
<Station>STN1</Station>
<RadioNr>1</RadioNr>
<Freq>704000</Freq>
<TXFreq>704000</TXFreq>
<InactiveFreq>702500</InactiveFreq>
<Mode>CW</Mode>
<OpCall>K1XM</OpCall>
<mycall>HQ9X</mycall>
<IsRunning>False</IsRunning>
<FocusEntry>591124</FocusEntry>
<Antenna>1</Antenna>
<Rotors>ABC</Rotors>
<FocusRadioNr>1</FocusRadioNr>
<IsStereo>False</IsStereo>
<IsSplit>False</IsSplit>
<ActiveRadioNr>1</ActiveRadioNr>
<Technique>SO2R</Technique>
<StationType>R1</StationType>
<IsTransmitting>False</IsTransmitting>
<IFFrequency>8215000</IFFrequency>
</RadioInfo>
</pre>

===Antenna direction===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program.
|-
| station
| The ID of the station.
|-
| radio
| The radio associated with the rotator.
|-
| go
| True if the rotator should be turned.
|-
| stop
| True if the rotator should be stopped if it is turning.
|-
| azimuth
| The direction to turn the rotator if go is True.
|-
| frequency
| The transmit frequency of the specified radio.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<Rotator>
<logger>DXLog v2.4.13</logger>
<station>STN1</station>
<radio>2</radio>
<go>True</go>
<azimuth>252</azimuth>
<frequency>2800200</frequency>
</Rotator>

</pre>
<pre><?xml version="1.0" encoding="utf-8"?>
<Rotator>
<logger>DXLog v2.4.13</logger>
<station>STN1</station>
<radio>2</radio>
<stop>True</stop>
<frequency>2800200</frequency>
</Rotator>
</pre>

===Callsign lookup===

Sent either when callsign in entry row is changed or when space or tab is pressed.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program.
|-
| contestname
| The name of the contest.
|-
| mycall
| Station's call
|-
| band
| Current band
|-
| txfreq
| Transmitter frequency
|-
| operator
| The call sign of the logged in operator
|-
| mode
| Operating mode
|-
| call
| Call entered in the logging field
|-
| countryprefix
| DXCC entity prefix
|-
| wpxprefix
| WPX prefix
|-
| azimuth
| Short path antenna direction
|-
| distance
| Distance in km
|-
| stationid
| The ID of the station sending the datagram
|-
| stationtype
| The role of the station sending the datagram; R, R1, R2, M, or R+
|-
| period
| Contest period
|-
| reason
| Reason for transmission; SpaceOrTab or CallChanged
|-
|}

Example message:

<pre><?xml version = "1.0"?>
<lookupinfo>
<logger>DXLog v2.4.20</logger>
<contestname>DARC-WAEDC-CW</contestname>
<mycall>K1XM</mycall>
<band>20</band>
<txfreq>1400200</txfreq>
<operator></operator>
<mode>CW</mode>
<call>E7DX</call>
<countryprefix>E7</countryprefix>
<wpxprefix>E7</wpxprefix>
<azimuth>54</azimuth>
<distance>6824</distance>
<stationid></stationid>
<stationtype>R</stationtype>
<period>1</period>
<reason>SpaceOrTab</reason>
</lookupinfo>
</pre>

===Spot===

Sent for every incoming spot from the DX cluster that is valid for the current contest.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| Application sending the message.
|-
| StationName
| The station issuing the broadcast.
|-
| dxcall
| The callsign of the spotted station.
|-
| frequency
| Frequency in kHz with decimal sign of the PC's current locale. (sic)
|-
| spottercall
| The callsign of the spotter. Station name if locally spotted or result of a logging operation.
|-
| timestamp
| Spot time in format yyyy-MM-dd HH:mm:ss
|-
| action
| add or delete.
|-
| mode
| actual or guessed mode of the spot in capitals.
|-
| comment
| The comment section of the spot.
|-
| status
| Spot status. Valid values are "dupe", "double mult", "single mult", and "new qso".
|-
| statuslist
| Same as status
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<spot>
<app>DXLog.net</app>
<StationName>CONTEST-PC</StationName>
<dxcall>E7DX</dxcall>
<frequency>14022.3</frequency>
<spottercall>SM7IUN-#</spottercall>
<timestamp>2O23-07-15 14:29:37</timestamp>
<action>add</action>
<mode>CW</mode>
<comment>CW 31 DB 42 WPM CQ</comment>
<status>single mult</status>
<statuslist>single mult</statuslist>
</spot></pre>

===Broadcast listener===

DXLog also listens for commands over UDP.

Currently only one command is implemented, <code><radio_setfrequency></code>, which is a QSY command.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| Application sending the command
|-
| radionr
| The radio to be changed. In SO2V radio 2 means VFO B. Optional as of DXLog 2.5.20.
|-
| frequency
| Requested frequency. Both period and comma is accepted as decimal separator.
|-
| mousebutton
| Which mouse button was used to create message, if any. Optional.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<radio_setfrequency>
<app>WaterfallBandmap</app>
<radionr>1</radionr>
<frequency>21022.194</frequency>
<mousebutton>Left</mousebutton>
</radio_setfrequency>
</pre>

==SDR integration==

===HDSDR, OmniRig, and microHAM===

''Contributed by Ingo SM5AJV/SE5E''

Until DXLog offers SDR integration there are still ways to get a waterfall/spectrum display with DXLog.

I have integrated the free SDR software [http://www.hdsdr.de/ HDSDR] with DXLog using
[http://www.microham.com Microham Device Router], 
[http://dxatlas.com/OmniRig/ OmniRig]
and [https://www.autohotkey.com/ AutoHotkey].

As illustrated below I place the HDSDR window at the very top of the desktop with DXLog right below.

I share my transceiver's (an Elecraft K3) antenna with the SDR. The receiver antenna signal from my 
K3's RX-ANT OUT is connected to the input of a 3dB power splitter. The two outputs from the splitter 
are connected RX-ANT IN on the K3 and the SDR Receiver antenna input, respectively. On a K3 you 
need to enable the RX-antenna input to make this to work. An additional benefit with this method 
is that the SDR is protected during transmission. It is a widely used method and is e.g. described 
by Bob N6TV in this
[http://dxlog.net/sw/files/utilities/Adding%20an%20SDR%20to%20an%20SO2R%20Station.pdf presentation].

'''Screenshot of my desktop:

[[Image:Sdrdesktop.png|800px]]

Since both DXLog and HDSDR need to communicate with the radio, you need to "split" 
the CAT communication. microHAM's USB Device Router provides a second, independent, 
CAT port that can be used via HDSDR's omniRig interface.

'''"PORT" Tab on microHamRouter:

[[Image:Sdrmicrohamrouter.png|800px]]

'''OmniRig settings in HDSDR:

[[Image:Sdromnirig.png|200px]]

With this set up, the radio, DxLog, and HDSDR will be fully synchronized. For instance, you can 
click in the waterfall to make the radio QSY, and it is easy to quickly find a clean frequency.

To make the integration even better I use a small AutoHotkey script. The script pulls entry focus 
back to DxLog after clicking on the HDSDR waterfall and in DXLog it allows you to use hotkeys to 
control HDSDR. <code>[Ctrl][Alt]+</code> and <code>[Ctrl][Alt]-</code> zooms the waterfall/spectrum 
in and out, and <code>[Ctrl][Alt]C</code> centers it.

'''AutoHotkey script:

SetTitleMatchMode, 2
#InstallKeybdHook
#IfWinActive, HDSDR
{
F4:: return ; disable F4
~LButton Up::
sleep, 1
Winactivate, DXLog
return
}
#IfWinActive, DXLog
{
^!+:: ControlSend ,, ^{+}, HDSDR
^!-:: ControlSend ,, ^{-}, HDSDR
^!c:: ControlSend ,, {c}, HDSDR
}

The script can be downloaded [http://DXLog/sw/files/utilities/dxlog_hdsr.ahk here].

If you start two instances of HDSDR with two different SDR you can even have two waterfalls 
running at the same time.

I have not yet found a way to display cluster spots in the HDSDR spectrum panel. 
But I still find it very useful to check band activity and it allows me to easily find 
a new Run frequency on a crowded band.

===Waterfall Bandmap===

The free waterfall/spot display utility "Waterfall Bandmap" by Steve N2IC is supported by DXLog.

Waterfall Bandmap supports almost any SDR that produce I/Q output either via ExtIO.DLL or a 
sound card; SDRPlay, FunCubeProPlus, HackRF, SDR-IQ, RTLSDR, SoftRock, etc.

A zip file with an executable binary and a Microsoft word document with installation and 
configuration instructions can be found here: https://groups.io/g/waterfallbandmap/files

If you are not a member of the support forum group, you need to apply for membership to download. 
Membership is free.

[[Image:Waterfallbandmap.png]]

The SDR can be connected either to a separate receive antenna, an external receiver output on 
your transceiver or to an IF output, should your transceiver have one. If connected to an antenna, 
keep in mind that you may need protection from the transmitter such as a T/R relay or a passive level limiter.

Please refer to Waterfall Bandmap's documentation for setting it up with your SDR.

Waterfall Bandmap needs two information feeds over UDP: Radio information and spot information. 
Both are provided as UDP broadcast by DXLog.

The default port for both is 13063 and this needs to be set in DXLog's Network configuration panel. 
If Waterfall Bandmap runs on the same computer as DXLog, the broadcast address can be left at the default 127.0.0.1.

[[Image:Setbroadcastportsforwfbandmap.png]]

Clicking on the waterfall display can set the frequency of DXLog. (Left click sets VFO A, right click sets VFO B.) 
To enable this functionality, check the option <code>Options|Broadcast|Receive Broadcasts</code> 
Also make sure "UDP broadcast listener" includes port 13064 in the network settings panel.

The radio information feed needs to be enabled by checking the <code>Options|Broadcast|Radio information</code> option

[[Image:radiobroadcastenable2.png]]

and the spot feed needs to be enabled by checking the <code>Options|DX Cluster|Send spots to SmartSDR</code> option.

[[Image:Enablesendspotstosmartsdr.png]]

==Time synchronization==

In a multi-station setting, the time needs to be accurately synchronized across all networked PC.

Windows' built in time synchronization is very crude and for a PC with poor clock stability the 
inaccuracy of the clock may be up to a minute. Which of course is not acceptable for contesting.

DXLog has built in support for time synchronization as described in the [[Menu Options#Configure network|Configure network section]].

Due to Windows' security system, this however requires all except the PC running as time server to 
run DXLog with elevated permissions. There is unfortunately no way around this inconvenience.

An equally accurate and less intrusive method is to use a standalone time synchronization application on each networked PC. 
This will keep each PC's clock accurate within a fraction of a second.

Contrary to a solution built into a logger it also has the great benefit of being an "install and forget" solution.

A popular application is Dimension 4 by Thinking Man Software. It is free for personal use and 
can be downloaded here: https://dxlog.net/sw/files/utilities/d4time531.msi

It runs in the background and only shows up as a tiny icon in your system tray. 
You hover the mouse above the icon to check status and right-click to open and change settings.

:::[[image:dimension4tray.png|50px]]

After installation a brief configuration is required.

First of all, allow the application to disable Windows' time service and to modify your system clock.

For maximum accuracy, select a time server geographically close to your location. 
When in doubt, you can always add the global server "pool.ntp.org" to the list and use that. 

There are also national and continental pools of time servers. You can find them here https://www.ntppool.org.

[[image:dimension4b.png]]

Make sure the check boxes "Load Dimension 4 at startup", "Start minimized", "Hide when minimized", 
and "Display icon in tray" are all checked.

[[image:dimension4advanced.png]]

Click the Advanced button and also make sure the option "Use the selected server" is selected.

Make sure the application reports a successful connection to the selected time server. 
From here on, you can basically forget the application. 
It will silently start with your PC and always keep its time accurate.

==Disabling USB power management==

In the interest of saving energy, Windows habitually power down USB interfaces 
when it believes there is inactivity. Some USB-to-serial and USB audio devices 
respond poorly to being suspended or powered down so as a rule this "feature" should 
be disabled when used in a ham radio environment.

There are two places where this functionality needs to be disabled; the device driver 
and Windows' energy management.

To disable it for each USB interface and device, open Windows settings. (Click the Windows 
icon in the lower left corner and then chose the cogwheel.) Type ''device manager'' and
select the result.

[[image:devicemanager-c.png|none|frame]]

This opens up a new window, Windows' Device Manager.

[[image:devicemanager2b.png|none|frame]]

For '''every''' USB interface component (there may be many), COM-port, and audio device, 
and '''uncheck''' the option ''Allow the computer to turn this device off to save power''.

The devices you are looking for are in the categories: ''Ports (COM & LPT)'', 
''Sound, video and game controllers'', ''Universal serial bus controllers'',

Note that some devices may not have a ''Power Management'' tab.

[[image:usbdevicemanager.png|none|frame]]

The next step is to disable Windows ''Selective suspend'' feature for USB interfaces.

Go back to Windows Settings and type ''edit power'', click the appearing ''Edit power plan'' menu entry.

[[image:editpowerplan2.png|none|frame]]

This should open the window below, the plan editing panel.

[[image:editplansettings.png|none|frame]]

Click ''Change advanced power settings''. Scroll down to ''USB settings'' and make 
sure ''USB selective suspend setting'' is '''disabled''' for all situations.

[[image:Advancedsettings.png|none|frame]]

To prevent audio devices from becoming unreachable or going into sleep mode you should also 
disable exclusive access. While changing this, also make sure all audio enhancements are disabled.

You reach the detailed audio device settings by entering Windows settings, search for Control panel, 
and in the Control panel view, select Hardware and audio, and then Sound.

[[image:Audiodevice.png]]

Reboot your computer to make sure all settings are recognized by Windows.

==Interlock and inband operation==

In contest station terminology, the term ''Interlock'' refers to a technical solution preventing 
more than one station from using a shared resource, typically an antenna, at the same time.

The most common use for interlock is for inband operation. Inband operation means to have multiple 
transmitters on a single band, interleaving their transmissions. Sometimes on a split-second basis.

As long as you never have more than one transmitter active at any time, the majority of contests allow 
an unlimited number of transmitters and receivers on a single band for multi-operator categories. 
This fact is used by most big contest stations.

For an inband solution to be effective, each station must be able to receive while the 
other station transmits. This means it requires a separate, high performance receive antenna 
with very good isolation from the transmitter antenna. The most common way to 
achieve this is physical separation and geographic orientation to minimize the situations 
when they will radiate/listen in the direction of the other antenna.

For a station operating in the M/M, M/S, or M/2 category, inband operation can boost the points 
per hour performance significantly. It is also a lot more fun.

However, as with everything else, it comes at a cost. An efficient inband solution has:

* A high performance receive antenna for each operated band(s) with very good isolation from the transmitter antenna.
* A fail-safe antenna switching hardware.
* Interlock-capable keyers and/or station controllers.
* An interlock-capable contest logging software

A typical inband configuration can be seen in the illustration below.

[[image:inbandconcept-trx.jpg|800px]]

DXLog offers a software-based interlock which can be configured in a variety of ways, e.g. based on frequency 
band, operating mode, or station role. It supports an unlimited number of stations interlocking each other 
using a great variety of strategies.

The interlock relies on UDP networking and is overlaid on the communication for multi-station logging. 
UDP networking has the benefit of speed and low latency but is, unlike TCP, susceptible to packet loss. 
This means that a '''wired LAN''' is a necessity for any station using interlock. 
For the same reason, it is also not recommended to run interlock over e.g. VLAN/VPN link for 
geographically distributed stations.

A software interlock is not 100% reliable. Computer or software malfunction, networking issues such as packet 
loss, etc. can cause interlock to fail, even if only momentarily.

For this reason it is necessary to also accompany a software interlock with a fail-safe '''hardware''' interlock. 
Without hardware supported interlock you run the risk of not only violating contest rules but also cause serious equipment damage. 
Some contests, such as CQ WW, explicitly requires hardware interlock when using multiple stations on the same band.

There are many designs and even commercial products available for hardware interlock. 
One example of a simple but effective two station hardware interlock which also supports 
power amplifier sharing can be found [https://sm7iun.se/contest/inband/ HERE].

The purpose of this section is to describe steps of setting up a basic two station in-band solution with 
DXLog and microHAM keyers. The microHAM keyers are not mandatory but offers a much better user experience 
and removes the need for additional hardware.

'''Pro tip:''' Consider checking <code>Options|Networking|Allow other stations to abort sending</code> 
which will allow your partner station to interrupt your transmission with <code>[Shift][Esc]</code> in 
critical situations. Be careful though, the use of this function requires good judgment to avoid violence.

===Networking===

Open the networking configuration panel with <code>Options|Configure network</code> and make sure each 
station has a unique name and that only UDP networking is enabled.

Make sure the two stations use the same broadcast IP address and that it is in line with your LAN's 
configuration. Pressing the <tt>Default</tt> button is a good way to ensure this.

Make sure the menu option <code>Options|Enable network</code> has a checkmark.

[[image:inbandnetworkrun.png|left|frame]][[image:inbandnetworkinband.png|none|frame]] 

===DXLog Interlock configuration===

First of all, make sure that the <code>Options|Interface specific options|Prevent TX if another radio is on same band</code> 
is '''not''' enabled. This option completely prevents transmission if more than one networked station is set to the same band 
and the whole idea with inband is to have exactly that.

Next, activate software interlock on both stations using the menu option <code>Options|Networking|Software interlock</code> 
or by typing the commmand <tt>ILOCKON</tt>.

[[image:inbandinterlock2.png|none|frame]]

There are multiple options for configuring the interlock. In a simple set up with only two stations, the topmost 
option ''Same band from status list'' is a good choice. This option will prevent more than one station transmitting 
on the same band, regardless of mode.

In an environment with many stations (such as a multi-operator-multi-transmitter station) it is 
recommended to use the bottom option to only interlock with one or several named stations. 
This will reduce both LAN traffic and inband operation latency. This is particularly important when 
running parts of the DXLog network over high latency links such as VLAN/VPN or if some stations (albeit not 
part of the interlock cluster) are connected via Wi-Fi.

For more advanced scenarios you can also use interlock based on mode or station type (e.g. Run 1, Run 2, Mult, etc.).

The "status list" listing the networked DXLog stations is displayed in the ''Status Window'' which is opened 
with <code>Windows|Status window</code> or <code>[Alt][J]</code>.

[[image:inbandstatuslist2.png]]

DXLog also offers great flexibility when it comes to interlock strategy. The most straightforward and 
most commonly used is ''First one wins''. This is also typically the behavior of "unintelligent" 
hardware solutions when not assisted by software. With this strategy, the station starting to transmit 
first can not be interrupted and always gets to finish its transmission.

[[image:inbandinterlockoptions.png]]

With a ''Last one wins'' strategy, the transmitting station can be interrupted. A carte blanche permission 
to interrupt all transmissions by the other station may however be counterproductive in a real contest situation.

For this reason, DXLog offers additional control of which transmit actions can be interrupted and which can not. 
This is a powerful tool but requires both operators to be aware of it and may require 
practice before fully effective.

[[image:inbandstrategyexceptions.png]]

''F1'' through ''F7'', ''PLUS'' and ''INS'' refers to DXLog's standard messages. ''KEYB'' means a free text transmission 
from the keyboard using the <code>[Alt][K]</code> function and ''MAN'' means manual transmission using either paddle 
break-in or a footswitch.

For CW, DXLog recognizes paddle break in from a K1EL Winkey-compatible keyer as described in the [[Menu_Options#Winkey_Configuration|Winkey configuration section]].

Since DXLog recognizes a footswitch connected to a microHAM device, this is a recommended approach for phone. 
It is also possible to connect a footswitch to the DSR pin (pin 6) on a physical COM-port on the PC, but today 
few PC have such a port and it also requires additional circuitry.
Details on how to do this is available [[Additional_Information#Connecting_a_footswitch|HERE]].

===microHAM configuration===

Open the microHAM device configuration panel with <code>Options|microHAM device configuration</code>.

[[image:Mk2r-new9.png|none|frame]]

Check the option ''Enable TX lock/unlock''. This will do two things; it will enable DXLog to prevent 
transmission and and it will make DXLog aware of the microHAM device's PTT status. The latter is particularly 
important since it means DXLog will recognize PTT assertion not only by a footswitch connected to the 
microHAM device but also by the built-in Winkeyer (requires microHAM USB Device Router version 9.3.0 or later) 
'''Paddle-based break-in in an inband solution is currently unique for microHAM with DXLog.'''

'''Important:''' Making DXLog "PTT aware" means that care has to be taken in how PTT is set up. If you, for instance, 
enable DXLog PTT for the voice keyer, this will create a self-reinforcing feedback loop and PTT will thus never drop.

Check the option ''Dual radio device'' if you are using a u2R, MK2R, or MK2R+, otherwise, leave this unchecked.

Check the option ''Device without CAT interface'' if the device lacks a CAT interface (like the u2R) 
or if its CAT interface is not connected to the radio. This option will make sure the e.g. keying and 
audio routing is always set correctly in line with the operating mode (Voice, CW, or RTTY).

===Operating===

Inband operation requires a fair amount of training and it is a good idea to define and agree 
on general rules for operation, such as hand signals for challenging QSO, beforehand.

There are more than enough YouTube videos of inband operators yelling at each other.

The operating tactics may have to be adjusted during the contest. If Run is slow, 
doing S&P on the inband station can increase the points per minute significantly. 
However, if Run is strong, an overly active inband operator doing S&P, but not working 
multipliers, may actually reduce the station's points per minute significantly.

Real-time interlock status is shown in the ''Radio status'' window, which is opened with 
<code>Windows|Radio status</code>.

[[image:inbandblocking.png]] [[image:inbandblocked.png]]

For Phone contesting, you typically rely on footswitches for PTT and the option 
<code>Options|Networking|Show QSO status when blocking</code> makes the blocking 
station send a more helpful blocking cause than ''MAN''.

With this option enabled, the blocking station will instead send ''CQ'', ''QSO'', or ''EXCHANGE'' 
as blocking cause, determined by cursor location and entry field content at the locking station.

Further reading can be found in the [[Menu_Options#microHAM_device_configuration|microHAM device configuration]] and [[Menu_Options#Networking|Networking]] sections.

==Connecting a footswitch==

To free up both hands in Phone contesting, a footswitch PTT is a great help.

Also, to use interlock in Phone contesting, a footswitch is mandatory.

There are two basic ways to interface a footswitch with DXLog; via a microHAM device (which is the recommended solution) 
or directly connected to a physical serial port on the PC (which very few PC have today).

The connection of a footswitch to a microHAM device is very straightforward and by checking the ''Enable TX lock/unlock'' 
in the ''microHAM device configuration'' panel, it is recognized by DXLog.

Lacking a microHAM device, it is also possible to use the computer's DB9 RS-232 serial port connector, providing it has one.

The required steps to do this are:
* Connect a 10k resistor between DB9 pin 6 and pin 7.
* In the port's settings (<code>Options|Configure interfaces</code>) set DTR (pin 4) to ''Always On'' and RTS (pin 7) to ''Always Off'' for the port.
* Connect the footswitch between DB9 pins 4 and pin 6. '''Important:''' Neither pole on the footswitch must be connected to ground.
* In the radio's configuration panel, check ''use CAT PTT command on Phone'' and set ''Footswitch (pin 6)'' to ''PTT''

==Support for CC Cluster==

CC Cluster is today the main choice for contest use.

It offers a high quality, database-verified, flow of skimmer spots and a rapid 3-minute respotting period for skimmer spots.

It also publishes unique spots from less common locations which are valuable for DX chasers or as contest multipliers.

To make use of the display of own spot in the world map, make sure to issue the command '''<tt>SET/OWN</tt>''' to the cluster node. 
This setting is persistent and only needs to be done once.

A list of cluster nodes that runs CC Cluster can be found here: [https://www.dxcluster.info/telnet/index.php?software=CC%20Cluster CC Cluster nodes]

A description of the command line syntax can be found here: [http://bcdxc.org/ve7cc/ccc/CCC_Commands.htm CC Cluster command syntax]

A convenient software for setting up filters etc. can be found here [http://www.bcdxc.org/ve7cc/default.htm#prog CC User]

[[Image:Ccclustersspotflow.png]]

==Support for AR Cluster 6==

With the author tragically SK, AR Cluster is no longer under development but still available as an executable binary.

In its standard configuration, AR Cluster offers no consolidation of skimmer spots meaning a very high flow of spots 
that can become extreme during a major contest weekend.

With the advent of skimmers, the traffic on the DX Cluster has risen dramatically. Even though CW skimmers are generally 
quite reliable, the absolute number of busted spots can be quite high during a busy contest.

Jose CT1BOH has developed an algorithm for evaluating spot quality which is included in version 6 of AR Cluster. 
Today many cluster nodes runs this version and thereby offer this mechanic. 
A complete list can be found here: [http://www.dxcluster.info/telnet/index.php?software=AR-Cluster AR Cluster nodes]

To enable the functionality on a cluster node running AR Cluster 6, the command

<tt>'''SET DX EXTENSION SKIMMERQUALITY'''</tt>

needs to be issued to the cluster node. The easiest way to do this in DXLog is via <code>[Alt][T]</code>. 
This setting will be remembered at subsequent logins.

The quality of the spots is indicated by a character ("tag") in the last column of the comment field and, 
in some cases, a corrected callsign within parenthesis. This syntax is recognized by DXLog and can reduce the 
number of bad spots in your bandmap.

The CT1BOH skimmer quality algorithm is based on three parts:

; Validation : When a callsign is first spotted, it is tagged with "?" in the last column of the spot's comment field. If the callsign of an unverified spot closely resembles an already verified one on the same frequency, the verified callsign is provided within parenthesis in the spot's comment field. When two or more skimmers agree on the spot, it is considered verified and the tag becomes "V".

; Frequency : When a verified spot appears more than 0.35kHz off its verified frequency, the spot is tagged "Q" for QSY. Once verified, this becomes the new verified frequency and it is tagged "V".

; Probability : The algorithm checks uncertain spots for resemblance with already verified spots and spots at or near the same frequency. If the resemblance is high enough, the spot is considered busted "B" and the corrected callsign is provided within parenthesis in the spot's comment field.

Below you can see an example of the spot flow from W9PA-4 with skimmer quality enabled. 
The flow contains one unverified and one busted spot.

[[image:spotquality.png]]

DXLog's policy for spots with CT1BOH skimmer quality tags is the following:

: '''V''' - Accept spot.
: '''Q''' - Accept spot.
: '''?''' - Accept spot. Use corrected call when provided.
: '''B''' - Accept spot if corrected call provided. Else ignore.

DXLog recognizes the skimmer quality tags but consolidates them for consistency 
with other cluster nodes' quality tags and to minimize confusion when mixing spot flows. 
The legend is:

: '''?''' means a spot with ? This is an unreliable spot.
: '''P''' means a spot with Q or B with correction. This is a fairly reliable spot.
: '''V''' means a spot with V. This spot is considered validated.

This basic policy can be modified by using additional filters at the cluster node end. Some examples are:

: <tt>'''SET DX FILTER NOT SKIMBUSTED'''</tt> - Do not send busted spots at all
: <tt>'''SET DX FILTER NOT SKIMQSY'''</tt> - Do not send QSY spots
: <tt>'''SET DX FILTER SKIMVALID'''</tt> - Only send verified spots
: <tt>'''SET DX FILTER NOT SKIMUNKNOWN'''</tt> - Do not send unreliable spots
: <tt>'''SET DX FILTER SKIMMER'''</tt> - Do not send manual spots

You can also compose more complex filters such as:

: <tt>'''SET DX FILTER SKIMVALID OR SKIMBUSTED OR NOT SKIMMER'''</tt>

This can be a good filter for most contests. It will will only provide valid or busted skimmer spots together with manual spots. 
It is safe to receive busted spots since DXLog will ignore them if there is no corrected callsign included. 

For assisted operation in serious contesting you however need to allow also unknown spots since weak stations spotted 
only by one or a few skimmers may never reach validated status. You do this by adding <tt>'''OR SKIMUNKNOWN'''</tt> to the filter.

Both the bandmap and the DX cluster announcement windows have the option to display the spot quality tag. 
These windows will show two additional tags; L and C. L stands for local spot, created by yourself or one of your team members. 
C stands for corrected, i.e., a B or ? spot where a corrected call has been included in the spot's comment field.

The AR6 filtering syntax offers a lot of flexibility. Another example:

: <tt>'''SET DX FILTER (SKIMVALID OR NOT SKIMMER OR ((SKIMQSY OR SKIMUNKNOWN) AND (CTY <> K AND CONT <> EU )))'''</tt>

will provide only validated and human spots except if they are from outside the US and EU.

If you get lost in the filter settings you can always reset with : <tt>'''SET DX DEFAULT'''</tt>.

Some more guidance on how to work with filters on AR-Cluster nodes can be found in [http://dxlog.net/sw/files/utilities/AR_Cluster_v6_User_Manual.pdf this document].

==Support for DXSpider==

DXSpider is the by far most dominant DX cluster software but has historically not been a good choice for contesters. 
The reasons for this include: Long respotting time, lack of pass function for own spots, and suppression of spots from a single skimmer.

The good news is however that the author Dirk G1TLH has worked hard to address these aspects of the otherwise brilliant software.

From '''version 1.57 release 440''' the respotting time is now 3 minutes and there is a <tt>SET/SEEME</tt> command that passes all spots 
without consolidation of your own callsign.

So if your favorite cluster node is not running this version, ask the owner to upgrade asap.

Yet another reason for its popularity is its extreme resource-efficiency which allows it to run virtually 
any Linux capable hardware, including a $20 Raspberry Pi Zero.

A list of all DX cluster nodes running DX Spider can be found here: [https://www.dxcluster.info/telnet/index.php?software=DX%20Spider DX Spider cluster nodes]

[[image:dxspiderflow.png]]

DXLog recognizes the <tt>Q:#</tt> skimmer quality tag in the comment field and converts them into "CT1BOH-like" quality 
tags that can be displayed in DXLog's bandmap. The legend is:

: '''?''' means a spot with Q:1, i.e. heard by only one skimmer. This is an unreliable spot.
: '''P''' means a spot with Q:2, i.e. heard by only two skimmers. This is a fairly reliable spot.
: '''V''' means a spot with Q:3 or higher, i.e. heard by several skimmers. This spot is considered validated.

Since a DXSpider node currently needs to be specially configured by the owner to publish Q:1 spots, very few do this. 
Also, since DXSpider lacks busted call detection, the the quality of the spot flow will suffer if this is done.

There is a wealth of information to be found on the [http://wiki.dxcluster.org/index.php/Main_Page DXSpider wiki].

==Support for N2WQ Cluster==

Introduced in late 2025, Rudy N2WQ has developed the first new DX cluster node software in decades.

The N2WQ-2 cluster has some unique features like a more advanced callsign validation than 
AR 6 and propagation estimation tags embedded in the spot comments. An example can be seen below.

[[image:n2wpspotflow.png]]

When you connect to dxc.n2wq.com port 8300 and you have set your 4-digit Maidenhead grid (SET GRID), there 
will be a single character just before the DX’s grid locator. This character is the path prediction glyph.

It is a crowdsourced, real-time estimate of how reliable the path is between you and the DX on that band right now, 
based on recent on-air propagation reports from RBN and PSKreporter. Its values and meaning are:

: > High: Strong path. If you can hear them, you should be able to work them.
: = Medium: Decent path. Workable with normal contest/DX technique.
: < Low: Weak path. Possible, but expect repeats, timing, and patience.
: - Unlikely: Marginal. Try only if it’s rare/needed, or you have a strong station advantage.

A missing glyph means insufficient data to estimate the path.

the glyph is mode-aware. A path that looks great for a very sensitive mode (FT8) can look 
more moderate for a less sensitive one (SSB).

You can filter spots by path reliability using the PASS/REJECT PATH command.

It is important to be aware that the glyph does not know:

: Your antenna gain/pattern, height, or takeoff angle
: Your transmit power and duty cycle constraints
: Your operating technique (timing, split discipline, pileup strategy)
: Short-lived phenomena the network has not yet “seen” such as sporadic E or aurora.

The cluster ingests upwards of 50,000 CW, FT, RTTY, and WSPR spots per minute. To compare different modes 
fairly, the system normalizes reports onto a common “FT8-equivalent” scale (so a CW SNR can be compared 
to an FT8 SNR).

Your grid and the DX grid are mapped into small geographic cells and the cluster calculates propagation 
at two levels:

: Fine (local): what’s happening close to your area (~180 miles).
:: On averages there are about 90,000 DE/DX pairs being tracked
: Coarse (regional): what’s happening in the broader region around
:: you (~480 miles). On average, there are about 30,000 DE/DX pairs.

If there isn’t enough local data, the system leans more on regional behavior. 
If there’s plenty of local data, it uses that more heavily.

Sometimes you can hear them better than they can hear you (or the reverse) due to noise 
floors, antennas, geography, or ionospheric effects. The system tracks both:

: Receive direction: DX to you (can you hear them?)
: Transmit direction: you to DX (can they hear you?)

It combines these into one “path reliability” estimate, weighting receive a bit more 
because if you can’t hear them, you can’t work them.

Propagation changes fast, so older reports get discounted using a half-life (data fades 
in influence over time). Typical behavior by band:

: Low bands (160/80m): slower changes (longer half-life)
: Mid bands (40–20m): medium pace
: High bands (15–6m): fast changes (shorter half-life)

In practice, this means glyphs can shift in minutes on 10m/6m, and more slowly on 80m/160m. 
Also, new openings take time to show up. A "insufficient" can simply mean “the path just opened 
and the cluster hasn’t collected enough recent reports yet.”

Your local noise floor heavily affects what you can receive, so the cluster lets you tell 
it what your noise environment is. This mainly tunes the receive-side expectation (DX to you).

Set it with SET NOISE SUBURBAN. Available profiles per ITU:

: QUIET: very low noise, rural/remote
: RURAL: mild noise
: SUBURBAN: typical neighborhood QRM
: URBAN: elevated noise, dense housing
: INDUSTRIAL: severe noise

If you don’t set it, the system may assume a quieter environment than you actually 
have, and your receive-side glyphs can look too optimistic.

Treat the glyph as a real-time probability hint that helps you spend your operating 
time where the odds are best. When you see > on a needed multiplier, move fast. 
When you see -, be intentional about whether it’s worth the time. 
And when you see a space, fall back to classic DX/contest instincts and your own ears.

The N2WQ cluster also offers spot quality tags between the DX grid and the time.

A quality (in terms of callsign reliability) tag can be V, P, S, C, or ? where V means validated, 
P highly likely, S less likely, C corrected, and ? unsure.

The propagation and quality tags can be displayed in the bandmaps and the DX cluster announcement window.

DXLog recognizes the skimmer quality tags but consolidates them before display for consistency 
with other cluster nodes' quality tags and to minimize confusion when mixing spot flows. 
The legend is:

: '''?''' means a spot with ? or S. This is an unreliable spot.
: '''P''' means a spot with P or C. This is a fairly reliable spot.
: '''V''' means a spot with V. This spot is considered verified.

==Interacting with WSJT-X==

Important: When in a DXpedition/multi-station setting, always use local host 127.0.0.1 as the 
broadcast address to prevent packets being picked up by other stations in the network. 
Also, enabling the creation of local spots from decodes may overwhelm DXLog.

DXLog can add QSO performed with WSJT-X to its log. Note that this functionality only works 
for contests with grid as the first and only exchange or for DXPedition type logs.

DXLog can also create local spots from WSJT-X decodes by checking 
<code>Options|Broadcast|Spot WSJT-X decodes</code>.

To enable logging of WSJT-X QSO, set up WSJT-X to broadcast information:

[[image:Wsjt-x-udp.png]]

[[image:Radiobroadcastenable3.png]]

Activate DXLog's UDP listener by checking <code>Options|Broadcast|Receive broadcasts</code> and set 
the same port number as in WSTJ-X in DXLog's network configuration panel.

[[image:Dxlog-udp.png]]

==Using Winkey FSK==

Winkey FSK is not natively supported by DXLog's digital mode engines MMVARI or MMTTY but 
Rafal EI6LA has developed a plugin for MMTTY that makes this possible.

You can find it [https://github.com/RafalLukawiecki/WinKeyerMMTY here].

==Interfacing with LogHX==

Christian F8GHE has prepared a guide on how to do this.

You can find it [http://dxlog.net/sw/files/utilities/DXLOG-LogHX_UDP-config_v2.pdf here].

==Self-spotting==

More and more contests allow spotting your own station on the DX cluster.

DXLog supports this, even when operating unassisted, as long as you connect to the cluster.

DXLog has three mechanics for self-spotting.

DXLog blocks self spotting unless specifically allowed in the contest rules. 
Should you find that DXLog incorrectly allows or blocks self-spotting, please make 
the development team aware via the support reflector.

* The <tt>$SPOTME</tt> macro command. This macro will create a cluster spot of the station's
: call at the earliest 15 seconds after being invoked the first time on a new frequency.
: Thereafter it will spot as frequent as allowed by the contest. If the contest rules do not
: specify a minimum period, 10 minutes will be used.

* Checking the menu option <code>Tools|Data entry|Run F1 message self-spots when permitted</code>.
: Works exactly like the <tt>$SPOTME</tt> macro command but is triggered by sending the
: Run F1 message which happens when pressing <code>[Enter]</code> with an empty entry line
: in Run, pressing <code>[F1]</code> in Run, or with Auto-CQ.

* Clicking the menu item <code>Commands|Self-spot</code> or pressing its shortcut key <code>[Ctrl][S]</code>.
: This will immediately create a spot of the station's call but no more often than
: every two seconds to avoid accidental multiple spots.

==DXpedition use==

DXLog is a popular choice for top tier dxpeditions. Below we have collected advice based on experience 
on how to best use DXLog in a dxpedition setting.

* Use client/server networking between stations. Never use UDP over Wi-Fi or WAN links.
* Use the "Minimal data" option in ADIF export to save on satellite link cost.
* For Club Log real time upload, use [[https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads Club Log's upload app]]
* Club Log truncate QSO time to minutes so to avoid creating dupes when mixing manual and real time
: upload to Club Log, check "QSO time in minutes" when doing ADIF export.
* Use the "Minimal data" option in ADIF export to save on satellite link cost.
* Follow [[Additional_Information#Interacting_with_WSJT-X|the instructions]] to log QSO made with WSJT-X and MSHV.
* Check <code>Options|Broadcast|Spot WSJT-X decodes</code> to make decoded calls appear in e.g., DX cluster announcements.
* You can extend the number of digits in the QSO count with <code>Options|Log|QSO number digits</code>

==Beacon spots on DX cluster==

Although propagation measurements based on FT8 communications has reduced the 
value of beacons, there are still hundreds of them in operation.

Identifying with CW, they are typically reported on reported on the DX cluster.

When beacon spots are received by DXLog, they are always displayed in the bandmap. 
In DXLog, beacon spots are recognized by having a trailing <tt>/B</tt>.

The DX cluster announcement window never shows or counts beacon spots.

Beacon spots can be enabled and disabled in the cluster node.

For CC Cluster, the commands are <tt>SET/BEACON</tt> and <tt>UNSET/BEACON</tt>.

For DXSpider, command is part of the <tt>SET/SKIMMER</tt> command where <tt>SET/SKIMMER</tt> 
or e.g., <tt>SET/SKIMMER CW BCN FT RTTY</tt> will pass beacon spots and <tt>UNSET/SKIMMER</tt> 
or any <tt>SET/SKIMMER</tt> listing modes but not BCN will block them.

AR 6 cluster nodes always pass beacon spots when skimmer spots are enabled. They cannot be disabled.

Additional Information

2026-03-31T11:10:48Z

Sm7iun: /* Real time upload to Club Log Live Stream */

==Using alternative configurations==

Window positions, coloring and general look and feel is saved in each log file but all other settings such as 
radio control, keying, and networking is saved in a common, contest-independent configuration file.

By default, the configuration file name is <tt>DXLog.net.config</tt> and it is located in the <tt>%appdata%\DXLog.net</tt> configuration folder.

This folder is also reachable via the <code>File|Open configuration folder</code> menu item.

[[image:configfolder.png]]

DXLog can be made to use an alternative configuration file with the command line option <tt>-cfg=<filename></tt>.

A convenient way to use this option is to create a separate Windows desktop shortcut including the command line option 
and give it a meaningful name.

[[image:Desktopshortcut.png]]

The command line option is simply added to the end of the Target text box in the shortcut's properties. 
Double-clicking the icon will start DXLog with the alternative configuration which will also be remembered between sessions. 
In the picture below the target of the shortcut is

[[image:Desktopshortcutconfig.png]]

'''Important:''' If you want to use an alternative configuration, do not just modify the desktop shortcut created at installation 
since this shortcut will be deleted when you upgrade DXLog. Instead make a copy, rename, and add the command line option. 
You should keep the command line option outside the apostrophes, like this

<tt>"C:\Program Files (x86)\DXLog.net\DXLog.net.exe" -cfg=SO2R.config</tt>

==Using a number server==

For contests involving serial numbers you need to secure that the sent number and the (slightly later) 
logged serial numbers are the same. In a straightforward SO1R or SO2V scenario, serial numbers are simply 
chronological but in more complex station configurations such as Multi-single or Multi-2 with inband, and 
advanced SO2R, QSO can be interleaved and requires a central source source of serial numbers together 
with a mechanic to protect an already sent serial number from re-use by another radio.

In DXLog this is achieved with a central number server. A number server can be used either 
by a single instance of DXLog (for SO2R) or by multiple stations on the same LAN.

The use of a number server involves three, natural, steps:

* Activating the server on a single station
* Making sure all stations use it
* Verifying functionality, making sure serial numbers are correctly reserved

The number server is activated in the <code>Options|Configure network</code> panel, described [[Menu_Options#Configure_network|HERE]].

[[image:startnumberserver.png]]

Since the server uses a networking socket, <code>Options|Networking</code> must be enabled '''also''' when 
using a single computer in SO2R. In the case of multiple stations, UDP networking or Client-Server 
networking must also be enabled to transfer the numbers over the LAN. For SO2R, this is however not 
necessary. When using Client-Server networking, a client cannot be number server.

There must only be one number server in a local network and all stations using it must have 
<code>Options|Networking|Use number server</code> checked like in the picture below.

'''Important:''' The number client/server functionality is not very robust. 
If you have stations joining/leaving your network or being rebooted, it is 
best to restart DXLog on all stations to guarantee correct function.

[[image:usenumberserver.png]]

The option <code>Block logging if serial number reservation is unsuccessful</code> can be used as an extra precaution 
but is not necessary in SO2R since the communication with the number server does not leave the computer.

There are three methods for reserving a number from the server:

* Checking <code>Tools|Data entry|Space key reserves serial number</code> and using the space key to reserve serial numbers. This is typically used on phone or when operating "old school" with F-keys.
* Checking <code>Tools|Data entry|Insert and F2 messages reserve serial number</code> and letting DXLog automatically reserve a serial number right before $SERIAL sends it. This is the preferred and most straightforward way for CW and digital.
* Adding the $RESERVENR macro to messages like illustrated below. 

These methods can of course also be combined. 

The $RESERVENR macro is "smart" and will only reserve a serial number if the callsign entry field is not empty and a 
serial number is not already reserved. The same goes for the menu items.

[[image:reservemessages.PNG]]

The sign of a serial number being reserved is that it turns red. It then stays reserved (and red) until the 
QSO is logged or the entry line is cleared with <code>[Alt][W]</code>.

An option that can prove useful is <code>Tools|Data entry|Cancel serial number reservation only if callsign field is empty</code>. 
In the case that you send the exchange and realize you got the other station's callsign call completely wrong, a reflex can be to hit 
<code>[Alt][W]</code> and start typing. If this is your habit, this option will prevent you from releasing the 
already sent serial number, thereby avoiding you the trouble to send a new one to the other station.

[[image:reservednumber.png]]

==Networking over internet==

When, for instance, activating a special event callsign it is possible to network multiple DXLog stations over the internet.

'''Pro tip:''' Consider displaying the callsign, message ID, Message text, etc. fields in the ''Network status'' 
window when operating a distributed station. Also, learn to use the gab <code>[Alt][G]</code> and <code>[Alt][J]</code> function.

===VLAN/VPN Solution===

The most secure way for remote networking is to rely on a VLAN (virtual LAN) software. There are several available such as:

ZeroTier https://www.zerotier.com/ 
FreeLan http://www.freelan.org/ 
Player.me https://player.me/ 
OpenVPN https://openvpn.net/

Each VLAN solutions have their own particular set up which is covered in their respective documentations. 
With a VLAN solution, all DXLog configurations are the same as when operating in a regular LAN however with a few exceptions.

One weakness with connections over the internet (a.k.a. WAN), including VLAN solutions, is that they are prone to packet loss. 
Packet loss is disastrous to DXLog's (or any logger's) "standard" UDP networking.

It is therefore essential to use '''only client/server networking over a VLAN'''. 
'''This also means you should never use interlock over an internet connection unless you use a zero packet loss VPN tunnel.'''

ZeroTier is particularly popular since it is free.

Since DXLog is able to mix TCP (client/server) and UDP (peer-to-peer) networking, a distributed station set up should be configured to rely on TCP 
for the wide-area network and UDP for the local network at each station location. Below you will find the station 
set up for the Swedish HQ station SE9HQ in the 2019 IARU HF Championship. The DXLog.net.DXC cluster client was run 
on SK3W-A which distributed spots to all stations over the network. Inband interlock was also used at the SK3W location.

[[image:SE9HQ-network-eng.png|800px]]

Important to note:

* For the server as well as the main clients, ''Server IP'' should be set to the server's VLAN IP address, '''not''' its LAN address.
* The '''server''' should check both "Act as network server" and "UDP network broadcast for multiple stations".
* The '''main clients''' should check both "Connect to network server" and "UDP network broadcast for multiple stations".
* The '''sub clients''' should check only "UDP networking for multiple stations".
* Interlock (which is UDP-based) over VLAN does not work reliably because of packet loss.
: Therefore, it is important to configure any interlock to '''only''' consider relevant operating positions,
: which all must be local. Use the possibility to only consider named stations for the interlock in the software 
: interlock set up. <code>Options|Networking|Software interlock</code> "Custom station ID(s)"
* For a large set-up with many stations connecting as clients to a central server you may overload the server if you also
: distribute spots via all client-server connections. In this case, check the "No spots via client/server" option
: on all stations and use '''local DX cluster connections''' via UDP at each location.
: '''Important:''' Limitations in Windows networking makes client/server networking unreliable beyond 10 station locations.
* Make sure to check <code>Options->Load contest at startup</code> to avoid opening the wrong log after a restart.
* '''Remote commands are not forwarded''' in the network but are executed in the station where they arrive.
: Thus, to clear all logs, disconnect networking on each main client, execute the remote command CLEARLOGNOW on each main client
: to clear the logs of all sub clients and do not reconnect until the server and all other main clients have done the same.

===Port forwarding Solution===

If you are less worried about competitors or government agencies listening in on your contest data, 
it is possible to route the traffic directly over the internet using port forwarding at the server.

'''Important security notice: This solution is not without risk. It offers no security or authentication. 
Any DXLog station running the same contest configuration, knowing the URL or IP address and IP port of the 
server can connect to the server station. There are no means to disconnect a station by force.'''

Also note the comment about '''remote commands''' in the section above.

With a port forwarding solution, the following must be observed:

* '''Server configuration'''
:* Only one of the stations should be configured as the '''server'''.
:* "Connect to network server" should not be checked on this station and
:: "UDP networking for multiple stations" should only be enabled if it is used to
:: communicate with a cluster client or other stations locally on the same LAN.
:: Either use a central cluster connection (uncheck "No spots via client/server")
:: or use one cluster connection per station location (check "No spots via client/server").
:: If one cluster connection per station location is used, make sure they
:: all use different SSID to prevent disconnects, such as E7HQ-1, E7HQ-2, etc.
:: This will ensure the cluster node regards all connections as having the same callsign
:: which is essential for e.g., correctly receiving own spots.
:* The PC acting as server must be configured for a fixed LAN IP address. This is done
:: either by manually configuring the networking settings in the PC to use a fixed
:: LAN IP address, or by setting up the router in the server's LAN to to always allocate
:: the same IP address to it.
:* The internet connection used by the server PC must ''either'' have a fixed public IP address ''or''
:: use dynamic DNS. Otherwise clients will not be able to reliable connect over the internet.
:* The server's TCP/IP port (e.g., <code>9888</code>) must be forwarded to the server by the server LAN's router.
:: Only TCP traffic should be forwarded. DXLog UDP traffic is not carried well over the internet.

:: [[image:serverconfig.png|600px]]
:: '''Example configuration for server for networking over internet'''

::[[image:portforwarding.png|600px]]
::'''Example of port forwarding UI in router'''

* '''All other stations'''
:* All other PC in the multi-station set up should be set up as clients.
:* Over the internet, "Server:" is either the static, public IP address of the server's internet
:: connection (e.g. <code>5.140.211.42</code>) or the dynamic DNS address (e.g. <code>hq.sm7iun.se</code>).
:: Clients connecting over the internet does not have to enable UDP networking and ''should not''
:: enable a server.
:* A client may connect via UDP if it is on the same LAN as the server ''or'' a "main client".
:: A "main client" is a client that connects to the server using the "Connect to network server" option in
:: the networking set up panel. A "main client" acts as a UDP gateway which means that if
:: several computers on a LAN are part of the same multi station set up but the server is located
:: elsewhere, only one computer in that LAN needs to connect as a client and the rest can use UDP.
:* Software interlock is UDP-based and can only reliably be used locally. Never over the internet.
:: If used, make sure the interlock is explicitly limited to local stations. See above for more details.

::[[image:clientconfig.png|600px]]
::'''Example configuration of client for networking over internet'''

* In a multi-station setting it is recommended to enable
: <code>Options|Networking|Block standard messages if no operator is logged on</code>
* Make sure <code>Options|Enable network</code> is checked.
* It is also a very good idea to check <code>Options|Load contest at startup</code> to reduce the
: risk of the wrong contest log file being loaded by any stations.

==Real time upload to Club Log Live Stream==

'''Important:''' Club Log truncates QSO time to minutes which means that if you mix real time upload 
with manual upload, make sure to check "QSO time in minutes" when creating ADIF export files.

The author of Club Log, Michael Wall, G7VJR, has developed a very powerful agent for real time uploads. 
It works with all the three major loggers, DXLog, N1MM Logger+, and Win-Test.

It can either be used as is, with a command line user interface, or with an optional user interface front end.

Information on how to download and configure it can be found [[https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads HERE]]

The Club Log Gateway can either listen to DXLog's native multi-station networking protocol or to N1MM style XML broadcast.

To use DXLog's networking protocol, make sure the same port (default 9888) is used in the gateway and DXLog 
and that UDP networking is enabled in DXLog. Do not enable QSO broadcast.

Although this works, it is recommended to use N1MM style broadcast since it contains information like logged on operator, etc.

To use this make sure the port (default 12060) is the same in N1MM port setting in the gateway and in the 
QSO broadcast port settings in DXLog's network configuration. Also make sure to se the DXLog port number 
in the gateway is not the same as that used in DXLog to avoid QSO duplication.

Also set:

<code>Options|Broadcast|QSOs</code> 
<code>Options|Broadcast|QSOs</code> 
<code>Options|Broadcast|Use N1MM QSO format</code> 
<code>Options|Broadcast|QSO time in minutes only</code>

'''Important:''' If you are going to also upload exported ADIF files to Club Log, it is important to also 
check "QSO time in minutes" in the ADIF export configuration to avoid creating virtual dupes, since Club 
Log does not know seconds.

==Diversity reception==

Diversity means receiving the same signal through two different receive chains, including antenna. 
With two antennas having different characteristics this can give substantial benefits in receiving 
fading and/or weak signals or separating calls in a large pile-up. Particularly on low bands.

DXLog supports diversity operation on a selected number of radio models.

For the supported radios, diversity operation can be toggled on and off using <code>[Ctrl][-]</code> or <code>[Ctrl][Keypad -]</code>.

If enabled via the radio's controls, DXLog will automatically detect diversity operation and enable 
the necessary mechanics. Diversity operation is indicated by a small DIV icon in the frequency 
counter box for the radio's band map.

'''Yaesu FTDX101D

Yaesu calls this feature "Sync" and it has a dedicated button up and left of the main VFO knob. 
Enabling this will make DXLog update both VFO with the same information when grabbing spots. 
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO. 
Since both VFO are kept on the same frequency, split operation is not supported.

'''ICOM IC-7851 and IC-7610

ICOM calls this feature "Tracking" and it can be enabled either via a menu entry or a long press on the "MAIN/SUB" button. 
Enabling this will make DXLog update both VFO with the same information when grabbing spots. 
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO. 
Since both VFO are kept on the same frequency, split operation is not supported.

'''Elecraft K3/K3S/K4

Elecraft calls this feature by its proper name. It is enabled by a long press on the "Sub" button. 
It should be noted that Elecraft's implementation where the main VFO controls both the main and 
sub receivers allows for split operation, i.e. transmitting on a different frequency using VFO B.

==UDP broadcast==

For interaction with other applications, DXLog can broadcast useful information as 
XML datagrams over UDP. 

There are five types of broadcast messages produced by DXLog:

* QSO information. Sent when logging.
* Radio information. Sent at changes as well as periodically.
* Antenna direction information. Sent when rotor control is invoked.
* Callsign look-up information
* Spots

QSO can be broadcasted in traditional DXLog format or in a more N1MM-like format.

Radio information can report SO2V as a single physical radio or as two physical radios, like N1MM.

There is an option to truncate the broadcasted QSO time to full minutes for better 
interoperability with some online services and software such as MSHV.

In addition, DXLog can also recognize QSY commands from Waterfall Bandmap and log QSO done as well as create 
local spots from decodes broadcasted by WSJT-X and its forks.

The broadcasting of QSO and radio related data is enabled using the <code>Options|Broadcast</code> submenu.

The broadcasting of spots is enabled by checking <code>Options|DX Cluster|Send spots to SmartSDR</code>.

[[image:radiobroadcastenable3.png]]

[[image:sendspotstosmartsdr.png]]

UDP broadcast parameters are configured in the <code>Options|Network configuration</code> panel. 
Please note that up to three ports can be specified for each broadcast, thereby supporting 
multiple receivers of the information.

[[image:Networksettingsbroadcast3.png]]

If you are writing a C# application to make use of these datagrams, there is a very nice online tool 
for creating an object from a sample XML datagram here https://xmltocsharp.azurewebsites.net/ 

In C# parsing is easily done using Linq. One example of XML parsing and deserialization using Linq 
can be found here https://github.com/bjornekelund/ICOMautomagic

===QSO information===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program
|-
| qsoid
| A unique string for this QSO. If this QSO is edited another contactinfo message will be sent with the same qsoid. Note that the qsoid is only unique within one instance of DXLog. If the computer is networked to others running DXLog the different computers may have a different qsoid for the same QSO.
|-
| contestname
| The name of the contest as it would be written to a Cabrillo file.
|-
| timestamp
| The UTC date and time of the QSO.
|-
| mycall
| The callsign of this station.
|-
| band
| The band on which the QSO was made. In MHz with period as decimal separator.
|-
| txfreq
| The frequency on which the QSO was made.
|-
| operator
| The callsign of the operator if the OPON command was used to set it, otherwise blank.
|-
| mode
| The mode used for the QSO.
|-
| call
| The callsign of the station worked.
|-
| countryprefix
| The DXCC country of the station worked.
|-
| wpxprefix
| The WPX prefix of the station worked.
|-
| snt
| The RST sent. This is always included whether or not the contest exchange contains an RST.
|-
| rcv
| The RST received. This is always included whether or not the contest exchange contains an RST.
|-
| nr
| The number sent if the exchange uses a serial number, otherwise the QSO number from this station.
|-
| exch1
| The first element in the contest exchange if any.
|-
| exch2
| The second element in the contest exchange if any.
|-
| exch3
| The third element in the contest exchange if any.
|-
| exch4
| The fourth element in the contest exchange if any.
|-
| xqso
| True if this QSO should not be counted towards the score.
|-
| invalid
| True if this QSO is invalid, for example a DX QSO in a domestic contest.
|-
| duplicate
| True if this QSO is a dupe (the station has previously been worked).
|-
| rule10broken
| True if this QSO breaks the 10 minute or similar rule. Note that a QSO may not break the 10 minute rule when it is logged but may later if another QSO is edited. This may not cause a broadcast.
|-
| azimuth
| The approximate direction of the station worked, in degrees.
|-
| distance
| The approximate distance of the station worked, in kilometers.
|-
| stationid
| The station ID of the station which made the QSO.
|-
| stationqso
| A unique QSO ID generated by the logging station. The combination of stationid and stationqso forms a unique identifier for the QSO.
|-
| stationtype
| The type of station - R for run, R1 for run 1 etc.
|-
| local
| True if this broadcast is due to this QSO being logged or edited on this computer.
|-
| runqso
| True if QSO logged in Run, false if S&P, and empty if unknown. '''Important:''' Only valid when local is True.
|-
| mult1
| The name of the multiplier if this station is a new multipllier, empty otherwise.
|-
| mult2
| The name of the multiplier if this station is a new multiplier, emtpy otherwise.
|-
| mult3
| The name of the multiplier if this station is a new multiplier, empty otherwise.
|-
| points
| The logged points for the QSO.
|-
| period
| The number of the operating period.
|-
| guid
| The GUID in hex format.
|-
| newqso
| True if a new QSO, False if this message is an update to an existing QSO.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<contactinfo>
<logger>DXLog v2.4.13</logger>
<qsoid>19</qsoid>
<contestname>ARRL-SS-CW</contestname>
<timestamp>2020-01-13 18:28:07</timestamp>
<mycall>SM7IUN</mycall>
<band>3.5</band>
<txfreq>352376</txfreq>
<operator></operator>
<mode>CW</mode>
<call>K4BAI</call>
<countryprefix>K</countryprefix>
<wpxprefix>K4</wpxprefix>
<snt>599</snt>
<rcv>599</rcv>
<nr>19</nr>
<exch1>076</exch1>
<exch2>B</exch2>
<exch3>54</exch3>
<exch4>GA</exch4>
<xqso>False</xqso>
<invalid>False</invalid>
<duplicate>False</duplicate>
<rule10broken>False</rule10broken>
<azimuth>225</azimuth>
<distance>1388</distance>
<stationid>STN1</stationid>
<stationqso>19</stationqso>
<stationtype>R1</stationtype>
<local>True</local>
<runqso>True</local>
<mult1>GA</mult1>
<mult2></mult2>
<mult3></mult3>
<points>3</points>
<period>1</period>
<guid>11223344556677889900aabbccddeeff</newqso>
<newqso>True</newqso>
</contactinfo>
</pre>

Alternative N1MM format

Note that the band name uses the computer's local number format so it may use either comma 
or period as decimal separator. The ID is a number rather than an alphanumeric string.

Also note that IsRunQSO is only valid when IsOriginal is True.

<pre><?xml version="1.0" encoding="utf-8"?>
<contactinfo>
<app>N1MM</app>
<contestname>CWOps</contestname>
<timestamp>2020-01-17 16:43:38</timestamp>
<mycall>SM7IUN</mycall>
<band>3.5</band>
<rxfreq>352519</rxfreq>
<txfreq>352519</txfreq>
<operator></operator>
<mode>CW</mode>
<call>K1XM</call>
<countryprefix>K</countryprefix>
<wpxprefix>K1</wpxprefix>
<stationprefix>K1XM</stationprefix>
<continent>NA</continent>
<snt>599</snt>
<sntnr>5</sntnr>
<rcv>599</rcv>
<misctext></misctext>
<ismultiplier1>1</ismultiplier1>
<ismultiplier2>0</ismultiplier2>
<ismultiplier3>0</ismultiplier3>
<points>l</points>
<radionr>l</radionr>
<run1run2>1<run1run2>
<IsOriginal>False</IsOriginal>
<NetBiosName>DESKTOP-23AB</NetBiosName>
<IsRunQSO>0</IsRunQSO>
<StationName>STATION_B</StationName>
<ID>23</ID>
<IsClaimedQso>true</IsClaimedQso>
</contactinfo>
</pre>

===Radio information===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| The name of the logging program.
|-
| logger
| The name and version of the logging program.
|-
| Station
| The ID of the station.
|-
| RadioNr
| The radio being described.
|-
| Freq
| The receiving frequency.
|-
| TXFreq
| The transmitting frequency
|-
| InactiveFreq
| The frequency of the VFO not receiving.
|-
| Mode
| The reported radio's mode.
|-
| OpCall
| The callsign of the operator if the OPON command was used to set it, otherwise blank.
|-
| mycall
| The callsign of the station.
|-
| IsRunning
| "True" if the station is running, "False" if search and pounce.
|-
| FocusEntry
| The Windows handle for the focused entry window.
|-
| Antenna
| Antenna number.
|-
| Rotors
| Rotators used by selected antenna (not currently used by DXLog).
|-
| FocusRadioNr
| The radio which has keyboard focus. In SO2V with "Report SO2V as two radios" checked, radio 2 is the sub/B VFO.
|-
| IsStereo
| True if headphones are listening to two radios.
|-
| IsSplit
| True if radio is set to split.
|-
| ActiveRadioNr
| The radio which is transmitting, if any.
|-
| Technique
| SO1R, SO2R, SO2R_ADV, or SO2V
|-
| StationType
| Station role: R, M, R1, R2, or R+.
|-
| isTransmitting
| True if a DXLog is transmitting. False if DXLog is not aware of transmission.
|-
| IFFrequency
| Optional element only used with Elecraft K3/K4. Contains the current IF frequency in Hz.
|-
|}

Important note: In SO2V the format differs from some other loggers and is:

: Only physical radio 1 is reported.
: <tt>Freq</tt> and <tt>TXFreq</tt> are the frequency of the currently focused VFO.
: <tt>InactiveFreq</tt> is the frequency of the currently unfocused VFO.
: <tt>ActiveRadio</tt> is always 1.
: <tt>FocusedRadioNr</tt> is 1 when the main/A VFO is focused, 2 otherwise.
: <tt>IsSplit</tt> is always false.

With the option "Report SO2V as two radios" checked, the reporting is similar to some other loggers and is:

: The two VFO are reported as two physical radios.
: <tt>Freq</tt> and <tt>TXFreq</tt> for radio 1 are the frequency of the main/A VFO.
: <tt>Freq</tt> and <tt>TXFreq</tt> for radio 2 are the frequency of the sub/B VFO.
: <tt>InactiveFreq</tt> is the frequency of the other VFO.
: <tt>ActiveRadio</tt> and <tt>FocusedRadioNr</tt> are 1 when the main/A VFO is focused, 2 otherwise.
: <tt>IsSplit</tt> is always false.

Example message:

<pre><?xml version = "1.0"?>
<RadioInfo>
<app>DXLog</app>
<logger>DXLog v2.4.13</logger>
<Station>STN1</Station>
<RadioNr>1</RadioNr>
<Freq>704000</Freq>
<TXFreq>704000</TXFreq>
<InactiveFreq>702500</InactiveFreq>
<Mode>CW</Mode>
<OpCall>K1XM</OpCall>
<mycall>HQ9X</mycall>
<IsRunning>False</IsRunning>
<FocusEntry>591124</FocusEntry>
<Antenna>1</Antenna>
<Rotors>ABC</Rotors>
<FocusRadioNr>1</FocusRadioNr>
<IsStereo>False</IsStereo>
<IsSplit>False</IsSplit>
<ActiveRadioNr>1</ActiveRadioNr>
<Technique>SO2R</Technique>
<StationType>R1</StationType>
<IsTransmitting>False</IsTransmitting>
<IFFrequency>8215000</IFFrequency>
</RadioInfo>
</pre>

===Antenna direction===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program.
|-
| station
| The ID of the station.
|-
| radio
| The radio associated with the rotator.
|-
| go
| True if the rotator should be turned.
|-
| stop
| True if the rotator should be stopped if it is turning.
|-
| azimuth
| The direction to turn the rotator if go is True.
|-
| frequency
| The transmit frequency of the specified radio.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<Rotator>
<logger>DXLog v2.4.13</logger>
<station>STN1</station>
<radio>2</radio>
<go>True</go>
<azimuth>252</azimuth>
<frequency>2800200</frequency>
</Rotator>

</pre>
<pre><?xml version="1.0" encoding="utf-8"?>
<Rotator>
<logger>DXLog v2.4.13</logger>
<station>STN1</station>
<radio>2</radio>
<stop>True</stop>
<frequency>2800200</frequency>
</Rotator>
</pre>

===Callsign lookup===

Sent either when callsign in entry row is changed or when space or tab is pressed.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program.
|-
| contestname
| The name of the contest.
|-
| mycall
| Station's call
|-
| band
| Current band
|-
| txfreq
| Transmitter frequency
|-
| operator
| The call sign of the logged in operator
|-
| mode
| Operating mode
|-
| call
| Call entered in the logging field
|-
| countryprefix
| DXCC entity prefix
|-
| wpxprefix
| WPX prefix
|-
| azimuth
| Short path antenna direction
|-
| distance
| Distance in km
|-
| stationid
| The ID of the station sending the datagram
|-
| stationtype
| The role of the station sending the datagram; R, R1, R2, M, or R+
|-
| period
| Contest period
|-
| reason
| Reason for transmission; SpaceOrTab or CallChanged
|-
|}

Example message:

<pre><?xml version = "1.0"?>
<lookupinfo>
<logger>DXLog v2.4.20</logger>
<contestname>DARC-WAEDC-CW</contestname>
<mycall>K1XM</mycall>
<band>20</band>
<txfreq>1400200</txfreq>
<operator></operator>
<mode>CW</mode>
<call>E7DX</call>
<countryprefix>E7</countryprefix>
<wpxprefix>E7</wpxprefix>
<azimuth>54</azimuth>
<distance>6824</distance>
<stationid></stationid>
<stationtype>R</stationtype>
<period>1</period>
<reason>SpaceOrTab</reason>
</lookupinfo>
</pre>

===Spot===

Sent for every incoming spot from the DX cluster that is valid for the current contest.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| Application sending the message.
|-
| StationName
| The station issuing the broadcast.
|-
| dxcall
| The callsign of the spotted station.
|-
| frequency
| Frequency in kHz with decimal sign of the PC's current locale. (sic)
|-
| spottercall
| The callsign of the spotter. Station name if locally spotted or result of a logging operation.
|-
| timestamp
| Spot time in format yyyy-MM-dd HH:mm:ss
|-
| action
| add or delete.
|-
| mode
| actual or guessed mode of the spot in capitals.
|-
| comment
| The comment section of the spot.
|-
| status
| Spot status. Valid values are "dupe", "double mult", "single mult", and "new qso".
|-
| statuslist
| Same as status
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<spot>
<app>DXLog.net</app>
<StationName>CONTEST-PC</StationName>
<dxcall>E7DX</dxcall>
<frequency>14022.3</frequency>
<spottercall>SM7IUN-#</spottercall>
<timestamp>2O23-07-15 14:29:37</timestamp>
<action>add</action>
<mode>CW</mode>
<comment>CW 31 DB 42 WPM CQ</comment>
<status>single mult</status>
<statuslist>single mult</statuslist>
</spot></pre>

===Broadcast listener===

DXLog also listens for commands over UDP.

Currently only one command is implemented, <code><radio_setfrequency></code>, which is a QSY command.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| Application sending the command
|-
| radionr
| The radio to be changed. In SO2V radio 2 means VFO B. Optional as of DXLog 2.5.20.
|-
| frequency
| Requested frequency. Both period and comma is accepted as decimal separator.
|-
| mousebutton
| Which mouse button was used to create message, if any. Optional.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<radio_setfrequency>
<app>WaterfallBandmap</app>
<radionr>1</radionr>
<frequency>21022.194</frequency>
<mousebutton>Left</mousebutton>
</radio_setfrequency>
</pre>

==SDR integration==

===HDSDR, OmniRig, and microHAM===

''Contributed by Ingo SM5AJV/SE5E''

Until DXLog offers SDR integration there are still ways to get a waterfall/spectrum display with DXLog.

I have integrated the free SDR software [http://www.hdsdr.de/ HDSDR] with DXLog using
[http://www.microham.com Microham Device Router], 
[http://dxatlas.com/OmniRig/ OmniRig]
and [https://www.autohotkey.com/ AutoHotkey].

As illustrated below I place the HDSDR window at the very top of the desktop with DXLog right below.

I share my transceiver's (an Elecraft K3) antenna with the SDR. The receiver antenna signal from my 
K3's RX-ANT OUT is connected to the input of a 3dB power splitter. The two outputs from the splitter 
are connected RX-ANT IN on the K3 and the SDR Receiver antenna input, respectively. On a K3 you 
need to enable the RX-antenna input to make this to work. An additional benefit with this method 
is that the SDR is protected during transmission. It is a widely used method and is e.g. described 
by Bob N6TV in this
[http://dxlog.net/sw/files/utilities/Adding%20an%20SDR%20to%20an%20SO2R%20Station.pdf presentation].

'''Screenshot of my desktop:

[[Image:Sdrdesktop.png|800px]]

Since both DXLog and HDSDR need to communicate with the radio, you need to "split" 
the CAT communication. microHAM's USB Device Router provides a second, independent, 
CAT port that can be used via HDSDR's omniRig interface.

'''"PORT" Tab on microHamRouter:

[[Image:Sdrmicrohamrouter.png|800px]]

'''OmniRig settings in HDSDR:

[[Image:Sdromnirig.png|200px]]

With this set up, the radio, DxLog, and HDSDR will be fully synchronized. For instance, you can 
click in the waterfall to make the radio QSY, and it is easy to quickly find a clean frequency.

To make the integration even better I use a small AutoHotkey script. The script pulls entry focus 
back to DxLog after clicking on the HDSDR waterfall and in DXLog it allows you to use hotkeys to 
control HDSDR. <code>[Ctrl][Alt]+</code> and <code>[Ctrl][Alt]-</code> zooms the waterfall/spectrum 
in and out, and <code>[Ctrl][Alt]C</code> centers it.

'''AutoHotkey script:

SetTitleMatchMode, 2
#InstallKeybdHook
#IfWinActive, HDSDR
{
F4:: return ; disable F4
~LButton Up::
sleep, 1
Winactivate, DXLog
return
}
#IfWinActive, DXLog
{
^!+:: ControlSend ,, ^{+}, HDSDR
^!-:: ControlSend ,, ^{-}, HDSDR
^!c:: ControlSend ,, {c}, HDSDR
}

The script can be downloaded [http://DXLog/sw/files/utilities/dxlog_hdsr.ahk here].

If you start two instances of HDSDR with two different SDR you can even have two waterfalls 
running at the same time.

I have not yet found a way to display cluster spots in the HDSDR spectrum panel. 
But I still find it very useful to check band activity and it allows me to easily find 
a new Run frequency on a crowded band.

===Waterfall Bandmap===

The free waterfall/spot display utility "Waterfall Bandmap" by Steve N2IC is supported by DXLog.

Waterfall Bandmap supports almost any SDR that produce I/Q output either via ExtIO.DLL or a 
sound card; SDRPlay, FunCubeProPlus, HackRF, SDR-IQ, RTLSDR, SoftRock, etc.

A zip file with an executable binary and a Microsoft word document with installation and 
configuration instructions can be found here: https://groups.io/g/waterfallbandmap/files

If you are not a member of the support forum group, you need to apply for membership to download. 
Membership is free.

[[Image:Waterfallbandmap.png]]

The SDR can be connected either to a separate receive antenna, an external receiver output on 
your transceiver or to an IF output, should your transceiver have one. If connected to an antenna, 
keep in mind that you may need protection from the transmitter such as a T/R relay or a passive level limiter.

Please refer to Waterfall Bandmap's documentation for setting it up with your SDR.

Waterfall Bandmap needs two information feeds over UDP: Radio information and spot information. 
Both are provided as UDP broadcast by DXLog.

The default port for both is 13063 and this needs to be set in DXLog's Network configuration panel. 
If Waterfall Bandmap runs on the same computer as DXLog, the broadcast address can be left at the default 127.0.0.1.

[[Image:Setbroadcastportsforwfbandmap.png]]

Clicking on the waterfall display can set the frequency of DXLog. (Left click sets VFO A, right click sets VFO B.) 
To enable this functionality, check the option <code>Options|Broadcast|Receive Broadcasts</code> 
Also make sure "UDP broadcast listener" includes port 13064 in the network settings panel.

The radio information feed needs to be enabled by checking the <code>Options|Broadcast|Radio information</code> option

[[Image:radiobroadcastenable2.png]]

and the spot feed needs to be enabled by checking the <code>Options|DX Cluster|Send spots to SmartSDR</code> option.

[[Image:Enablesendspotstosmartsdr.png]]

==Time synchronization==

In a multi-station setting, the time needs to be accurately synchronized across all networked PC.

Windows' built in time synchronization is very crude and for a PC with poor clock stability the 
inaccuracy of the clock may be up to a minute. Which of course is not acceptable for contesting.

DXLog has built in support for time synchronization as described in the [[Menu Options#Configure network|Configure network section]].

Due to Windows' security system, this however requires all except the PC running as time server to 
run DXLog with elevated permissions. There is unfortunately no way around this inconvenience.

An equally accurate and less intrusive method is to use a standalone time synchronization application on each networked PC. 
This will keep each PC's clock accurate within a fraction of a second.

Contrary to a solution built into a logger it also has the great benefit of being an "install and forget" solution.

A popular application is Dimension 4 by Thinking Man Software. It is free for personal use and 
can be downloaded here: https://dxlog.net/sw/files/utilities/d4time531.msi

It runs in the background and only shows up as a tiny icon in your system tray. 
You hover the mouse above the icon to check status and right-click to open and change settings.

:::[[image:dimension4tray.png|50px]]

After installation a brief configuration is required.

First of all, allow the application to disable Windows' time service and to modify your system clock.

For maximum accuracy, select a time server geographically close to your location. 
When in doubt, you can always add the global server "pool.ntp.org" to the list and use that. 

There are also national and continental pools of time servers. You can find them here https://www.ntppool.org.

[[image:dimension4b.png]]

Make sure the check boxes "Load Dimension 4 at startup", "Start minimized", "Hide when minimized", 
and "Display icon in tray" are all checked.

[[image:dimension4advanced.png]]

Click the Advanced button and also make sure the option "Use the selected server" is selected.

Make sure the application reports a successful connection to the selected time server. 
From here on, you can basically forget the application. 
It will silently start with your PC and always keep its time accurate.

==Disabling USB power management==

In the interest of saving energy, Windows habitually power down USB interfaces 
when it believes there is inactivity. Some USB-to-serial and USB audio devices 
respond poorly to being suspended or powered down so as a rule this "feature" should 
be disabled when used in a ham radio environment.

There are two places where this functionality needs to be disabled; the device driver 
and Windows' energy management.

To disable it for each USB interface and device, open Windows settings. (Click the Windows 
icon in the lower left corner and then chose the cogwheel.) Type ''device manager'' and
select the result.

[[image:devicemanager-c.png|none|frame]]

This opens up a new window, Windows' Device Manager.

[[image:devicemanager2b.png|none|frame]]

For '''every''' USB interface component (there may be many), COM-port, and audio device, 
and '''uncheck''' the option ''Allow the computer to turn this device off to save power''.

The devices you are looking for are in the categories: ''Ports (COM & LPT)'', 
''Sound, video and game controllers'', ''Universal serial bus controllers'',

Note that some devices may not have a ''Power Management'' tab.

[[image:usbdevicemanager.png|none|frame]]

The next step is to disable Windows ''Selective suspend'' feature for USB interfaces.

Go back to Windows Settings and type ''edit power'', click the appearing ''Edit power plan'' menu entry.

[[image:editpowerplan2.png|none|frame]]

This should open the window below, the plan editing panel.

[[image:editplansettings.png|none|frame]]

Click ''Change advanced power settings''. Scroll down to ''USB settings'' and make 
sure ''USB selective suspend setting'' is '''disabled''' for all situations.

[[image:Advancedsettings.png|none|frame]]

To prevent audio devices from becoming unreachable or going into sleep mode you should also 
disable exclusive access. While changing this, also make sure all audio enhancements are disabled.

You reach the detailed audio device settings by entering Windows settings, search for Control panel, 
and in the Control panel view, select Hardware and audio, and then Sound.

[[image:Audiodevice.png]]

Reboot your computer to make sure all settings are recognized by Windows.

==Interlock and inband operation==

In contest station terminology, the term ''Interlock'' refers to a technical solution preventing 
more than one station from using a shared resource, typically an antenna, at the same time.

The most common use for interlock is for inband operation. Inband operation means to have multiple 
transmitters on a single band, interleaving their transmissions. Sometimes on a split-second basis.

As long as you never have more than one transmitter active at any time, the majority of contests allow 
an unlimited number of transmitters and receivers on a single band for multi-operator categories. 
This fact is used by most big contest stations.

For an inband solution to be effective, each station must be able to receive while the 
other station transmits. This means it requires a separate, high performance receive antenna 
with very good isolation from the transmitter antenna. The most common way to 
achieve this is physical separation and geographic orientation to minimize the situations 
when they will radiate/listen in the direction of the other antenna.

For a station operating in the M/M, M/S, or M/2 category, inband operation can boost the points 
per hour performance significantly. It is also a lot more fun.

However, as with everything else, it comes at a cost. An efficient inband solution has:

* A high performance receive antenna for each operated band(s) with very good isolation from the transmitter antenna.
* A fail-safe antenna switching hardware.
* Interlock-capable keyers and/or station controllers.
* An interlock-capable contest logging software

A typical inband configuration can be seen in the illustration below.

[[image:inbandconcept-trx.jpg|800px]]

DXLog offers a software-based interlock which can be configured in a variety of ways, e.g. based on frequency 
band, operating mode, or station role. It supports an unlimited number of stations interlocking each other 
using a great variety of strategies.

The interlock relies on UDP networking and is overlaid on the communication for multi-station logging. 
UDP networking has the benefit of speed and low latency but is, unlike TCP, susceptible to packet loss. 
This means that a '''wired LAN''' is a necessity for any station using interlock. 
For the same reason, it is also not recommended to run interlock over e.g. VLAN/VPN link for 
geographically distributed stations.

A software interlock is not 100% reliable. Computer or software malfunction, networking issues such as packet 
loss, etc. can cause interlock to fail, even if only momentarily.

For this reason it is necessary to also accompany a software interlock with a fail-safe '''hardware''' interlock. 
Without hardware supported interlock you run the risk of not only violating contest rules but also cause serious equipment damage. 
Some contests, such as CQ WW, explicitly requires hardware interlock when using multiple stations on the same band.

There are many designs and even commercial products available for hardware interlock. 
One example of a simple but effective two station hardware interlock which also supports 
power amplifier sharing can be found [https://sm7iun.se/contest/inband/ HERE].

The purpose of this section is to describe steps of setting up a basic two station in-band solution with 
DXLog and microHAM keyers. The microHAM keyers are not mandatory but offers a much better user experience 
and removes the need for additional hardware.

'''Pro tip:''' Consider checking <code>Options|Networking|Allow other stations to abort sending</code> 
which will allow your partner station to interrupt your transmission with <code>[Shift][Esc]</code> in 
critical situations. Be careful though, the use of this function requires good judgment to avoid violence.

===Networking===

Open the networking configuration panel with <code>Options|Configure network</code> and make sure each 
station has a unique name and that only UDP networking is enabled.

Make sure the two stations use the same broadcast IP address and that it is in line with your LAN's 
configuration. Pressing the <tt>Default</tt> button is a good way to ensure this.

Make sure the menu option <code>Options|Enable network</code> has a checkmark.

[[image:inbandnetworkrun.png|left|frame]][[image:inbandnetworkinband.png|none|frame]] 

===DXLog Interlock configuration===

First of all, make sure that the <code>Options|Interface specific options|Prevent TX if another radio is on same band</code> 
is '''not''' enabled. This option completely prevents transmission if more than one networked station is set to the same band 
and the whole idea with inband is to have exactly that.

Next, activate software interlock on both stations using the menu option <code>Options|Networking|Software interlock</code> 
or by typing the commmand <tt>ILOCKON</tt>.

[[image:inbandinterlock2.png|none|frame]]

There are multiple options for configuring the interlock. In a simple set up with only two stations, the topmost 
option ''Same band from status list'' is a good choice. This option will prevent more than one station transmitting 
on the same band, regardless of mode.

In an environment with many stations (such as a multi-operator-multi-transmitter station) it is 
recommended to use the bottom option to only interlock with one or several named stations. 
This will reduce both LAN traffic and inband operation latency. This is particularly important when 
running parts of the DXLog network over high latency links such as VLAN/VPN or if some stations (albeit not 
part of the interlock cluster) are connected via Wi-Fi.

For more advanced scenarios you can also use interlock based on mode or station type (e.g. Run 1, Run 2, Mult, etc.).

The "status list" listing the networked DXLog stations is displayed in the ''Status Window'' which is opened 
with <code>Windows|Status window</code> or <code>[Alt][J]</code>.

[[image:inbandstatuslist2.png]]

DXLog also offers great flexibility when it comes to interlock strategy. The most straightforward and 
most commonly used is ''First one wins''. This is also typically the behavior of "unintelligent" 
hardware solutions when not assisted by software. With this strategy, the station starting to transmit 
first can not be interrupted and always gets to finish its transmission.

[[image:inbandinterlockoptions.png]]

With a ''Last one wins'' strategy, the transmitting station can be interrupted. A carte blanche permission 
to interrupt all transmissions by the other station may however be counterproductive in a real contest situation.

For this reason, DXLog offers additional control of which transmit actions can be interrupted and which can not. 
This is a powerful tool but requires both operators to be aware of it and may require 
practice before fully effective.

[[image:inbandstrategyexceptions.png]]

''F1'' through ''F7'', ''PLUS'' and ''INS'' refers to DXLog's standard messages. ''KEYB'' means a free text transmission 
from the keyboard using the <code>[Alt][K]</code> function and ''MAN'' means manual transmission using either paddle 
break-in or a footswitch.

For CW, DXLog recognizes paddle break in from a K1EL Winkey-compatible keyer as described in the [[Menu_Options#Winkey_Configuration|Winkey configuration section]].

Since DXLog recognizes a footswitch connected to a microHAM device, this is a recommended approach for phone. 
It is also possible to connect a footswitch to the DSR pin (pin 6) on a physical COM-port on the PC, but today 
few PC have such a port and it also requires additional circuitry.
Details on how to do this is available [[Additional_Information#Connecting_a_footswitch|HERE]].

===microHAM configuration===

Open the microHAM device configuration panel with <code>Options|microHAM device configuration</code>.

[[image:Mk2r-new9.png|none|frame]]

Check the option ''Enable TX lock/unlock''. This will do two things; it will enable DXLog to prevent 
transmission and and it will make DXLog aware of the microHAM device's PTT status. The latter is particularly 
important since it means DXLog will recognize PTT assertion not only by a footswitch connected to the 
microHAM device but also by the built-in Winkeyer (requires microHAM USB Device Router version 9.3.0 or later) 
'''Paddle-based break-in in an inband solution is currently unique for microHAM with DXLog.'''

'''Important:''' Making DXLog "PTT aware" means that care has to be taken in how PTT is set up. If you, for instance, 
enable DXLog PTT for the voice keyer, this will create a self-reinforcing feedback loop and PTT will thus never drop.

Check the option ''Dual radio device'' if you are using a u2R, MK2R, or MK2R+, otherwise, leave this unchecked.

Check the option ''Device without CAT interface'' if the device lacks a CAT interface (like the u2R) 
or if its CAT interface is not connected to the radio. This option will make sure the e.g. keying and 
audio routing is always set correctly in line with the operating mode (Voice, CW, or RTTY).

===Operating===

Inband operation requires a fair amount of training and it is a good idea to define and agree 
on general rules for operation, such as hand signals for challenging QSO, beforehand.

There are more than enough YouTube videos of inband operators yelling at each other.

The operating tactics may have to be adjusted during the contest. If Run is slow, 
doing S&P on the inband station can increase the points per minute significantly. 
However, if Run is strong, an overly active inband operator doing S&P, but not working 
multipliers, may actually reduce the station's points per minute significantly.

Real-time interlock status is shown in the ''Radio status'' window, which is opened with 
<code>Windows|Radio status</code>.

[[image:inbandblocking.png]] [[image:inbandblocked.png]]

For Phone contesting, you typically rely on footswitches for PTT and the option 
<code>Options|Networking|Show QSO status when blocking</code> makes the blocking 
station send a more helpful blocking cause than ''MAN''.

With this option enabled, the blocking station will instead send ''CQ'', ''QSO'', or ''EXCHANGE'' 
as blocking cause, determined by cursor location and entry field content at the locking station.

Further reading can be found in the [[Menu_Options#microHAM_device_configuration|microHAM device configuration]] and [[Menu_Options#Networking|Networking]] sections.

==Connecting a footswitch==

To free up both hands in Phone contesting, a footswitch PTT is a great help.

Also, to use interlock in Phone contesting, a footswitch is mandatory.

There are two basic ways to interface a footswitch with DXLog; via a microHAM device (which is the recommended solution) 
or directly connected to a physical serial port on the PC (which very few PC have today).

The connection of a footswitch to a microHAM device is very straightforward and by checking the ''Enable TX lock/unlock'' 
in the ''microHAM device configuration'' panel, it is recognized by DXLog.

Lacking a microHAM device, it is also possible to use the computer's DB9 RS-232 serial port connector, providing it has one.

The required steps to do this are:
* Connect a 10k resistor between DB9 pin 6 and pin 7.
* In the port's settings (<code>Options|Configure interfaces</code>) set DTR (pin 4) to ''Always On'' and RTS (pin 7) to ''Always Off'' for the port.
* Connect the footswitch between DB9 pins 4 and pin 6. '''Important:''' Neither pole on the footswitch must be connected to ground.
* In the radio's configuration panel, check ''use CAT PTT command on Phone'' and set ''Footswitch (pin 6)'' to ''PTT''

==Support for CC Cluster==

CC Cluster is today the main choice for contest use.

It offers a high quality, database-verified, flow of skimmer spots and a rapid 3-minute respotting period for skimmer spots.

It also publishes unique spots from less common locations which are valuable for DX chasers or as contest multipliers.

To make use of the display of own spot in the world map, make sure to issue the command '''<tt>SET/OWN</tt>''' to the cluster node. 
This setting is persistent and only needs to be done once.

A list of cluster nodes that runs CC Cluster can be found here: [https://www.dxcluster.info/telnet/index.php?software=CC%20Cluster CC Cluster nodes]

A description of the command line syntax can be found here: [http://bcdxc.org/ve7cc/ccc/CCC_Commands.htm CC Cluster command syntax]

A convenient software for setting up filters etc. can be found here [http://www.bcdxc.org/ve7cc/default.htm#prog CC User]

[[Image:Ccclustersspotflow.png]]

==Support for AR Cluster 6==

With the author tragically SK, AR Cluster is no longer under development but still available as an executable binary.

In its standard configuration, AR Cluster offers no consolidation of skimmer spots meaning a very high flow of spots 
that can become extreme during a major contest weekend.

With the advent of skimmers, the traffic on the DX Cluster has risen dramatically. Even though CW skimmers are generally 
quite reliable, the absolute number of busted spots can be quite high during a busy contest.

Jose CT1BOH has developed an algorithm for evaluating spot quality which is included in version 6 of AR Cluster. 
Today many cluster nodes runs this version and thereby offer this mechanic. 
A complete list can be found here: [http://www.dxcluster.info/telnet/index.php?software=AR-Cluster AR Cluster nodes]

To enable the functionality on a cluster node running AR Cluster 6, the command

<tt>'''SET DX EXTENSION SKIMMERQUALITY'''</tt>

needs to be issued to the cluster node. The easiest way to do this in DXLog is via <code>[Alt][T]</code>. 
This setting will be remembered at subsequent logins.

The quality of the spots is indicated by a character ("tag") in the last column of the comment field and, 
in some cases, a corrected callsign within parenthesis. This syntax is recognized by DXLog and can reduce the 
number of bad spots in your bandmap.

The CT1BOH skimmer quality algorithm is based on three parts:

; Validation : When a callsign is first spotted, it is tagged with "?" in the last column of the spot's comment field. If the callsign of an unverified spot closely resembles an already verified one on the same frequency, the verified callsign is provided within parenthesis in the spot's comment field. When two or more skimmers agree on the spot, it is considered verified and the tag becomes "V".

; Frequency : When a verified spot appears more than 0.35kHz off its verified frequency, the spot is tagged "Q" for QSY. Once verified, this becomes the new verified frequency and it is tagged "V".

; Probability : The algorithm checks uncertain spots for resemblance with already verified spots and spots at or near the same frequency. If the resemblance is high enough, the spot is considered busted "B" and the corrected callsign is provided within parenthesis in the spot's comment field.

Below you can see an example of the spot flow from W9PA-4 with skimmer quality enabled. 
The flow contains one unverified and one busted spot.

[[image:spotquality.png]]

DXLog's policy for spots with CT1BOH skimmer quality tags is the following:

: '''V''' - Accept spot.
: '''Q''' - Accept spot.
: '''?''' - Accept spot. Use corrected call when provided.
: '''B''' - Accept spot if corrected call provided. Else ignore.

DXLog recognizes the skimmer quality tags but consolidates them for consistency 
with other cluster nodes' quality tags and to minimize confusion when mixing spot flows. 
The legend is:

: '''?''' means a spot with ? This is an unreliable spot.
: '''P''' means a spot with Q or B with correction. This is a fairly reliable spot.
: '''V''' means a spot with V. This spot is considered validated.

This basic policy can be modified by using additional filters at the cluster node end. Some examples are:

: <tt>'''SET DX FILTER NOT SKIMBUSTED'''</tt> - Do not send busted spots at all
: <tt>'''SET DX FILTER NOT SKIMQSY'''</tt> - Do not send QSY spots
: <tt>'''SET DX FILTER SKIMVALID'''</tt> - Only send verified spots
: <tt>'''SET DX FILTER NOT SKIMUNKNOWN'''</tt> - Do not send unreliable spots
: <tt>'''SET DX FILTER SKIMMER'''</tt> - Do not send manual spots

You can also compose more complex filters such as:

: <tt>'''SET DX FILTER SKIMVALID OR SKIMBUSTED OR NOT SKIMMER'''</tt>

This can be a good filter for most contests. It will will only provide valid or busted skimmer spots together with manual spots. 
It is safe to receive busted spots since DXLog will ignore them if there is no corrected callsign included. 

For assisted operation in serious contesting you however need to allow also unknown spots since weak stations spotted 
only by one or a few skimmers may never reach validated status. You do this by adding <tt>'''OR SKIMUNKNOWN'''</tt> to the filter.

Both the bandmap and the DX cluster announcement windows have the option to display the spot quality tag. 
These windows will show two additional tags; L and C. L stands for local spot, created by yourself or one of your team members. 
C stands for corrected, i.e., a B or ? spot where a corrected call has been included in the spot's comment field.

The AR6 filtering syntax offers a lot of flexibility. Another example:

: <tt>'''SET DX FILTER (SKIMVALID OR NOT SKIMMER OR ((SKIMQSY OR SKIMUNKNOWN) AND (CTY <> K AND CONT <> EU )))'''</tt>

will provide only validated and human spots except if they are from outside the US and EU.

If you get lost in the filter settings you can always reset with : <tt>'''SET DX DEFAULT'''</tt>.

Some more guidance on how to work with filters on AR-Cluster nodes can be found in [http://dxlog.net/sw/files/utilities/AR_Cluster_v6_User_Manual.pdf this document].

==Support for DXSpider==

DXSpider is the by far most dominant DX cluster software but has historically not been a good choice for contesters. 
The reasons for this include: Long respotting time, lack of pass function for own spots, and suppression of spots from a single skimmer.

The good news is however that the author Dirk G1TLH has worked hard to address these aspects of the otherwise brilliant software.

From '''version 1.57 release 440''' the respotting time is now 3 minutes and there is a <tt>SET/SEEME</tt> command that passes all spots 
without consolidation of your own callsign.

So if your favorite cluster node is not running this version, ask the owner to upgrade asap.

Yet another reason for its popularity is its extreme resource-efficiency which allows it to run virtually 
any Linux capable hardware, including a $20 Raspberry Pi Zero.

A list of all DX cluster nodes running DX Spider can be found here: [https://www.dxcluster.info/telnet/index.php?software=DX%20Spider DX Spider cluster nodes]

[[image:dxspiderflow.png]]

DXLog recognizes the <tt>Q:#</tt> skimmer quality tag in the comment field and converts them into "CT1BOH-like" quality 
tags that can be displayed in DXLog's bandmap. The legend is:

: '''?''' means a spot with Q:1, i.e. heard by only one skimmer. This is an unreliable spot.
: '''P''' means a spot with Q:2, i.e. heard by only two skimmers. This is a fairly reliable spot.
: '''V''' means a spot with Q:3 or higher, i.e. heard by several skimmers. This spot is considered validated.

Since a DXSpider node currently needs to be specially configured by the owner to publish Q:1 spots, very few do this. 
Also, since DXSpider lacks busted call detection, the the quality of the spot flow will suffer if this is done.

There is a wealth of information to be found on the [http://wiki.dxcluster.org/index.php/Main_Page DXSpider wiki].

==Support for N2WQ Cluster==

Introduced in late 2025, Rudy N2WQ has developed the first new DX cluster node software in decades.

The N2WQ-2 cluster has some unique features like a more advanced callsign validation than 
AR 6 and propagation estimation tags embedded in the spot comments. An example can be seen below.

[[image:n2wpspotflow.png]]

When you connect to dxc.n2wq.com port 8300 and you have set your 4-digit Maidenhead grid (SET GRID), there 
will be a single character just before the DX’s grid locator. This character is the path prediction glyph.

It is a crowdsourced, real-time estimate of how reliable the path is between you and the DX on that band right now, 
based on recent on-air propagation reports from RBN and PSKreporter. Its values and meaning are:

: > High: Strong path. If you can hear them, you should be able to work them.
: = Medium: Decent path. Workable with normal contest/DX technique.
: < Low: Weak path. Possible, but expect repeats, timing, and patience.
: - Unlikely: Marginal. Try only if it’s rare/needed, or you have a strong station advantage.

A missing glyph means insufficient data to estimate the path.

the glyph is mode-aware. A path that looks great for a very sensitive mode (FT8) can look 
more moderate for a less sensitive one (SSB).

You can filter spots by path reliability using the PASS/REJECT PATH command.

It is important to be aware that the glyph does not know:

: Your antenna gain/pattern, height, or takeoff angle
: Your transmit power and duty cycle constraints
: Your operating technique (timing, split discipline, pileup strategy)
: Short-lived phenomena the network has not yet “seen” such as sporadic E or aurora.

The cluster ingests upwards of 50,000 CW, FT, RTTY, and WSPR spots per minute. To compare different modes 
fairly, the system normalizes reports onto a common “FT8-equivalent” scale (so a CW SNR can be compared 
to an FT8 SNR).

Your grid and the DX grid are mapped into small geographic cells and the cluster calculates propagation 
at two levels:

: Fine (local): what’s happening close to your area (~180 miles).
:: On averages there are about 90,000 DE/DX pairs being tracked
: Coarse (regional): what’s happening in the broader region around
:: you (~480 miles). On average, there are about 30,000 DE/DX pairs.

If there isn’t enough local data, the system leans more on regional behavior. 
If there’s plenty of local data, it uses that more heavily.

Sometimes you can hear them better than they can hear you (or the reverse) due to noise 
floors, antennas, geography, or ionospheric effects. The system tracks both:

: Receive direction: DX to you (can you hear them?)
: Transmit direction: you to DX (can they hear you?)

It combines these into one “path reliability” estimate, weighting receive a bit more 
because if you can’t hear them, you can’t work them.

Propagation changes fast, so older reports get discounted using a half-life (data fades 
in influence over time). Typical behavior by band:

: Low bands (160/80m): slower changes (longer half-life)
: Mid bands (40–20m): medium pace
: High bands (15–6m): fast changes (shorter half-life)

In practice, this means glyphs can shift in minutes on 10m/6m, and more slowly on 80m/160m. 
Also, new openings take time to show up. A "insufficient" can simply mean “the path just opened 
and the cluster hasn’t collected enough recent reports yet.”

Your local noise floor heavily affects what you can receive, so the cluster lets you tell 
it what your noise environment is. This mainly tunes the receive-side expectation (DX to you).

Set it with SET NOISE SUBURBAN. Available profiles per ITU:

: QUIET: very low noise, rural/remote
: RURAL: mild noise
: SUBURBAN: typical neighborhood QRM
: URBAN: elevated noise, dense housing
: INDUSTRIAL: severe noise

If you don’t set it, the system may assume a quieter environment than you actually 
have, and your receive-side glyphs can look too optimistic.

Treat the glyph as a real-time probability hint that helps you spend your operating 
time where the odds are best. When you see > on a needed multiplier, move fast. 
When you see -, be intentional about whether it’s worth the time. 
And when you see a space, fall back to classic DX/contest instincts and your own ears.

The N2WQ cluster also offers spot quality tags between the DX grid and the time.

A quality (in terms of callsign reliability) tag can be V, P, S, C, or ? where V means validated, 
P highly likely, S less likely, C corrected, and ? unsure.

The propagation and quality tags can be displayed in the bandmaps and the DX cluster announcement window.

DXLog recognizes the skimmer quality tags but consolidates them before display for consistency 
with other cluster nodes' quality tags and to minimize confusion when mixing spot flows. 
The legend is:

: '''?''' means a spot with ? or S. This is an unreliable spot.
: '''P''' means a spot with P or C. This is a fairly reliable spot.
: '''V''' means a spot with V. This spot is considered verified.

==Interacting with WSJT-X==

Important: When in a DXpedition/multi-station setting, always use local host 127.0.0.1 as the 
broadcast address to prevent packets being picked up by other stations in the network. 
Also, enabling the creation of local spots from decodes may overwhelm DXLog.

DXLog can add QSO performed with WSJT-X to its log. Note that this functionality only works 
for contests with grid as the first and only exchange or for DXPedition type logs.

DXLog can also create local spots from WSJT-X decodes by checking 
<code>Options|Broadcast|Spot WSJT-X decodes</code>.

To enable logging of WSJT-X QSO, set up WSJT-X to broadcast information:

[[image:Wsjt-x-udp.png]]

[[image:Radiobroadcastenable3.png]]

Activate DXLog's UDP listener by checking <code>Options|Broadcast|Receive broadcasts</code> and set 
the same port number as in WSTJ-X in DXLog's network configuration panel.

[[image:Dxlog-udp.png]]

==Using Winkey FSK==

Winkey FSK is not natively supported by DXLog's digital mode engines MMVARI or MMTTY but 
Rafal EI6LA has developed a plugin for MMTTY that makes this possible.

You can find it [https://github.com/RafalLukawiecki/WinKeyerMMTY here].

==Interfacing with LogHX==

Christian F8GHE has prepared a guide on how to do this.

You can find it [http://dxlog.net/sw/files/utilities/DXLOG-LogHX_UDP-config_v2.pdf here].

==Self-spotting==

More and more contests allow spotting your own station on the DX cluster.

DXLog supports this, even when operating unassisted, as long as you connect to the cluster.

DXLog has three mechanics for self-spotting.

DXLog blocks self spotting unless specifically allowed in the contest rules. 
Should you find that DXLog incorrectly allows or blocks self-spotting, please make 
the development team aware via the support reflector.

* The <tt>$SPOTME</tt> macro command. This macro will create a cluster spot of the station's
: call at the earliest 15 seconds after being invoked the first time on a new frequency.
: Thereafter it will spot as frequent as allowed by the contest. If the contest rules do not
: specify a minimum period, 10 minutes will be used.

* Checking the menu option <code>Tools|Data entry|Run F1 message self-spots when permitted</code>.
: Works exactly like the <tt>$SPOTME</tt> macro command but is triggered by sending the
: Run F1 message which happens when pressing <code>[Enter]</code> with an empty entry line
: in Run, pressing <code>[F1]</code> in Run, or with Auto-CQ.

* Clicking the menu item <code>Commands|Self-spot</code> or pressing its shortcut key <code>[Ctrl][S]</code>.
: This will immediately create a spot of the station's call but no more often than
: every two seconds to avoid accidental multiple spots.

==DXpedition use==

DXLog is a popular choice for top tier dxpeditions. Below we have collected advice based on experience 
on how to best use DXLog in a dxpedition setting.

* Use client/server networking between stations. Never use UDP over Wi-Fi or WAN links.
* Use the "Minimal data" option in ADIF export to save on satellite link cost.
* For Club Log real time upload, use [[https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads Club Log's upload app]]
* Club Log truncate QSO time to minutes so to avoid creating dupes when mixing manual and real time
: upload to Club Log, check "QSO time in minutes" when doing ADIF export.
* Use the "Minimal data" option in ADIF export to save on satellite link cost.
* Follow [[Additional_Information#Interacting_with_WSJT-X|the instructions]] to log QSO made with WSJT-X and MSHV.
* Check <code>Options|Broadcast|Spot WSJT-X decodes</code> to make decoded calls appear in e.g., DX cluster announcements.
* You can extend the number of digits in the QSO count with <code>Options|Log|QSO number digits</code>

==Beacon spots on DX cluster==

Although propagation measurements based on FT8 communications has reduced the
value of beacons, there are still hundreds of them in operation.

Identifying with CW, they are typically reported on reported on the DX cluster.

When beacon spots are received by DXLog, they are always displayed in the bandmap. 
In DXLog, beacon spots are recognized by having a trailing <tt>/B</tt>.

The DX cluster announcement window never shows or counts beacon spots.

Beacon spots can be enabled and disabled in the cluster node.

For CC Cluster, the commands are <tt>SET/BEACON</tt> and <tt>UNSET/BEACON</tt>.

For DXSpider, command is part of the <tt>SET/SKIMMER</tt> command where <tt>SET/SKIMMER</tt> 
or e.g., <tt>SET/SKIMMER CW BCN FT RTTY</tt> will pass beacon spots and <tt>UNSET/SKIMMER</tt> 
or any <tt>SET/SKIMMER</tt> listing modes but not BCN will block them.

AR 6 cluster nodes always pass beacon spots when skimmer spots are enabled. They cannot be disabled.

Additional Information

2026-03-31T11:10:29Z

Sm7iun: /* Real time upload to Club Log Live Stream */

==Using alternative configurations==

Window positions, coloring and general look and feel is saved in each log file but all other settings such as 
radio control, keying, and networking is saved in a common, contest-independent configuration file.

By default, the configuration file name is <tt>DXLog.net.config</tt> and it is located in the <tt>%appdata%\DXLog.net</tt> configuration folder.

This folder is also reachable via the <code>File|Open configuration folder</code> menu item.

[[image:configfolder.png]]

DXLog can be made to use an alternative configuration file with the command line option <tt>-cfg=<filename></tt>.

A convenient way to use this option is to create a separate Windows desktop shortcut including the command line option 
and give it a meaningful name.

[[image:Desktopshortcut.png]]

The command line option is simply added to the end of the Target text box in the shortcut's properties. 
Double-clicking the icon will start DXLog with the alternative configuration which will also be remembered between sessions. 
In the picture below the target of the shortcut is

[[image:Desktopshortcutconfig.png]]

'''Important:''' If you want to use an alternative configuration, do not just modify the desktop shortcut created at installation 
since this shortcut will be deleted when you upgrade DXLog. Instead make a copy, rename, and add the command line option. 
You should keep the command line option outside the apostrophes, like this

<tt>"C:\Program Files (x86)\DXLog.net\DXLog.net.exe" -cfg=SO2R.config</tt>

==Using a number server==

For contests involving serial numbers you need to secure that the sent number and the (slightly later) 
logged serial numbers are the same. In a straightforward SO1R or SO2V scenario, serial numbers are simply 
chronological but in more complex station configurations such as Multi-single or Multi-2 with inband, and 
advanced SO2R, QSO can be interleaved and requires a central source source of serial numbers together 
with a mechanic to protect an already sent serial number from re-use by another radio.

In DXLog this is achieved with a central number server. A number server can be used either 
by a single instance of DXLog (for SO2R) or by multiple stations on the same LAN.

The use of a number server involves three, natural, steps:

* Activating the server on a single station
* Making sure all stations use it
* Verifying functionality, making sure serial numbers are correctly reserved

The number server is activated in the <code>Options|Configure network</code> panel, described [[Menu_Options#Configure_network|HERE]].

[[image:startnumberserver.png]]

Since the server uses a networking socket, <code>Options|Networking</code> must be enabled '''also''' when 
using a single computer in SO2R. In the case of multiple stations, UDP networking or Client-Server 
networking must also be enabled to transfer the numbers over the LAN. For SO2R, this is however not 
necessary. When using Client-Server networking, a client cannot be number server.

There must only be one number server in a local network and all stations using it must have 
<code>Options|Networking|Use number server</code> checked like in the picture below.

'''Important:''' The number client/server functionality is not very robust. 
If you have stations joining/leaving your network or being rebooted, it is 
best to restart DXLog on all stations to guarantee correct function.

[[image:usenumberserver.png]]

The option <code>Block logging if serial number reservation is unsuccessful</code> can be used as an extra precaution 
but is not necessary in SO2R since the communication with the number server does not leave the computer.

There are three methods for reserving a number from the server:

* Checking <code>Tools|Data entry|Space key reserves serial number</code> and using the space key to reserve serial numbers. This is typically used on phone or when operating "old school" with F-keys.
* Checking <code>Tools|Data entry|Insert and F2 messages reserve serial number</code> and letting DXLog automatically reserve a serial number right before $SERIAL sends it. This is the preferred and most straightforward way for CW and digital.
* Adding the $RESERVENR macro to messages like illustrated below. 

These methods can of course also be combined. 

The $RESERVENR macro is "smart" and will only reserve a serial number if the callsign entry field is not empty and a 
serial number is not already reserved. The same goes for the menu items.

[[image:reservemessages.PNG]]

The sign of a serial number being reserved is that it turns red. It then stays reserved (and red) until the 
QSO is logged or the entry line is cleared with <code>[Alt][W]</code>.

An option that can prove useful is <code>Tools|Data entry|Cancel serial number reservation only if callsign field is empty</code>. 
In the case that you send the exchange and realize you got the other station's callsign call completely wrong, a reflex can be to hit 
<code>[Alt][W]</code> and start typing. If this is your habit, this option will prevent you from releasing the 
already sent serial number, thereby avoiding you the trouble to send a new one to the other station.

[[image:reservednumber.png]]

==Networking over internet==

When, for instance, activating a special event callsign it is possible to network multiple DXLog stations over the internet.

'''Pro tip:''' Consider displaying the callsign, message ID, Message text, etc. fields in the ''Network status'' 
window when operating a distributed station. Also, learn to use the gab <code>[Alt][G]</code> and <code>[Alt][J]</code> function.

===VLAN/VPN Solution===

The most secure way for remote networking is to rely on a VLAN (virtual LAN) software. There are several available such as:

ZeroTier https://www.zerotier.com/ 
FreeLan http://www.freelan.org/ 
Player.me https://player.me/ 
OpenVPN https://openvpn.net/

Each VLAN solutions have their own particular set up which is covered in their respective documentations. 
With a VLAN solution, all DXLog configurations are the same as when operating in a regular LAN however with a few exceptions.

One weakness with connections over the internet (a.k.a. WAN), including VLAN solutions, is that they are prone to packet loss. 
Packet loss is disastrous to DXLog's (or any logger's) "standard" UDP networking.

It is therefore essential to use '''only client/server networking over a VLAN'''. 
'''This also means you should never use interlock over an internet connection unless you use a zero packet loss VPN tunnel.'''

ZeroTier is particularly popular since it is free.

Since DXLog is able to mix TCP (client/server) and UDP (peer-to-peer) networking, a distributed station set up should be configured to rely on TCP 
for the wide-area network and UDP for the local network at each station location. Below you will find the station 
set up for the Swedish HQ station SE9HQ in the 2019 IARU HF Championship. The DXLog.net.DXC cluster client was run 
on SK3W-A which distributed spots to all stations over the network. Inband interlock was also used at the SK3W location.

[[image:SE9HQ-network-eng.png|800px]]

Important to note:

* For the server as well as the main clients, ''Server IP'' should be set to the server's VLAN IP address, '''not''' its LAN address.
* The '''server''' should check both "Act as network server" and "UDP network broadcast for multiple stations".
* The '''main clients''' should check both "Connect to network server" and "UDP network broadcast for multiple stations".
* The '''sub clients''' should check only "UDP networking for multiple stations".
* Interlock (which is UDP-based) over VLAN does not work reliably because of packet loss.
: Therefore, it is important to configure any interlock to '''only''' consider relevant operating positions,
: which all must be local. Use the possibility to only consider named stations for the interlock in the software 
: interlock set up. <code>Options|Networking|Software interlock</code> "Custom station ID(s)"
* For a large set-up with many stations connecting as clients to a central server you may overload the server if you also
: distribute spots via all client-server connections. In this case, check the "No spots via client/server" option
: on all stations and use '''local DX cluster connections''' via UDP at each location.
: '''Important:''' Limitations in Windows networking makes client/server networking unreliable beyond 10 station locations.
* Make sure to check <code>Options->Load contest at startup</code> to avoid opening the wrong log after a restart.
* '''Remote commands are not forwarded''' in the network but are executed in the station where they arrive.
: Thus, to clear all logs, disconnect networking on each main client, execute the remote command CLEARLOGNOW on each main client
: to clear the logs of all sub clients and do not reconnect until the server and all other main clients have done the same.

===Port forwarding Solution===

If you are less worried about competitors or government agencies listening in on your contest data, 
it is possible to route the traffic directly over the internet using port forwarding at the server.

'''Important security notice: This solution is not without risk. It offers no security or authentication. 
Any DXLog station running the same contest configuration, knowing the URL or IP address and IP port of the 
server can connect to the server station. There are no means to disconnect a station by force.'''

Also note the comment about '''remote commands''' in the section above.

With a port forwarding solution, the following must be observed:

* '''Server configuration'''
:* Only one of the stations should be configured as the '''server'''.
:* "Connect to network server" should not be checked on this station and
:: "UDP networking for multiple stations" should only be enabled if it is used to
:: communicate with a cluster client or other stations locally on the same LAN.
:: Either use a central cluster connection (uncheck "No spots via client/server")
:: or use one cluster connection per station location (check "No spots via client/server").
:: If one cluster connection per station location is used, make sure they
:: all use different SSID to prevent disconnects, such as E7HQ-1, E7HQ-2, etc.
:: This will ensure the cluster node regards all connections as having the same callsign
:: which is essential for e.g., correctly receiving own spots.
:* The PC acting as server must be configured for a fixed LAN IP address. This is done
:: either by manually configuring the networking settings in the PC to use a fixed
:: LAN IP address, or by setting up the router in the server's LAN to to always allocate
:: the same IP address to it.
:* The internet connection used by the server PC must ''either'' have a fixed public IP address ''or''
:: use dynamic DNS. Otherwise clients will not be able to reliable connect over the internet.
:* The server's TCP/IP port (e.g., <code>9888</code>) must be forwarded to the server by the server LAN's router.
:: Only TCP traffic should be forwarded. DXLog UDP traffic is not carried well over the internet.

:: [[image:serverconfig.png|600px]]
:: '''Example configuration for server for networking over internet'''

::[[image:portforwarding.png|600px]]
::'''Example of port forwarding UI in router'''

* '''All other stations'''
:* All other PC in the multi-station set up should be set up as clients.
:* Over the internet, "Server:" is either the static, public IP address of the server's internet
:: connection (e.g. <code>5.140.211.42</code>) or the dynamic DNS address (e.g. <code>hq.sm7iun.se</code>).
:: Clients connecting over the internet does not have to enable UDP networking and ''should not''
:: enable a server.
:* A client may connect via UDP if it is on the same LAN as the server ''or'' a "main client".
:: A "main client" is a client that connects to the server using the "Connect to network server" option in
:: the networking set up panel. A "main client" acts as a UDP gateway which means that if
:: several computers on a LAN are part of the same multi station set up but the server is located
:: elsewhere, only one computer in that LAN needs to connect as a client and the rest can use UDP.
:* Software interlock is UDP-based and can only reliably be used locally. Never over the internet.
:: If used, make sure the interlock is explicitly limited to local stations. See above for more details.

::[[image:clientconfig.png|600px]]
::'''Example configuration of client for networking over internet'''

* In a multi-station setting it is recommended to enable
: <code>Options|Networking|Block standard messages if no operator is logged on</code>
* Make sure <code>Options|Enable network</code> is checked.
* It is also a very good idea to check <code>Options|Load contest at startup</code> to reduce the
: risk of the wrong contest log file being loaded by any stations.

==Real time upload to Club Log Live Stream==

'''Important:''' Club Log truncates QSO time to minutes which means that if you mix real time upload 
with manual upload, make sure to check "QSO time in minutes" when creating ADIF export files.

The author of Club Log, Michael Wall, G7VJR, has developed a very powerful agent for real time uploads.
It works with all the three major loggers, DXLog, N1MM Logger+, and Win-Test.

It can either be used as is, with a command line user interface, or with an optional user interface front end.

Information on how to download and configure it can be found [[https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads HERE]]

The Club Log Gateway can either listen to DXLog's native multi-station networking protocol or to N1MM style XML broadcast.

To use DXLog's networking protocol, make sure the same port (default 9888) is used in the gateway and DXLog 
and that UDP networking is enabled in DXLog. Do not enable QSO broadcast.

Although this works, it is recommended to use N1MM style broadcast since it contains information like logged on operator, etc.

To use this make sure the port (default 12060) is the same in N1MM port setting in the gateway and in the 
QSO broadcast port settings in DXLog's network configuration. Also make sure to se the DXLog port number 
in the gateway is not the same as that used in DXLog to avoid QSO duplication.

Also set:

<code>Options|Broadcast|QSOs</code> 
<code>Options|Broadcast|QSOs</code> 
<code>Options|Broadcast|Use N1MM QSO format</code> 
<code>Options|Broadcast|QSO time in minutes only</code>

'''Important:''' If you are going to also upload exported ADIF files to Club Log, it is important to also 
check "QSO time in minutes" in the ADIF export configuration to avoid creating virtual dupes, since Club 
Log does not know seconds.

==Diversity reception==

Diversity means receiving the same signal through two different receive chains, including antenna. 
With two antennas having different characteristics this can give substantial benefits in receiving 
fading and/or weak signals or separating calls in a large pile-up. Particularly on low bands.

DXLog supports diversity operation on a selected number of radio models.

For the supported radios, diversity operation can be toggled on and off using <code>[Ctrl][-]</code> or <code>[Ctrl][Keypad -]</code>.

If enabled via the radio's controls, DXLog will automatically detect diversity operation and enable 
the necessary mechanics. Diversity operation is indicated by a small DIV icon in the frequency 
counter box for the radio's band map.

'''Yaesu FTDX101D

Yaesu calls this feature "Sync" and it has a dedicated button up and left of the main VFO knob. 
Enabling this will make DXLog update both VFO with the same information when grabbing spots. 
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO. 
Since both VFO are kept on the same frequency, split operation is not supported.

'''ICOM IC-7851 and IC-7610

ICOM calls this feature "Tracking" and it can be enabled either via a menu entry or a long press on the "MAIN/SUB" button. 
Enabling this will make DXLog update both VFO with the same information when grabbing spots. 
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO. 
Since both VFO are kept on the same frequency, split operation is not supported.

'''Elecraft K3/K3S/K4

Elecraft calls this feature by its proper name. It is enabled by a long press on the "Sub" button. 
It should be noted that Elecraft's implementation where the main VFO controls both the main and 
sub receivers allows for split operation, i.e. transmitting on a different frequency using VFO B.

==UDP broadcast==

For interaction with other applications, DXLog can broadcast useful information as 
XML datagrams over UDP. 

There are five types of broadcast messages produced by DXLog:

* QSO information. Sent when logging.
* Radio information. Sent at changes as well as periodically.
* Antenna direction information. Sent when rotor control is invoked.
* Callsign look-up information
* Spots

QSO can be broadcasted in traditional DXLog format or in a more N1MM-like format.

Radio information can report SO2V as a single physical radio or as two physical radios, like N1MM.

There is an option to truncate the broadcasted QSO time to full minutes for better 
interoperability with some online services and software such as MSHV.

In addition, DXLog can also recognize QSY commands from Waterfall Bandmap and log QSO done as well as create 
local spots from decodes broadcasted by WSJT-X and its forks.

The broadcasting of QSO and radio related data is enabled using the <code>Options|Broadcast</code> submenu.

The broadcasting of spots is enabled by checking <code>Options|DX Cluster|Send spots to SmartSDR</code>.

[[image:radiobroadcastenable3.png]]

[[image:sendspotstosmartsdr.png]]

UDP broadcast parameters are configured in the <code>Options|Network configuration</code> panel. 
Please note that up to three ports can be specified for each broadcast, thereby supporting 
multiple receivers of the information.

[[image:Networksettingsbroadcast3.png]]

If you are writing a C# application to make use of these datagrams, there is a very nice online tool 
for creating an object from a sample XML datagram here https://xmltocsharp.azurewebsites.net/ 

In C# parsing is easily done using Linq. One example of XML parsing and deserialization using Linq 
can be found here https://github.com/bjornekelund/ICOMautomagic

===QSO information===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program
|-
| qsoid
| A unique string for this QSO. If this QSO is edited another contactinfo message will be sent with the same qsoid. Note that the qsoid is only unique within one instance of DXLog. If the computer is networked to others running DXLog the different computers may have a different qsoid for the same QSO.
|-
| contestname
| The name of the contest as it would be written to a Cabrillo file.
|-
| timestamp
| The UTC date and time of the QSO.
|-
| mycall
| The callsign of this station.
|-
| band
| The band on which the QSO was made. In MHz with period as decimal separator.
|-
| txfreq
| The frequency on which the QSO was made.
|-
| operator
| The callsign of the operator if the OPON command was used to set it, otherwise blank.
|-
| mode
| The mode used for the QSO.
|-
| call
| The callsign of the station worked.
|-
| countryprefix
| The DXCC country of the station worked.
|-
| wpxprefix
| The WPX prefix of the station worked.
|-
| snt
| The RST sent. This is always included whether or not the contest exchange contains an RST.
|-
| rcv
| The RST received. This is always included whether or not the contest exchange contains an RST.
|-
| nr
| The number sent if the exchange uses a serial number, otherwise the QSO number from this station.
|-
| exch1
| The first element in the contest exchange if any.
|-
| exch2
| The second element in the contest exchange if any.
|-
| exch3
| The third element in the contest exchange if any.
|-
| exch4
| The fourth element in the contest exchange if any.
|-
| xqso
| True if this QSO should not be counted towards the score.
|-
| invalid
| True if this QSO is invalid, for example a DX QSO in a domestic contest.
|-
| duplicate
| True if this QSO is a dupe (the station has previously been worked).
|-
| rule10broken
| True if this QSO breaks the 10 minute or similar rule. Note that a QSO may not break the 10 minute rule when it is logged but may later if another QSO is edited. This may not cause a broadcast.
|-
| azimuth
| The approximate direction of the station worked, in degrees.
|-
| distance
| The approximate distance of the station worked, in kilometers.
|-
| stationid
| The station ID of the station which made the QSO.
|-
| stationqso
| A unique QSO ID generated by the logging station. The combination of stationid and stationqso forms a unique identifier for the QSO.
|-
| stationtype
| The type of station - R for run, R1 for run 1 etc.
|-
| local
| True if this broadcast is due to this QSO being logged or edited on this computer.
|-
| runqso
| True if QSO logged in Run, false if S&P, and empty if unknown. '''Important:''' Only valid when local is True.
|-
| mult1
| The name of the multiplier if this station is a new multipllier, empty otherwise.
|-
| mult2
| The name of the multiplier if this station is a new multiplier, emtpy otherwise.
|-
| mult3
| The name of the multiplier if this station is a new multiplier, empty otherwise.
|-
| points
| The logged points for the QSO.
|-
| period
| The number of the operating period.
|-
| guid
| The GUID in hex format.
|-
| newqso
| True if a new QSO, False if this message is an update to an existing QSO.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<contactinfo>
<logger>DXLog v2.4.13</logger>
<qsoid>19</qsoid>
<contestname>ARRL-SS-CW</contestname>
<timestamp>2020-01-13 18:28:07</timestamp>
<mycall>SM7IUN</mycall>
<band>3.5</band>
<txfreq>352376</txfreq>
<operator></operator>
<mode>CW</mode>
<call>K4BAI</call>
<countryprefix>K</countryprefix>
<wpxprefix>K4</wpxprefix>
<snt>599</snt>
<rcv>599</rcv>
<nr>19</nr>
<exch1>076</exch1>
<exch2>B</exch2>
<exch3>54</exch3>
<exch4>GA</exch4>
<xqso>False</xqso>
<invalid>False</invalid>
<duplicate>False</duplicate>
<rule10broken>False</rule10broken>
<azimuth>225</azimuth>
<distance>1388</distance>
<stationid>STN1</stationid>
<stationqso>19</stationqso>
<stationtype>R1</stationtype>
<local>True</local>
<runqso>True</local>
<mult1>GA</mult1>
<mult2></mult2>
<mult3></mult3>
<points>3</points>
<period>1</period>
<guid>11223344556677889900aabbccddeeff</newqso>
<newqso>True</newqso>
</contactinfo>
</pre>

Alternative N1MM format

Note that the band name uses the computer's local number format so it may use either comma 
or period as decimal separator. The ID is a number rather than an alphanumeric string.

Also note that IsRunQSO is only valid when IsOriginal is True.

<pre><?xml version="1.0" encoding="utf-8"?>
<contactinfo>
<app>N1MM</app>
<contestname>CWOps</contestname>
<timestamp>2020-01-17 16:43:38</timestamp>
<mycall>SM7IUN</mycall>
<band>3.5</band>
<rxfreq>352519</rxfreq>
<txfreq>352519</txfreq>
<operator></operator>
<mode>CW</mode>
<call>K1XM</call>
<countryprefix>K</countryprefix>
<wpxprefix>K1</wpxprefix>
<stationprefix>K1XM</stationprefix>
<continent>NA</continent>
<snt>599</snt>
<sntnr>5</sntnr>
<rcv>599</rcv>
<misctext></misctext>
<ismultiplier1>1</ismultiplier1>
<ismultiplier2>0</ismultiplier2>
<ismultiplier3>0</ismultiplier3>
<points>l</points>
<radionr>l</radionr>
<run1run2>1<run1run2>
<IsOriginal>False</IsOriginal>
<NetBiosName>DESKTOP-23AB</NetBiosName>
<IsRunQSO>0</IsRunQSO>
<StationName>STATION_B</StationName>
<ID>23</ID>
<IsClaimedQso>true</IsClaimedQso>
</contactinfo>
</pre>

===Radio information===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| The name of the logging program.
|-
| logger
| The name and version of the logging program.
|-
| Station
| The ID of the station.
|-
| RadioNr
| The radio being described.
|-
| Freq
| The receiving frequency.
|-
| TXFreq
| The transmitting frequency
|-
| InactiveFreq
| The frequency of the VFO not receiving.
|-
| Mode
| The reported radio's mode.
|-
| OpCall
| The callsign of the operator if the OPON command was used to set it, otherwise blank.
|-
| mycall
| The callsign of the station.
|-
| IsRunning
| "True" if the station is running, "False" if search and pounce.
|-
| FocusEntry
| The Windows handle for the focused entry window.
|-
| Antenna
| Antenna number.
|-
| Rotors
| Rotators used by selected antenna (not currently used by DXLog).
|-
| FocusRadioNr
| The radio which has keyboard focus. In SO2V with "Report SO2V as two radios" checked, radio 2 is the sub/B VFO.
|-
| IsStereo
| True if headphones are listening to two radios.
|-
| IsSplit
| True if radio is set to split.
|-
| ActiveRadioNr
| The radio which is transmitting, if any.
|-
| Technique
| SO1R, SO2R, SO2R_ADV, or SO2V
|-
| StationType
| Station role: R, M, R1, R2, or R+.
|-
| isTransmitting
| True if a DXLog is transmitting. False if DXLog is not aware of transmission.
|-
| IFFrequency
| Optional element only used with Elecraft K3/K4. Contains the current IF frequency in Hz.
|-
|}

Important note: In SO2V the format differs from some other loggers and is:

: Only physical radio 1 is reported.
: <tt>Freq</tt> and <tt>TXFreq</tt> are the frequency of the currently focused VFO.
: <tt>InactiveFreq</tt> is the frequency of the currently unfocused VFO.
: <tt>ActiveRadio</tt> is always 1.
: <tt>FocusedRadioNr</tt> is 1 when the main/A VFO is focused, 2 otherwise.
: <tt>IsSplit</tt> is always false.

With the option "Report SO2V as two radios" checked, the reporting is similar to some other loggers and is:

: The two VFO are reported as two physical radios.
: <tt>Freq</tt> and <tt>TXFreq</tt> for radio 1 are the frequency of the main/A VFO.
: <tt>Freq</tt> and <tt>TXFreq</tt> for radio 2 are the frequency of the sub/B VFO.
: <tt>InactiveFreq</tt> is the frequency of the other VFO.
: <tt>ActiveRadio</tt> and <tt>FocusedRadioNr</tt> are 1 when the main/A VFO is focused, 2 otherwise.
: <tt>IsSplit</tt> is always false.

Example message:

<pre><?xml version = "1.0"?>
<RadioInfo>
<app>DXLog</app>
<logger>DXLog v2.4.13</logger>
<Station>STN1</Station>
<RadioNr>1</RadioNr>
<Freq>704000</Freq>
<TXFreq>704000</TXFreq>
<InactiveFreq>702500</InactiveFreq>
<Mode>CW</Mode>
<OpCall>K1XM</OpCall>
<mycall>HQ9X</mycall>
<IsRunning>False</IsRunning>
<FocusEntry>591124</FocusEntry>
<Antenna>1</Antenna>
<Rotors>ABC</Rotors>
<FocusRadioNr>1</FocusRadioNr>
<IsStereo>False</IsStereo>
<IsSplit>False</IsSplit>
<ActiveRadioNr>1</ActiveRadioNr>
<Technique>SO2R</Technique>
<StationType>R1</StationType>
<IsTransmitting>False</IsTransmitting>
<IFFrequency>8215000</IFFrequency>
</RadioInfo>
</pre>

===Antenna direction===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program.
|-
| station
| The ID of the station.
|-
| radio
| The radio associated with the rotator.
|-
| go
| True if the rotator should be turned.
|-
| stop
| True if the rotator should be stopped if it is turning.
|-
| azimuth
| The direction to turn the rotator if go is True.
|-
| frequency
| The transmit frequency of the specified radio.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<Rotator>
<logger>DXLog v2.4.13</logger>
<station>STN1</station>
<radio>2</radio>
<go>True</go>
<azimuth>252</azimuth>
<frequency>2800200</frequency>
</Rotator>

</pre>
<pre><?xml version="1.0" encoding="utf-8"?>
<Rotator>
<logger>DXLog v2.4.13</logger>
<station>STN1</station>
<radio>2</radio>
<stop>True</stop>
<frequency>2800200</frequency>
</Rotator>
</pre>

===Callsign lookup===

Sent either when callsign in entry row is changed or when space or tab is pressed.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program.
|-
| contestname
| The name of the contest.
|-
| mycall
| Station's call
|-
| band
| Current band
|-
| txfreq
| Transmitter frequency
|-
| operator
| The call sign of the logged in operator
|-
| mode
| Operating mode
|-
| call
| Call entered in the logging field
|-
| countryprefix
| DXCC entity prefix
|-
| wpxprefix
| WPX prefix
|-
| azimuth
| Short path antenna direction
|-
| distance
| Distance in km
|-
| stationid
| The ID of the station sending the datagram
|-
| stationtype
| The role of the station sending the datagram; R, R1, R2, M, or R+
|-
| period
| Contest period
|-
| reason
| Reason for transmission; SpaceOrTab or CallChanged
|-
|}

Example message:

<pre><?xml version = "1.0"?>
<lookupinfo>
<logger>DXLog v2.4.20</logger>
<contestname>DARC-WAEDC-CW</contestname>
<mycall>K1XM</mycall>
<band>20</band>
<txfreq>1400200</txfreq>
<operator></operator>
<mode>CW</mode>
<call>E7DX</call>
<countryprefix>E7</countryprefix>
<wpxprefix>E7</wpxprefix>
<azimuth>54</azimuth>
<distance>6824</distance>
<stationid></stationid>
<stationtype>R</stationtype>
<period>1</period>
<reason>SpaceOrTab</reason>
</lookupinfo>
</pre>

===Spot===

Sent for every incoming spot from the DX cluster that is valid for the current contest.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| Application sending the message.
|-
| StationName
| The station issuing the broadcast.
|-
| dxcall
| The callsign of the spotted station.
|-
| frequency
| Frequency in kHz with decimal sign of the PC's current locale. (sic)
|-
| spottercall
| The callsign of the spotter. Station name if locally spotted or result of a logging operation.
|-
| timestamp
| Spot time in format yyyy-MM-dd HH:mm:ss
|-
| action
| add or delete.
|-
| mode
| actual or guessed mode of the spot in capitals.
|-
| comment
| The comment section of the spot.
|-
| status
| Spot status. Valid values are "dupe", "double mult", "single mult", and "new qso".
|-
| statuslist
| Same as status
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<spot>
<app>DXLog.net</app>
<StationName>CONTEST-PC</StationName>
<dxcall>E7DX</dxcall>
<frequency>14022.3</frequency>
<spottercall>SM7IUN-#</spottercall>
<timestamp>2O23-07-15 14:29:37</timestamp>
<action>add</action>
<mode>CW</mode>
<comment>CW 31 DB 42 WPM CQ</comment>
<status>single mult</status>
<statuslist>single mult</statuslist>
</spot></pre>

===Broadcast listener===

DXLog also listens for commands over UDP.

Currently only one command is implemented, <code><radio_setfrequency></code>, which is a QSY command.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| Application sending the command
|-
| radionr
| The radio to be changed. In SO2V radio 2 means VFO B. Optional as of DXLog 2.5.20.
|-
| frequency
| Requested frequency. Both period and comma is accepted as decimal separator.
|-
| mousebutton
| Which mouse button was used to create message, if any. Optional.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<radio_setfrequency>
<app>WaterfallBandmap</app>
<radionr>1</radionr>
<frequency>21022.194</frequency>
<mousebutton>Left</mousebutton>
</radio_setfrequency>
</pre>

==SDR integration==

===HDSDR, OmniRig, and microHAM===

''Contributed by Ingo SM5AJV/SE5E''

Until DXLog offers SDR integration there are still ways to get a waterfall/spectrum display with DXLog.

I have integrated the free SDR software [http://www.hdsdr.de/ HDSDR] with DXLog using
[http://www.microham.com Microham Device Router], 
[http://dxatlas.com/OmniRig/ OmniRig]
and [https://www.autohotkey.com/ AutoHotkey].

As illustrated below I place the HDSDR window at the very top of the desktop with DXLog right below.

I share my transceiver's (an Elecraft K3) antenna with the SDR. The receiver antenna signal from my 
K3's RX-ANT OUT is connected to the input of a 3dB power splitter. The two outputs from the splitter 
are connected RX-ANT IN on the K3 and the SDR Receiver antenna input, respectively. On a K3 you 
need to enable the RX-antenna input to make this to work. An additional benefit with this method 
is that the SDR is protected during transmission. It is a widely used method and is e.g. described 
by Bob N6TV in this
[http://dxlog.net/sw/files/utilities/Adding%20an%20SDR%20to%20an%20SO2R%20Station.pdf presentation].

'''Screenshot of my desktop:

[[Image:Sdrdesktop.png|800px]]

Since both DXLog and HDSDR need to communicate with the radio, you need to "split" 
the CAT communication. microHAM's USB Device Router provides a second, independent, 
CAT port that can be used via HDSDR's omniRig interface.

'''"PORT" Tab on microHamRouter:

[[Image:Sdrmicrohamrouter.png|800px]]

'''OmniRig settings in HDSDR:

[[Image:Sdromnirig.png|200px]]

With this set up, the radio, DxLog, and HDSDR will be fully synchronized. For instance, you can 
click in the waterfall to make the radio QSY, and it is easy to quickly find a clean frequency.

To make the integration even better I use a small AutoHotkey script. The script pulls entry focus 
back to DxLog after clicking on the HDSDR waterfall and in DXLog it allows you to use hotkeys to 
control HDSDR. <code>[Ctrl][Alt]+</code> and <code>[Ctrl][Alt]-</code> zooms the waterfall/spectrum 
in and out, and <code>[Ctrl][Alt]C</code> centers it.

'''AutoHotkey script:

SetTitleMatchMode, 2
#InstallKeybdHook
#IfWinActive, HDSDR
{
F4:: return ; disable F4
~LButton Up::
sleep, 1
Winactivate, DXLog
return
}
#IfWinActive, DXLog
{
^!+:: ControlSend ,, ^{+}, HDSDR
^!-:: ControlSend ,, ^{-}, HDSDR
^!c:: ControlSend ,, {c}, HDSDR
}

The script can be downloaded [http://DXLog/sw/files/utilities/dxlog_hdsr.ahk here].

If you start two instances of HDSDR with two different SDR you can even have two waterfalls 
running at the same time.

I have not yet found a way to display cluster spots in the HDSDR spectrum panel. 
But I still find it very useful to check band activity and it allows me to easily find 
a new Run frequency on a crowded band.

===Waterfall Bandmap===

The free waterfall/spot display utility "Waterfall Bandmap" by Steve N2IC is supported by DXLog.

Waterfall Bandmap supports almost any SDR that produce I/Q output either via ExtIO.DLL or a 
sound card; SDRPlay, FunCubeProPlus, HackRF, SDR-IQ, RTLSDR, SoftRock, etc.

A zip file with an executable binary and a Microsoft word document with installation and 
configuration instructions can be found here: https://groups.io/g/waterfallbandmap/files

If you are not a member of the support forum group, you need to apply for membership to download. 
Membership is free.

[[Image:Waterfallbandmap.png]]

The SDR can be connected either to a separate receive antenna, an external receiver output on 
your transceiver or to an IF output, should your transceiver have one. If connected to an antenna, 
keep in mind that you may need protection from the transmitter such as a T/R relay or a passive level limiter.

Please refer to Waterfall Bandmap's documentation for setting it up with your SDR.

Waterfall Bandmap needs two information feeds over UDP: Radio information and spot information. 
Both are provided as UDP broadcast by DXLog.

The default port for both is 13063 and this needs to be set in DXLog's Network configuration panel. 
If Waterfall Bandmap runs on the same computer as DXLog, the broadcast address can be left at the default 127.0.0.1.

[[Image:Setbroadcastportsforwfbandmap.png]]

Clicking on the waterfall display can set the frequency of DXLog. (Left click sets VFO A, right click sets VFO B.) 
To enable this functionality, check the option <code>Options|Broadcast|Receive Broadcasts</code> 
Also make sure "UDP broadcast listener" includes port 13064 in the network settings panel.

The radio information feed needs to be enabled by checking the <code>Options|Broadcast|Radio information</code> option

[[Image:radiobroadcastenable2.png]]

and the spot feed needs to be enabled by checking the <code>Options|DX Cluster|Send spots to SmartSDR</code> option.

[[Image:Enablesendspotstosmartsdr.png]]

==Time synchronization==

In a multi-station setting, the time needs to be accurately synchronized across all networked PC.

Windows' built in time synchronization is very crude and for a PC with poor clock stability the 
inaccuracy of the clock may be up to a minute. Which of course is not acceptable for contesting.

DXLog has built in support for time synchronization as described in the [[Menu Options#Configure network|Configure network section]].

Due to Windows' security system, this however requires all except the PC running as time server to 
run DXLog with elevated permissions. There is unfortunately no way around this inconvenience.

An equally accurate and less intrusive method is to use a standalone time synchronization application on each networked PC. 
This will keep each PC's clock accurate within a fraction of a second.

Contrary to a solution built into a logger it also has the great benefit of being an "install and forget" solution.

A popular application is Dimension 4 by Thinking Man Software. It is free for personal use and 
can be downloaded here: https://dxlog.net/sw/files/utilities/d4time531.msi

It runs in the background and only shows up as a tiny icon in your system tray. 
You hover the mouse above the icon to check status and right-click to open and change settings.

:::[[image:dimension4tray.png|50px]]

After installation a brief configuration is required.

First of all, allow the application to disable Windows' time service and to modify your system clock.

For maximum accuracy, select a time server geographically close to your location. 
When in doubt, you can always add the global server "pool.ntp.org" to the list and use that. 

There are also national and continental pools of time servers. You can find them here https://www.ntppool.org.

[[image:dimension4b.png]]

Make sure the check boxes "Load Dimension 4 at startup", "Start minimized", "Hide when minimized", 
and "Display icon in tray" are all checked.

[[image:dimension4advanced.png]]

Click the Advanced button and also make sure the option "Use the selected server" is selected.

Make sure the application reports a successful connection to the selected time server. 
From here on, you can basically forget the application. 
It will silently start with your PC and always keep its time accurate.

==Disabling USB power management==

In the interest of saving energy, Windows habitually power down USB interfaces 
when it believes there is inactivity. Some USB-to-serial and USB audio devices 
respond poorly to being suspended or powered down so as a rule this "feature" should 
be disabled when used in a ham radio environment.

There are two places where this functionality needs to be disabled; the device driver 
and Windows' energy management.

To disable it for each USB interface and device, open Windows settings. (Click the Windows 
icon in the lower left corner and then chose the cogwheel.) Type ''device manager'' and
select the result.

[[image:devicemanager-c.png|none|frame]]

This opens up a new window, Windows' Device Manager.

[[image:devicemanager2b.png|none|frame]]

For '''every''' USB interface component (there may be many), COM-port, and audio device, 
and '''uncheck''' the option ''Allow the computer to turn this device off to save power''.

The devices you are looking for are in the categories: ''Ports (COM & LPT)'', 
''Sound, video and game controllers'', ''Universal serial bus controllers'',

Note that some devices may not have a ''Power Management'' tab.

[[image:usbdevicemanager.png|none|frame]]

The next step is to disable Windows ''Selective suspend'' feature for USB interfaces.

Go back to Windows Settings and type ''edit power'', click the appearing ''Edit power plan'' menu entry.

[[image:editpowerplan2.png|none|frame]]

This should open the window below, the plan editing panel.

[[image:editplansettings.png|none|frame]]

Click ''Change advanced power settings''. Scroll down to ''USB settings'' and make 
sure ''USB selective suspend setting'' is '''disabled''' for all situations.

[[image:Advancedsettings.png|none|frame]]

To prevent audio devices from becoming unreachable or going into sleep mode you should also 
disable exclusive access. While changing this, also make sure all audio enhancements are disabled.

You reach the detailed audio device settings by entering Windows settings, search for Control panel, 
and in the Control panel view, select Hardware and audio, and then Sound.

[[image:Audiodevice.png]]

Reboot your computer to make sure all settings are recognized by Windows.

==Interlock and inband operation==

In contest station terminology, the term ''Interlock'' refers to a technical solution preventing 
more than one station from using a shared resource, typically an antenna, at the same time.

The most common use for interlock is for inband operation. Inband operation means to have multiple 
transmitters on a single band, interleaving their transmissions. Sometimes on a split-second basis.

As long as you never have more than one transmitter active at any time, the majority of contests allow 
an unlimited number of transmitters and receivers on a single band for multi-operator categories. 
This fact is used by most big contest stations.

For an inband solution to be effective, each station must be able to receive while the 
other station transmits. This means it requires a separate, high performance receive antenna 
with very good isolation from the transmitter antenna. The most common way to 
achieve this is physical separation and geographic orientation to minimize the situations 
when they will radiate/listen in the direction of the other antenna.

For a station operating in the M/M, M/S, or M/2 category, inband operation can boost the points 
per hour performance significantly. It is also a lot more fun.

However, as with everything else, it comes at a cost. An efficient inband solution has:

* A high performance receive antenna for each operated band(s) with very good isolation from the transmitter antenna.
* A fail-safe antenna switching hardware.
* Interlock-capable keyers and/or station controllers.
* An interlock-capable contest logging software

A typical inband configuration can be seen in the illustration below.

[[image:inbandconcept-trx.jpg|800px]]

DXLog offers a software-based interlock which can be configured in a variety of ways, e.g. based on frequency 
band, operating mode, or station role. It supports an unlimited number of stations interlocking each other 
using a great variety of strategies.

The interlock relies on UDP networking and is overlaid on the communication for multi-station logging. 
UDP networking has the benefit of speed and low latency but is, unlike TCP, susceptible to packet loss. 
This means that a '''wired LAN''' is a necessity for any station using interlock. 
For the same reason, it is also not recommended to run interlock over e.g. VLAN/VPN link for 
geographically distributed stations.

A software interlock is not 100% reliable. Computer or software malfunction, networking issues such as packet 
loss, etc. can cause interlock to fail, even if only momentarily.

For this reason it is necessary to also accompany a software interlock with a fail-safe '''hardware''' interlock. 
Without hardware supported interlock you run the risk of not only violating contest rules but also cause serious equipment damage. 
Some contests, such as CQ WW, explicitly requires hardware interlock when using multiple stations on the same band.

There are many designs and even commercial products available for hardware interlock. 
One example of a simple but effective two station hardware interlock which also supports 
power amplifier sharing can be found [https://sm7iun.se/contest/inband/ HERE].

The purpose of this section is to describe steps of setting up a basic two station in-band solution with 
DXLog and microHAM keyers. The microHAM keyers are not mandatory but offers a much better user experience 
and removes the need for additional hardware.

'''Pro tip:''' Consider checking <code>Options|Networking|Allow other stations to abort sending</code> 
which will allow your partner station to interrupt your transmission with <code>[Shift][Esc]</code> in 
critical situations. Be careful though, the use of this function requires good judgment to avoid violence.

===Networking===

Open the networking configuration panel with <code>Options|Configure network</code> and make sure each 
station has a unique name and that only UDP networking is enabled.

Make sure the two stations use the same broadcast IP address and that it is in line with your LAN's 
configuration. Pressing the <tt>Default</tt> button is a good way to ensure this.

Make sure the menu option <code>Options|Enable network</code> has a checkmark.

[[image:inbandnetworkrun.png|left|frame]][[image:inbandnetworkinband.png|none|frame]] 

===DXLog Interlock configuration===

First of all, make sure that the <code>Options|Interface specific options|Prevent TX if another radio is on same band</code> 
is '''not''' enabled. This option completely prevents transmission if more than one networked station is set to the same band 
and the whole idea with inband is to have exactly that.

Next, activate software interlock on both stations using the menu option <code>Options|Networking|Software interlock</code> 
or by typing the commmand <tt>ILOCKON</tt>.

[[image:inbandinterlock2.png|none|frame]]

There are multiple options for configuring the interlock. In a simple set up with only two stations, the topmost 
option ''Same band from status list'' is a good choice. This option will prevent more than one station transmitting 
on the same band, regardless of mode.

In an environment with many stations (such as a multi-operator-multi-transmitter station) it is 
recommended to use the bottom option to only interlock with one or several named stations. 
This will reduce both LAN traffic and inband operation latency. This is particularly important when 
running parts of the DXLog network over high latency links such as VLAN/VPN or if some stations (albeit not 
part of the interlock cluster) are connected via Wi-Fi.

For more advanced scenarios you can also use interlock based on mode or station type (e.g. Run 1, Run 2, Mult, etc.).

The "status list" listing the networked DXLog stations is displayed in the ''Status Window'' which is opened 
with <code>Windows|Status window</code> or <code>[Alt][J]</code>.

[[image:inbandstatuslist2.png]]

DXLog also offers great flexibility when it comes to interlock strategy. The most straightforward and 
most commonly used is ''First one wins''. This is also typically the behavior of "unintelligent" 
hardware solutions when not assisted by software. With this strategy, the station starting to transmit 
first can not be interrupted and always gets to finish its transmission.

[[image:inbandinterlockoptions.png]]

With a ''Last one wins'' strategy, the transmitting station can be interrupted. A carte blanche permission 
to interrupt all transmissions by the other station may however be counterproductive in a real contest situation.

For this reason, DXLog offers additional control of which transmit actions can be interrupted and which can not. 
This is a powerful tool but requires both operators to be aware of it and may require 
practice before fully effective.

[[image:inbandstrategyexceptions.png]]

''F1'' through ''F7'', ''PLUS'' and ''INS'' refers to DXLog's standard messages. ''KEYB'' means a free text transmission 
from the keyboard using the <code>[Alt][K]</code> function and ''MAN'' means manual transmission using either paddle 
break-in or a footswitch.

For CW, DXLog recognizes paddle break in from a K1EL Winkey-compatible keyer as described in the [[Menu_Options#Winkey_Configuration|Winkey configuration section]].

Since DXLog recognizes a footswitch connected to a microHAM device, this is a recommended approach for phone. 
It is also possible to connect a footswitch to the DSR pin (pin 6) on a physical COM-port on the PC, but today 
few PC have such a port and it also requires additional circuitry.
Details on how to do this is available [[Additional_Information#Connecting_a_footswitch|HERE]].

===microHAM configuration===

Open the microHAM device configuration panel with <code>Options|microHAM device configuration</code>.

[[image:Mk2r-new9.png|none|frame]]

Check the option ''Enable TX lock/unlock''. This will do two things; it will enable DXLog to prevent 
transmission and and it will make DXLog aware of the microHAM device's PTT status. The latter is particularly 
important since it means DXLog will recognize PTT assertion not only by a footswitch connected to the 
microHAM device but also by the built-in Winkeyer (requires microHAM USB Device Router version 9.3.0 or later) 
'''Paddle-based break-in in an inband solution is currently unique for microHAM with DXLog.'''

'''Important:''' Making DXLog "PTT aware" means that care has to be taken in how PTT is set up. If you, for instance, 
enable DXLog PTT for the voice keyer, this will create a self-reinforcing feedback loop and PTT will thus never drop.

Check the option ''Dual radio device'' if you are using a u2R, MK2R, or MK2R+, otherwise, leave this unchecked.

Check the option ''Device without CAT interface'' if the device lacks a CAT interface (like the u2R) 
or if its CAT interface is not connected to the radio. This option will make sure the e.g. keying and 
audio routing is always set correctly in line with the operating mode (Voice, CW, or RTTY).

===Operating===

Inband operation requires a fair amount of training and it is a good idea to define and agree 
on general rules for operation, such as hand signals for challenging QSO, beforehand.

There are more than enough YouTube videos of inband operators yelling at each other.

The operating tactics may have to be adjusted during the contest. If Run is slow, 
doing S&P on the inband station can increase the points per minute significantly. 
However, if Run is strong, an overly active inband operator doing S&P, but not working 
multipliers, may actually reduce the station's points per minute significantly.

Real-time interlock status is shown in the ''Radio status'' window, which is opened with 
<code>Windows|Radio status</code>.

[[image:inbandblocking.png]] [[image:inbandblocked.png]]

For Phone contesting, you typically rely on footswitches for PTT and the option 
<code>Options|Networking|Show QSO status when blocking</code> makes the blocking 
station send a more helpful blocking cause than ''MAN''.

With this option enabled, the blocking station will instead send ''CQ'', ''QSO'', or ''EXCHANGE'' 
as blocking cause, determined by cursor location and entry field content at the locking station.

Further reading can be found in the [[Menu_Options#microHAM_device_configuration|microHAM device configuration]] and [[Menu_Options#Networking|Networking]] sections.

==Connecting a footswitch==

To free up both hands in Phone contesting, a footswitch PTT is a great help.

Also, to use interlock in Phone contesting, a footswitch is mandatory.

There are two basic ways to interface a footswitch with DXLog; via a microHAM device (which is the recommended solution) 
or directly connected to a physical serial port on the PC (which very few PC have today).

The connection of a footswitch to a microHAM device is very straightforward and by checking the ''Enable TX lock/unlock'' 
in the ''microHAM device configuration'' panel, it is recognized by DXLog.

Lacking a microHAM device, it is also possible to use the computer's DB9 RS-232 serial port connector, providing it has one.

The required steps to do this are:
* Connect a 10k resistor between DB9 pin 6 and pin 7.
* In the port's settings (<code>Options|Configure interfaces</code>) set DTR (pin 4) to ''Always On'' and RTS (pin 7) to ''Always Off'' for the port.
* Connect the footswitch between DB9 pins 4 and pin 6. '''Important:''' Neither pole on the footswitch must be connected to ground.
* In the radio's configuration panel, check ''use CAT PTT command on Phone'' and set ''Footswitch (pin 6)'' to ''PTT''

==Support for CC Cluster==

CC Cluster is today the main choice for contest use.

It offers a high quality, database-verified, flow of skimmer spots and a rapid 3-minute respotting period for skimmer spots.

It also publishes unique spots from less common locations which are valuable for DX chasers or as contest multipliers.

To make use of the display of own spot in the world map, make sure to issue the command '''<tt>SET/OWN</tt>''' to the cluster node. 
This setting is persistent and only needs to be done once.

A list of cluster nodes that runs CC Cluster can be found here: [https://www.dxcluster.info/telnet/index.php?software=CC%20Cluster CC Cluster nodes]

A description of the command line syntax can be found here: [http://bcdxc.org/ve7cc/ccc/CCC_Commands.htm CC Cluster command syntax]

A convenient software for setting up filters etc. can be found here [http://www.bcdxc.org/ve7cc/default.htm#prog CC User]

[[Image:Ccclustersspotflow.png]]

==Support for AR Cluster 6==

With the author tragically SK, AR Cluster is no longer under development but still available as an executable binary.

In its standard configuration, AR Cluster offers no consolidation of skimmer spots meaning a very high flow of spots 
that can become extreme during a major contest weekend.

With the advent of skimmers, the traffic on the DX Cluster has risen dramatically. Even though CW skimmers are generally 
quite reliable, the absolute number of busted spots can be quite high during a busy contest.

Jose CT1BOH has developed an algorithm for evaluating spot quality which is included in version 6 of AR Cluster. 
Today many cluster nodes runs this version and thereby offer this mechanic. 
A complete list can be found here: [http://www.dxcluster.info/telnet/index.php?software=AR-Cluster AR Cluster nodes]

To enable the functionality on a cluster node running AR Cluster 6, the command

<tt>'''SET DX EXTENSION SKIMMERQUALITY'''</tt>

needs to be issued to the cluster node. The easiest way to do this in DXLog is via <code>[Alt][T]</code>. 
This setting will be remembered at subsequent logins.

The quality of the spots is indicated by a character ("tag") in the last column of the comment field and, 
in some cases, a corrected callsign within parenthesis. This syntax is recognized by DXLog and can reduce the 
number of bad spots in your bandmap.

The CT1BOH skimmer quality algorithm is based on three parts:

; Validation : When a callsign is first spotted, it is tagged with "?" in the last column of the spot's comment field. If the callsign of an unverified spot closely resembles an already verified one on the same frequency, the verified callsign is provided within parenthesis in the spot's comment field. When two or more skimmers agree on the spot, it is considered verified and the tag becomes "V".

; Frequency : When a verified spot appears more than 0.35kHz off its verified frequency, the spot is tagged "Q" for QSY. Once verified, this becomes the new verified frequency and it is tagged "V".

; Probability : The algorithm checks uncertain spots for resemblance with already verified spots and spots at or near the same frequency. If the resemblance is high enough, the spot is considered busted "B" and the corrected callsign is provided within parenthesis in the spot's comment field.

Below you can see an example of the spot flow from W9PA-4 with skimmer quality enabled. 
The flow contains one unverified and one busted spot.

[[image:spotquality.png]]

DXLog's policy for spots with CT1BOH skimmer quality tags is the following:

: '''V''' - Accept spot.
: '''Q''' - Accept spot.
: '''?''' - Accept spot. Use corrected call when provided.
: '''B''' - Accept spot if corrected call provided. Else ignore.

DXLog recognizes the skimmer quality tags but consolidates them for consistency 
with other cluster nodes' quality tags and to minimize confusion when mixing spot flows. 
The legend is:

: '''?''' means a spot with ? This is an unreliable spot.
: '''P''' means a spot with Q or B with correction. This is a fairly reliable spot.
: '''V''' means a spot with V. This spot is considered validated.

This basic policy can be modified by using additional filters at the cluster node end. Some examples are:

: <tt>'''SET DX FILTER NOT SKIMBUSTED'''</tt> - Do not send busted spots at all
: <tt>'''SET DX FILTER NOT SKIMQSY'''</tt> - Do not send QSY spots
: <tt>'''SET DX FILTER SKIMVALID'''</tt> - Only send verified spots
: <tt>'''SET DX FILTER NOT SKIMUNKNOWN'''</tt> - Do not send unreliable spots
: <tt>'''SET DX FILTER SKIMMER'''</tt> - Do not send manual spots

You can also compose more complex filters such as:

: <tt>'''SET DX FILTER SKIMVALID OR SKIMBUSTED OR NOT SKIMMER'''</tt>

This can be a good filter for most contests. It will will only provide valid or busted skimmer spots together with manual spots. 
It is safe to receive busted spots since DXLog will ignore them if there is no corrected callsign included. 

For assisted operation in serious contesting you however need to allow also unknown spots since weak stations spotted 
only by one or a few skimmers may never reach validated status. You do this by adding <tt>'''OR SKIMUNKNOWN'''</tt> to the filter.

Both the bandmap and the DX cluster announcement windows have the option to display the spot quality tag. 
These windows will show two additional tags; L and C. L stands for local spot, created by yourself or one of your team members. 
C stands for corrected, i.e., a B or ? spot where a corrected call has been included in the spot's comment field.

The AR6 filtering syntax offers a lot of flexibility. Another example:

: <tt>'''SET DX FILTER (SKIMVALID OR NOT SKIMMER OR ((SKIMQSY OR SKIMUNKNOWN) AND (CTY <> K AND CONT <> EU )))'''</tt>

will provide only validated and human spots except if they are from outside the US and EU.

If you get lost in the filter settings you can always reset with : <tt>'''SET DX DEFAULT'''</tt>.

Some more guidance on how to work with filters on AR-Cluster nodes can be found in [http://dxlog.net/sw/files/utilities/AR_Cluster_v6_User_Manual.pdf this document].

==Support for DXSpider==

DXSpider is the by far most dominant DX cluster software but has historically not been a good choice for contesters. 
The reasons for this include: Long respotting time, lack of pass function for own spots, and suppression of spots from a single skimmer.

The good news is however that the author Dirk G1TLH has worked hard to address these aspects of the otherwise brilliant software.

From '''version 1.57 release 440''' the respotting time is now 3 minutes and there is a <tt>SET/SEEME</tt> command that passes all spots 
without consolidation of your own callsign.

So if your favorite cluster node is not running this version, ask the owner to upgrade asap.

Yet another reason for its popularity is its extreme resource-efficiency which allows it to run virtually 
any Linux capable hardware, including a $20 Raspberry Pi Zero.

A list of all DX cluster nodes running DX Spider can be found here: [https://www.dxcluster.info/telnet/index.php?software=DX%20Spider DX Spider cluster nodes]

[[image:dxspiderflow.png]]

DXLog recognizes the <tt>Q:#</tt> skimmer quality tag in the comment field and converts them into "CT1BOH-like" quality 
tags that can be displayed in DXLog's bandmap. The legend is:

: '''?''' means a spot with Q:1, i.e. heard by only one skimmer. This is an unreliable spot.
: '''P''' means a spot with Q:2, i.e. heard by only two skimmers. This is a fairly reliable spot.
: '''V''' means a spot with Q:3 or higher, i.e. heard by several skimmers. This spot is considered validated.

Since a DXSpider node currently needs to be specially configured by the owner to publish Q:1 spots, very few do this. 
Also, since DXSpider lacks busted call detection, the the quality of the spot flow will suffer if this is done.

There is a wealth of information to be found on the [http://wiki.dxcluster.org/index.php/Main_Page DXSpider wiki].

==Support for N2WQ Cluster==

Introduced in late 2025, Rudy N2WQ has developed the first new DX cluster node software in decades.

The N2WQ-2 cluster has some unique features like a more advanced callsign validation than 
AR 6 and propagation estimation tags embedded in the spot comments. An example can be seen below.

[[image:n2wpspotflow.png]]

When you connect to dxc.n2wq.com port 8300 and you have set your 4-digit Maidenhead grid (SET GRID), there 
will be a single character just before the DX’s grid locator. This character is the path prediction glyph.

It is a crowdsourced, real-time estimate of how reliable the path is between you and the DX on that band right now, 
based on recent on-air propagation reports from RBN and PSKreporter. Its values and meaning are:

: > High: Strong path. If you can hear them, you should be able to work them.
: = Medium: Decent path. Workable with normal contest/DX technique.
: < Low: Weak path. Possible, but expect repeats, timing, and patience.
: - Unlikely: Marginal. Try only if it’s rare/needed, or you have a strong station advantage.

A missing glyph means insufficient data to estimate the path.

the glyph is mode-aware. A path that looks great for a very sensitive mode (FT8) can look 
more moderate for a less sensitive one (SSB).

You can filter spots by path reliability using the PASS/REJECT PATH command.

It is important to be aware that the glyph does not know:

: Your antenna gain/pattern, height, or takeoff angle
: Your transmit power and duty cycle constraints
: Your operating technique (timing, split discipline, pileup strategy)
: Short-lived phenomena the network has not yet “seen” such as sporadic E or aurora.

The cluster ingests upwards of 50,000 CW, FT, RTTY, and WSPR spots per minute. To compare different modes 
fairly, the system normalizes reports onto a common “FT8-equivalent” scale (so a CW SNR can be compared 
to an FT8 SNR).

Your grid and the DX grid are mapped into small geographic cells and the cluster calculates propagation 
at two levels:

: Fine (local): what’s happening close to your area (~180 miles).
:: On averages there are about 90,000 DE/DX pairs being tracked
: Coarse (regional): what’s happening in the broader region around
:: you (~480 miles). On average, there are about 30,000 DE/DX pairs.

If there isn’t enough local data, the system leans more on regional behavior. 
If there’s plenty of local data, it uses that more heavily.

Sometimes you can hear them better than they can hear you (or the reverse) due to noise 
floors, antennas, geography, or ionospheric effects. The system tracks both:

: Receive direction: DX to you (can you hear them?)
: Transmit direction: you to DX (can they hear you?)

It combines these into one “path reliability” estimate, weighting receive a bit more 
because if you can’t hear them, you can’t work them.

Propagation changes fast, so older reports get discounted using a half-life (data fades 
in influence over time). Typical behavior by band:

: Low bands (160/80m): slower changes (longer half-life)
: Mid bands (40–20m): medium pace
: High bands (15–6m): fast changes (shorter half-life)

In practice, this means glyphs can shift in minutes on 10m/6m, and more slowly on 80m/160m. 
Also, new openings take time to show up. A "insufficient" can simply mean “the path just opened 
and the cluster hasn’t collected enough recent reports yet.”

Your local noise floor heavily affects what you can receive, so the cluster lets you tell 
it what your noise environment is. This mainly tunes the receive-side expectation (DX to you).

Set it with SET NOISE SUBURBAN. Available profiles per ITU:

: QUIET: very low noise, rural/remote
: RURAL: mild noise
: SUBURBAN: typical neighborhood QRM
: URBAN: elevated noise, dense housing
: INDUSTRIAL: severe noise

If you don’t set it, the system may assume a quieter environment than you actually 
have, and your receive-side glyphs can look too optimistic.

Treat the glyph as a real-time probability hint that helps you spend your operating 
time where the odds are best. When you see > on a needed multiplier, move fast. 
When you see -, be intentional about whether it’s worth the time. 
And when you see a space, fall back to classic DX/contest instincts and your own ears.

The N2WQ cluster also offers spot quality tags between the DX grid and the time.

A quality (in terms of callsign reliability) tag can be V, P, S, C, or ? where V means validated, 
P highly likely, S less likely, C corrected, and ? unsure.

The propagation and quality tags can be displayed in the bandmaps and the DX cluster announcement window.

DXLog recognizes the skimmer quality tags but consolidates them before display for consistency 
with other cluster nodes' quality tags and to minimize confusion when mixing spot flows. 
The legend is:

: '''?''' means a spot with ? or S. This is an unreliable spot.
: '''P''' means a spot with P or C. This is a fairly reliable spot.
: '''V''' means a spot with V. This spot is considered verified.

==Interacting with WSJT-X==

Important: When in a DXpedition/multi-station setting, always use local host 127.0.0.1 as the 
broadcast address to prevent packets being picked up by other stations in the network. 
Also, enabling the creation of local spots from decodes may overwhelm DXLog.

DXLog can add QSO performed with WSJT-X to its log. Note that this functionality only works 
for contests with grid as the first and only exchange or for DXPedition type logs.

DXLog can also create local spots from WSJT-X decodes by checking 
<code>Options|Broadcast|Spot WSJT-X decodes</code>.

To enable logging of WSJT-X QSO, set up WSJT-X to broadcast information:

[[image:Wsjt-x-udp.png]]

[[image:Radiobroadcastenable3.png]]

Activate DXLog's UDP listener by checking <code>Options|Broadcast|Receive broadcasts</code> and set 
the same port number as in WSTJ-X in DXLog's network configuration panel.

[[image:Dxlog-udp.png]]

==Using Winkey FSK==

Winkey FSK is not natively supported by DXLog's digital mode engines MMVARI or MMTTY but 
Rafal EI6LA has developed a plugin for MMTTY that makes this possible.

You can find it [https://github.com/RafalLukawiecki/WinKeyerMMTY here].

==Interfacing with LogHX==

Christian F8GHE has prepared a guide on how to do this.

You can find it [http://dxlog.net/sw/files/utilities/DXLOG-LogHX_UDP-config_v2.pdf here].

==Self-spotting==

More and more contests allow spotting your own station on the DX cluster.

DXLog supports this, even when operating unassisted, as long as you connect to the cluster.

DXLog has three mechanics for self-spotting.

DXLog blocks self spotting unless specifically allowed in the contest rules. 
Should you find that DXLog incorrectly allows or blocks self-spotting, please make 
the development team aware via the support reflector.

* The <tt>$SPOTME</tt> macro command. This macro will create a cluster spot of the station's
: call at the earliest 15 seconds after being invoked the first time on a new frequency.
: Thereafter it will spot as frequent as allowed by the contest. If the contest rules do not
: specify a minimum period, 10 minutes will be used.

* Checking the menu option <code>Tools|Data entry|Run F1 message self-spots when permitted</code>.
: Works exactly like the <tt>$SPOTME</tt> macro command but is triggered by sending the
: Run F1 message which happens when pressing <code>[Enter]</code> with an empty entry line
: in Run, pressing <code>[F1]</code> in Run, or with Auto-CQ.

* Clicking the menu item <code>Commands|Self-spot</code> or pressing its shortcut key <code>[Ctrl][S]</code>.
: This will immediately create a spot of the station's call but no more often than
: every two seconds to avoid accidental multiple spots.

==DXpedition use==

DXLog is a popular choice for top tier dxpeditions. Below we have collected advice based on experience 
on how to best use DXLog in a dxpedition setting.

* Use client/server networking between stations. Never use UDP over Wi-Fi or WAN links.
* Use the "Minimal data" option in ADIF export to save on satellite link cost.
* For Club Log real time upload, use [[https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads Club Log's upload app]]
* Club Log truncate QSO time to minutes so to avoid creating dupes when mixing manual and real time
: upload to Club Log, check "QSO time in minutes" when doing ADIF export.
* Use the "Minimal data" option in ADIF export to save on satellite link cost.
* Follow [[Additional_Information#Interacting_with_WSJT-X|the instructions]] to log QSO made with WSJT-X and MSHV.
* Check <code>Options|Broadcast|Spot WSJT-X decodes</code> to make decoded calls appear in e.g., DX cluster announcements.
* You can extend the number of digits in the QSO count with <code>Options|Log|QSO number digits</code>

==Beacon spots on DX cluster==

Although propagation measurements based on FT8 communications has reduced the
value of beacons, there are still hundreds of them in operation.

Identifying with CW, they are typically reported on reported on the DX cluster.

When beacon spots are received by DXLog, they are always displayed in the bandmap. 
In DXLog, beacon spots are recognized by having a trailing <tt>/B</tt>.

The DX cluster announcement window never shows or counts beacon spots.

Beacon spots can be enabled and disabled in the cluster node.

For CC Cluster, the commands are <tt>SET/BEACON</tt> and <tt>UNSET/BEACON</tt>.

For DXSpider, command is part of the <tt>SET/SKIMMER</tt> command where <tt>SET/SKIMMER</tt> 
or e.g., <tt>SET/SKIMMER CW BCN FT RTTY</tt> will pass beacon spots and <tt>UNSET/SKIMMER</tt> 
or any <tt>SET/SKIMMER</tt> listing modes but not BCN will block them.

AR 6 cluster nodes always pass beacon spots when skimmer spots are enabled. They cannot be disabled.

Additional Information

2026-03-31T11:07:23Z

Sm7iun: /* Real time upload to Club Log Live Stream */

==Using alternative configurations==

Window positions, coloring and general look and feel is saved in each log file but all other settings such as 
radio control, keying, and networking is saved in a common, contest-independent configuration file.

By default, the configuration file name is <tt>DXLog.net.config</tt> and it is located in the <tt>%appdata%\DXLog.net</tt> configuration folder.

This folder is also reachable via the <code>File|Open configuration folder</code> menu item.

[[image:configfolder.png]]

DXLog can be made to use an alternative configuration file with the command line option <tt>-cfg=<filename></tt>.

A convenient way to use this option is to create a separate Windows desktop shortcut including the command line option 
and give it a meaningful name.

[[image:Desktopshortcut.png]]

The command line option is simply added to the end of the Target text box in the shortcut's properties. 
Double-clicking the icon will start DXLog with the alternative configuration which will also be remembered between sessions. 
In the picture below the target of the shortcut is

[[image:Desktopshortcutconfig.png]]

'''Important:''' If you want to use an alternative configuration, do not just modify the desktop shortcut created at installation 
since this shortcut will be deleted when you upgrade DXLog. Instead make a copy, rename, and add the command line option. 
You should keep the command line option outside the apostrophes, like this

<tt>"C:\Program Files (x86)\DXLog.net\DXLog.net.exe" -cfg=SO2R.config</tt>

==Using a number server==

For contests involving serial numbers you need to secure that the sent number and the (slightly later) 
logged serial numbers are the same. In a straightforward SO1R or SO2V scenario, serial numbers are simply 
chronological but in more complex station configurations such as Multi-single or Multi-2 with inband, and 
advanced SO2R, QSO can be interleaved and requires a central source source of serial numbers together 
with a mechanic to protect an already sent serial number from re-use by another radio.

In DXLog this is achieved with a central number server. A number server can be used either 
by a single instance of DXLog (for SO2R) or by multiple stations on the same LAN.

The use of a number server involves three, natural, steps:

* Activating the server on a single station
* Making sure all stations use it
* Verifying functionality, making sure serial numbers are correctly reserved

The number server is activated in the <code>Options|Configure network</code> panel, described [[Menu_Options#Configure_network|HERE]].

[[image:startnumberserver.png]]

Since the server uses a networking socket, <code>Options|Networking</code> must be enabled '''also''' when 
using a single computer in SO2R. In the case of multiple stations, UDP networking or Client-Server 
networking must also be enabled to transfer the numbers over the LAN. For SO2R, this is however not 
necessary. When using Client-Server networking, a client cannot be number server.

There must only be one number server in a local network and all stations using it must have 
<code>Options|Networking|Use number server</code> checked like in the picture below.

'''Important:''' The number client/server functionality is not very robust. 
If you have stations joining/leaving your network or being rebooted, it is 
best to restart DXLog on all stations to guarantee correct function.

[[image:usenumberserver.png]]

The option <code>Block logging if serial number reservation is unsuccessful</code> can be used as an extra precaution 
but is not necessary in SO2R since the communication with the number server does not leave the computer.

There are three methods for reserving a number from the server:

* Checking <code>Tools|Data entry|Space key reserves serial number</code> and using the space key to reserve serial numbers. This is typically used on phone or when operating "old school" with F-keys.
* Checking <code>Tools|Data entry|Insert and F2 messages reserve serial number</code> and letting DXLog automatically reserve a serial number right before $SERIAL sends it. This is the preferred and most straightforward way for CW and digital.
* Adding the $RESERVENR macro to messages like illustrated below. 

These methods can of course also be combined. 

The $RESERVENR macro is "smart" and will only reserve a serial number if the callsign entry field is not empty and a 
serial number is not already reserved. The same goes for the menu items.

[[image:reservemessages.PNG]]

The sign of a serial number being reserved is that it turns red. It then stays reserved (and red) until the 
QSO is logged or the entry line is cleared with <code>[Alt][W]</code>.

An option that can prove useful is <code>Tools|Data entry|Cancel serial number reservation only if callsign field is empty</code>. 
In the case that you send the exchange and realize you got the other station's callsign call completely wrong, a reflex can be to hit 
<code>[Alt][W]</code> and start typing. If this is your habit, this option will prevent you from releasing the 
already sent serial number, thereby avoiding you the trouble to send a new one to the other station.

[[image:reservednumber.png]]

==Networking over internet==

When, for instance, activating a special event callsign it is possible to network multiple DXLog stations over the internet.

'''Pro tip:''' Consider displaying the callsign, message ID, Message text, etc. fields in the ''Network status'' 
window when operating a distributed station. Also, learn to use the gab <code>[Alt][G]</code> and <code>[Alt][J]</code> function.

===VLAN/VPN Solution===

The most secure way for remote networking is to rely on a VLAN (virtual LAN) software. There are several available such as:

ZeroTier https://www.zerotier.com/ 
FreeLan http://www.freelan.org/ 
Player.me https://player.me/ 
OpenVPN https://openvpn.net/

Each VLAN solutions have their own particular set up which is covered in their respective documentations. 
With a VLAN solution, all DXLog configurations are the same as when operating in a regular LAN however with a few exceptions.

One weakness with connections over the internet (a.k.a. WAN), including VLAN solutions, is that they are prone to packet loss. 
Packet loss is disastrous to DXLog's (or any logger's) "standard" UDP networking.

It is therefore essential to use '''only client/server networking over a VLAN'''. 
'''This also means you should never use interlock over an internet connection unless you use a zero packet loss VPN tunnel.'''

ZeroTier is particularly popular since it is free.

Since DXLog is able to mix TCP (client/server) and UDP (peer-to-peer) networking, a distributed station set up should be configured to rely on TCP 
for the wide-area network and UDP for the local network at each station location. Below you will find the station 
set up for the Swedish HQ station SE9HQ in the 2019 IARU HF Championship. The DXLog.net.DXC cluster client was run 
on SK3W-A which distributed spots to all stations over the network. Inband interlock was also used at the SK3W location.

[[image:SE9HQ-network-eng.png|800px]]

Important to note:

* For the server as well as the main clients, ''Server IP'' should be set to the server's VLAN IP address, '''not''' its LAN address.
* The '''server''' should check both "Act as network server" and "UDP network broadcast for multiple stations".
* The '''main clients''' should check both "Connect to network server" and "UDP network broadcast for multiple stations".
* The '''sub clients''' should check only "UDP networking for multiple stations".
* Interlock (which is UDP-based) over VLAN does not work reliably because of packet loss.
: Therefore, it is important to configure any interlock to '''only''' consider relevant operating positions,
: which all must be local. Use the possibility to only consider named stations for the interlock in the software 
: interlock set up. <code>Options|Networking|Software interlock</code> "Custom station ID(s)"
* For a large set-up with many stations connecting as clients to a central server you may overload the server if you also
: distribute spots via all client-server connections. In this case, check the "No spots via client/server" option
: on all stations and use '''local DX cluster connections''' via UDP at each location.
: '''Important:''' Limitations in Windows networking makes client/server networking unreliable beyond 10 station locations.
* Make sure to check <code>Options->Load contest at startup</code> to avoid opening the wrong log after a restart.
* '''Remote commands are not forwarded''' in the network but are executed in the station where they arrive.
: Thus, to clear all logs, disconnect networking on each main client, execute the remote command CLEARLOGNOW on each main client
: to clear the logs of all sub clients and do not reconnect until the server and all other main clients have done the same.

===Port forwarding Solution===

If you are less worried about competitors or government agencies listening in on your contest data, 
it is possible to route the traffic directly over the internet using port forwarding at the server.

'''Important security notice: This solution is not without risk. It offers no security or authentication. 
Any DXLog station running the same contest configuration, knowing the URL or IP address and IP port of the 
server can connect to the server station. There are no means to disconnect a station by force.'''

Also note the comment about '''remote commands''' in the section above.

With a port forwarding solution, the following must be observed:

* '''Server configuration'''
:* Only one of the stations should be configured as the '''server'''.
:* "Connect to network server" should not be checked on this station and
:: "UDP networking for multiple stations" should only be enabled if it is used to
:: communicate with a cluster client or other stations locally on the same LAN.
:: Either use a central cluster connection (uncheck "No spots via client/server")
:: or use one cluster connection per station location (check "No spots via client/server").
:: If one cluster connection per station location is used, make sure they
:: all use different SSID to prevent disconnects, such as E7HQ-1, E7HQ-2, etc.
:: This will ensure the cluster node regards all connections as having the same callsign
:: which is essential for e.g., correctly receiving own spots.
:* The PC acting as server must be configured for a fixed LAN IP address. This is done
:: either by manually configuring the networking settings in the PC to use a fixed
:: LAN IP address, or by setting up the router in the server's LAN to to always allocate
:: the same IP address to it.
:* The internet connection used by the server PC must ''either'' have a fixed public IP address ''or''
:: use dynamic DNS. Otherwise clients will not be able to reliable connect over the internet.
:* The server's TCP/IP port (e.g., <code>9888</code>) must be forwarded to the server by the server LAN's router.
:: Only TCP traffic should be forwarded. DXLog UDP traffic is not carried well over the internet.

:: [[image:serverconfig.png|600px]]
:: '''Example configuration for server for networking over internet'''

::[[image:portforwarding.png|600px]]
::'''Example of port forwarding UI in router'''

* '''All other stations'''
:* All other PC in the multi-station set up should be set up as clients.
:* Over the internet, "Server:" is either the static, public IP address of the server's internet
:: connection (e.g. <code>5.140.211.42</code>) or the dynamic DNS address (e.g. <code>hq.sm7iun.se</code>).
:: Clients connecting over the internet does not have to enable UDP networking and ''should not''
:: enable a server.
:* A client may connect via UDP if it is on the same LAN as the server ''or'' a "main client".
:: A "main client" is a client that connects to the server using the "Connect to network server" option in
:: the networking set up panel. A "main client" acts as a UDP gateway which means that if
:: several computers on a LAN are part of the same multi station set up but the server is located
:: elsewhere, only one computer in that LAN needs to connect as a client and the rest can use UDP.
:* Software interlock is UDP-based and can only reliably be used locally. Never over the internet.
:: If used, make sure the interlock is explicitly limited to local stations. See above for more details.

::[[image:clientconfig.png|600px]]
::'''Example configuration of client for networking over internet'''

* In a multi-station setting it is recommended to enable
: <code>Options|Networking|Block standard messages if no operator is logged on</code>
* Make sure <code>Options|Enable network</code> is checked.
* It is also a very good idea to check <code>Options|Load contest at startup</code> to reduce the
: risk of the wrong contest log file being loaded by any stations.

==Real time upload to Club Log Live Stream==

Note: Club Log truncates QSO time to minutes which means that if you mix real time upload
with manual upload, make sure to check "QSO time in minutes" when creating ADIF export files.

===Club Log Gateway===

The author of Club Log, Michael Wall, G7VJR, has developed a very powerful agent for real time uploads.
It works with all the three major loggers, DXLog, N1MM Logger+, and Win-Test.

It can either be used directly, with a command line user interface, or together with an optional user interface front end.

Information on how to download and configure it can be found [[https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads HERE]]

The Club Log Gateway can either listen to DXLog's native multi-station networking protocol or to the N1MM style broadcast.

To use DXLog's networking protocol, make sure the same port (default 9888) is used in the gateway and DXLog 
and that UDP networking is enabled in DXLog.

It is however recommended to use the N1MM style broadcast since it contains information like logged on operator, etc.

To use N1MM style XML broadcastmake sure the port (default 12060) is the same in the gateway and in the 
QSO broadcast port settings in DXLog's network configuration. Also make sure to se the DXLog port number 
in the gateway to something else than that used in DXLog to avoid QSO duplication.

Also set:

<code>Options|Broadcast|QSOs</code> 
<code>Options|Broadcast|QSOs</code> 
<code>Options|Broadcast|Use N1MM QSO format</code> 
<code>Options|Broadcast|QSO time in minutes only</code>

If you are going to also upload exported ADIF files to Club Log, it is important to also check "QSO time in minutes" 
in the ADIF export configuration to avoid creating virtual dupes, since Club Log does not know seconds.

==Diversity reception==

Diversity means receiving the same signal through two different receive chains, including antenna. 
With two antennas having different characteristics this can give substantial benefits in receiving 
fading and/or weak signals or separating calls in a large pile-up. Particularly on low bands.

DXLog supports diversity operation on a selected number of radio models.

For the supported radios, diversity operation can be toggled on and off using <code>[Ctrl][-]</code> or <code>[Ctrl][Keypad -]</code>.

If enabled via the radio's controls, DXLog will automatically detect diversity operation and enable 
the necessary mechanics. Diversity operation is indicated by a small DIV icon in the frequency 
counter box for the radio's band map.

'''Yaesu FTDX101D

Yaesu calls this feature "Sync" and it has a dedicated button up and left of the main VFO knob. 
Enabling this will make DXLog update both VFO with the same information when grabbing spots. 
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO. 
Since both VFO are kept on the same frequency, split operation is not supported.

'''ICOM IC-7851 and IC-7610

ICOM calls this feature "Tracking" and it can be enabled either via a menu entry or a long press on the "MAIN/SUB" button. 
Enabling this will make DXLog update both VFO with the same information when grabbing spots. 
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO. 
Since both VFO are kept on the same frequency, split operation is not supported.

'''Elecraft K3/K3S/K4

Elecraft calls this feature by its proper name. It is enabled by a long press on the "Sub" button. 
It should be noted that Elecraft's implementation where the main VFO controls both the main and 
sub receivers allows for split operation, i.e. transmitting on a different frequency using VFO B.

==UDP broadcast==

For interaction with other applications, DXLog can broadcast useful information as 
XML datagrams over UDP. 

There are five types of broadcast messages produced by DXLog:

* QSO information. Sent when logging.
* Radio information. Sent at changes as well as periodically.
* Antenna direction information. Sent when rotor control is invoked.
* Callsign look-up information
* Spots

QSO can be broadcasted in traditional DXLog format or in a more N1MM-like format.

Radio information can report SO2V as a single physical radio or as two physical radios, like N1MM.

There is an option to truncate the broadcasted QSO time to full minutes for better 
interoperability with some online services and software such as MSHV.

In addition, DXLog can also recognize QSY commands from Waterfall Bandmap and log QSO done as well as create 
local spots from decodes broadcasted by WSJT-X and its forks.

The broadcasting of QSO and radio related data is enabled using the <code>Options|Broadcast</code> submenu.

The broadcasting of spots is enabled by checking <code>Options|DX Cluster|Send spots to SmartSDR</code>.

[[image:radiobroadcastenable3.png]]

[[image:sendspotstosmartsdr.png]]

UDP broadcast parameters are configured in the <code>Options|Network configuration</code> panel. 
Please note that up to three ports can be specified for each broadcast, thereby supporting 
multiple receivers of the information.

[[image:Networksettingsbroadcast3.png]]

If you are writing a C# application to make use of these datagrams, there is a very nice online tool 
for creating an object from a sample XML datagram here https://xmltocsharp.azurewebsites.net/ 

In C# parsing is easily done using Linq. One example of XML parsing and deserialization using Linq 
can be found here https://github.com/bjornekelund/ICOMautomagic

===QSO information===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program
|-
| qsoid
| A unique string for this QSO. If this QSO is edited another contactinfo message will be sent with the same qsoid. Note that the qsoid is only unique within one instance of DXLog. If the computer is networked to others running DXLog the different computers may have a different qsoid for the same QSO.
|-
| contestname
| The name of the contest as it would be written to a Cabrillo file.
|-
| timestamp
| The UTC date and time of the QSO.
|-
| mycall
| The callsign of this station.
|-
| band
| The band on which the QSO was made. In MHz with period as decimal separator.
|-
| txfreq
| The frequency on which the QSO was made.
|-
| operator
| The callsign of the operator if the OPON command was used to set it, otherwise blank.
|-
| mode
| The mode used for the QSO.
|-
| call
| The callsign of the station worked.
|-
| countryprefix
| The DXCC country of the station worked.
|-
| wpxprefix
| The WPX prefix of the station worked.
|-
| snt
| The RST sent. This is always included whether or not the contest exchange contains an RST.
|-
| rcv
| The RST received. This is always included whether or not the contest exchange contains an RST.
|-
| nr
| The number sent if the exchange uses a serial number, otherwise the QSO number from this station.
|-
| exch1
| The first element in the contest exchange if any.
|-
| exch2
| The second element in the contest exchange if any.
|-
| exch3
| The third element in the contest exchange if any.
|-
| exch4
| The fourth element in the contest exchange if any.
|-
| xqso
| True if this QSO should not be counted towards the score.
|-
| invalid
| True if this QSO is invalid, for example a DX QSO in a domestic contest.
|-
| duplicate
| True if this QSO is a dupe (the station has previously been worked).
|-
| rule10broken
| True if this QSO breaks the 10 minute or similar rule. Note that a QSO may not break the 10 minute rule when it is logged but may later if another QSO is edited. This may not cause a broadcast.
|-
| azimuth
| The approximate direction of the station worked, in degrees.
|-
| distance
| The approximate distance of the station worked, in kilometers.
|-
| stationid
| The station ID of the station which made the QSO.
|-
| stationqso
| A unique QSO ID generated by the logging station. The combination of stationid and stationqso forms a unique identifier for the QSO.
|-
| stationtype
| The type of station - R for run, R1 for run 1 etc.
|-
| local
| True if this broadcast is due to this QSO being logged or edited on this computer.
|-
| runqso
| True if QSO logged in Run, false if S&P, and empty if unknown. '''Important:''' Only valid when local is True.
|-
| mult1
| The name of the multiplier if this station is a new multipllier, empty otherwise.
|-
| mult2
| The name of the multiplier if this station is a new multiplier, emtpy otherwise.
|-
| mult3
| The name of the multiplier if this station is a new multiplier, empty otherwise.
|-
| points
| The logged points for the QSO.
|-
| period
| The number of the operating period.
|-
| guid
| The GUID in hex format.
|-
| newqso
| True if a new QSO, False if this message is an update to an existing QSO.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<contactinfo>
<logger>DXLog v2.4.13</logger>
<qsoid>19</qsoid>
<contestname>ARRL-SS-CW</contestname>
<timestamp>2020-01-13 18:28:07</timestamp>
<mycall>SM7IUN</mycall>
<band>3.5</band>
<txfreq>352376</txfreq>
<operator></operator>
<mode>CW</mode>
<call>K4BAI</call>
<countryprefix>K</countryprefix>
<wpxprefix>K4</wpxprefix>
<snt>599</snt>
<rcv>599</rcv>
<nr>19</nr>
<exch1>076</exch1>
<exch2>B</exch2>
<exch3>54</exch3>
<exch4>GA</exch4>
<xqso>False</xqso>
<invalid>False</invalid>
<duplicate>False</duplicate>
<rule10broken>False</rule10broken>
<azimuth>225</azimuth>
<distance>1388</distance>
<stationid>STN1</stationid>
<stationqso>19</stationqso>
<stationtype>R1</stationtype>
<local>True</local>
<runqso>True</local>
<mult1>GA</mult1>
<mult2></mult2>
<mult3></mult3>
<points>3</points>
<period>1</period>
<guid>11223344556677889900aabbccddeeff</newqso>
<newqso>True</newqso>
</contactinfo>
</pre>

Alternative N1MM format

Note that the band name uses the computer's local number format so it may use either comma 
or period as decimal separator. The ID is a number rather than an alphanumeric string.

Also note that IsRunQSO is only valid when IsOriginal is True.

<pre><?xml version="1.0" encoding="utf-8"?>
<contactinfo>
<app>N1MM</app>
<contestname>CWOps</contestname>
<timestamp>2020-01-17 16:43:38</timestamp>
<mycall>SM7IUN</mycall>
<band>3.5</band>
<rxfreq>352519</rxfreq>
<txfreq>352519</txfreq>
<operator></operator>
<mode>CW</mode>
<call>K1XM</call>
<countryprefix>K</countryprefix>
<wpxprefix>K1</wpxprefix>
<stationprefix>K1XM</stationprefix>
<continent>NA</continent>
<snt>599</snt>
<sntnr>5</sntnr>
<rcv>599</rcv>
<misctext></misctext>
<ismultiplier1>1</ismultiplier1>
<ismultiplier2>0</ismultiplier2>
<ismultiplier3>0</ismultiplier3>
<points>l</points>
<radionr>l</radionr>
<run1run2>1<run1run2>
<IsOriginal>False</IsOriginal>
<NetBiosName>DESKTOP-23AB</NetBiosName>
<IsRunQSO>0</IsRunQSO>
<StationName>STATION_B</StationName>
<ID>23</ID>
<IsClaimedQso>true</IsClaimedQso>
</contactinfo>
</pre>

===Radio information===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| The name of the logging program.
|-
| logger
| The name and version of the logging program.
|-
| Station
| The ID of the station.
|-
| RadioNr
| The radio being described.
|-
| Freq
| The receiving frequency.
|-
| TXFreq
| The transmitting frequency
|-
| InactiveFreq
| The frequency of the VFO not receiving.
|-
| Mode
| The reported radio's mode.
|-
| OpCall
| The callsign of the operator if the OPON command was used to set it, otherwise blank.
|-
| mycall
| The callsign of the station.
|-
| IsRunning
| "True" if the station is running, "False" if search and pounce.
|-
| FocusEntry
| The Windows handle for the focused entry window.
|-
| Antenna
| Antenna number.
|-
| Rotors
| Rotators used by selected antenna (not currently used by DXLog).
|-
| FocusRadioNr
| The radio which has keyboard focus. In SO2V with "Report SO2V as two radios" checked, radio 2 is the sub/B VFO.
|-
| IsStereo
| True if headphones are listening to two radios.
|-
| IsSplit
| True if radio is set to split.
|-
| ActiveRadioNr
| The radio which is transmitting, if any.
|-
| Technique
| SO1R, SO2R, SO2R_ADV, or SO2V
|-
| StationType
| Station role: R, M, R1, R2, or R+.
|-
| isTransmitting
| True if a DXLog is transmitting. False if DXLog is not aware of transmission.
|-
| IFFrequency
| Optional element only used with Elecraft K3/K4. Contains the current IF frequency in Hz.
|-
|}

Important note: In SO2V the format differs from some other loggers and is:

: Only physical radio 1 is reported.
: <tt>Freq</tt> and <tt>TXFreq</tt> are the frequency of the currently focused VFO.
: <tt>InactiveFreq</tt> is the frequency of the currently unfocused VFO.
: <tt>ActiveRadio</tt> is always 1.
: <tt>FocusedRadioNr</tt> is 1 when the main/A VFO is focused, 2 otherwise.
: <tt>IsSplit</tt> is always false.

With the option "Report SO2V as two radios" checked, the reporting is similar to some other loggers and is:

: The two VFO are reported as two physical radios.
: <tt>Freq</tt> and <tt>TXFreq</tt> for radio 1 are the frequency of the main/A VFO.
: <tt>Freq</tt> and <tt>TXFreq</tt> for radio 2 are the frequency of the sub/B VFO.
: <tt>InactiveFreq</tt> is the frequency of the other VFO.
: <tt>ActiveRadio</tt> and <tt>FocusedRadioNr</tt> are 1 when the main/A VFO is focused, 2 otherwise.
: <tt>IsSplit</tt> is always false.

Example message:

<pre><?xml version = "1.0"?>
<RadioInfo>
<app>DXLog</app>
<logger>DXLog v2.4.13</logger>
<Station>STN1</Station>
<RadioNr>1</RadioNr>
<Freq>704000</Freq>
<TXFreq>704000</TXFreq>
<InactiveFreq>702500</InactiveFreq>
<Mode>CW</Mode>
<OpCall>K1XM</OpCall>
<mycall>HQ9X</mycall>
<IsRunning>False</IsRunning>
<FocusEntry>591124</FocusEntry>
<Antenna>1</Antenna>
<Rotors>ABC</Rotors>
<FocusRadioNr>1</FocusRadioNr>
<IsStereo>False</IsStereo>
<IsSplit>False</IsSplit>
<ActiveRadioNr>1</ActiveRadioNr>
<Technique>SO2R</Technique>
<StationType>R1</StationType>
<IsTransmitting>False</IsTransmitting>
<IFFrequency>8215000</IFFrequency>
</RadioInfo>
</pre>

===Antenna direction===

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program.
|-
| station
| The ID of the station.
|-
| radio
| The radio associated with the rotator.
|-
| go
| True if the rotator should be turned.
|-
| stop
| True if the rotator should be stopped if it is turning.
|-
| azimuth
| The direction to turn the rotator if go is True.
|-
| frequency
| The transmit frequency of the specified radio.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<Rotator>
<logger>DXLog v2.4.13</logger>
<station>STN1</station>
<radio>2</radio>
<go>True</go>
<azimuth>252</azimuth>
<frequency>2800200</frequency>
</Rotator>

</pre>
<pre><?xml version="1.0" encoding="utf-8"?>
<Rotator>
<logger>DXLog v2.4.13</logger>
<station>STN1</station>
<radio>2</radio>
<stop>True</stop>
<frequency>2800200</frequency>
</Rotator>
</pre>

===Callsign lookup===

Sent either when callsign in entry row is changed or when space or tab is pressed.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| logger
| The name and version of the logging program.
|-
| contestname
| The name of the contest.
|-
| mycall
| Station's call
|-
| band
| Current band
|-
| txfreq
| Transmitter frequency
|-
| operator
| The call sign of the logged in operator
|-
| mode
| Operating mode
|-
| call
| Call entered in the logging field
|-
| countryprefix
| DXCC entity prefix
|-
| wpxprefix
| WPX prefix
|-
| azimuth
| Short path antenna direction
|-
| distance
| Distance in km
|-
| stationid
| The ID of the station sending the datagram
|-
| stationtype
| The role of the station sending the datagram; R, R1, R2, M, or R+
|-
| period
| Contest period
|-
| reason
| Reason for transmission; SpaceOrTab or CallChanged
|-
|}

Example message:

<pre><?xml version = "1.0"?>
<lookupinfo>
<logger>DXLog v2.4.20</logger>
<contestname>DARC-WAEDC-CW</contestname>
<mycall>K1XM</mycall>
<band>20</band>
<txfreq>1400200</txfreq>
<operator></operator>
<mode>CW</mode>
<call>E7DX</call>
<countryprefix>E7</countryprefix>
<wpxprefix>E7</wpxprefix>
<azimuth>54</azimuth>
<distance>6824</distance>
<stationid></stationid>
<stationtype>R</stationtype>
<period>1</period>
<reason>SpaceOrTab</reason>
</lookupinfo>
</pre>

===Spot===

Sent for every incoming spot from the DX cluster that is valid for the current contest.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| Application sending the message.
|-
| StationName
| The station issuing the broadcast.
|-
| dxcall
| The callsign of the spotted station.
|-
| frequency
| Frequency in kHz with decimal sign of the PC's current locale. (sic)
|-
| spottercall
| The callsign of the spotter. Station name if locally spotted or result of a logging operation.
|-
| timestamp
| Spot time in format yyyy-MM-dd HH:mm:ss
|-
| action
| add or delete.
|-
| mode
| actual or guessed mode of the spot in capitals.
|-
| comment
| The comment section of the spot.
|-
| status
| Spot status. Valid values are "dupe", "double mult", "single mult", and "new qso".
|-
| statuslist
| Same as status
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<spot>
<app>DXLog.net</app>
<StationName>CONTEST-PC</StationName>
<dxcall>E7DX</dxcall>
<frequency>14022.3</frequency>
<spottercall>SM7IUN-#</spottercall>
<timestamp>2O23-07-15 14:29:37</timestamp>
<action>add</action>
<mode>CW</mode>
<comment>CW 31 DB 42 WPM CQ</comment>
<status>single mult</status>
<statuslist>single mult</statuslist>
</spot></pre>

===Broadcast listener===

DXLog also listens for commands over UDP.

Currently only one command is implemented, <code><radio_setfrequency></code>, which is a QSY command.

{|class="wikitable"
|+style="text-align:Left;"|
|-
| '''Keyword
| '''Meaning
|-
| app
| Application sending the command
|-
| radionr
| The radio to be changed. In SO2V radio 2 means VFO B. Optional as of DXLog 2.5.20.
|-
| frequency
| Requested frequency. Both period and comma is accepted as decimal separator.
|-
| mousebutton
| Which mouse button was used to create message, if any. Optional.
|-
|}

Example message:

<pre><?xml version="1.0" encoding="utf-8"?>
<radio_setfrequency>
<app>WaterfallBandmap</app>
<radionr>1</radionr>
<frequency>21022.194</frequency>
<mousebutton>Left</mousebutton>
</radio_setfrequency>
</pre>

==SDR integration==

===HDSDR, OmniRig, and microHAM===

''Contributed by Ingo SM5AJV/SE5E''

Until DXLog offers SDR integration there are still ways to get a waterfall/spectrum display with DXLog.

I have integrated the free SDR software [http://www.hdsdr.de/ HDSDR] with DXLog using
[http://www.microham.com Microham Device Router], 
[http://dxatlas.com/OmniRig/ OmniRig]
and [https://www.autohotkey.com/ AutoHotkey].

As illustrated below I place the HDSDR window at the very top of the desktop with DXLog right below.

I share my transceiver's (an Elecraft K3) antenna with the SDR. The receiver antenna signal from my 
K3's RX-ANT OUT is connected to the input of a 3dB power splitter. The two outputs from the splitter 
are connected RX-ANT IN on the K3 and the SDR Receiver antenna input, respectively. On a K3 you 
need to enable the RX-antenna input to make this to work. An additional benefit with this method 
is that the SDR is protected during transmission. It is a widely used method and is e.g. described 
by Bob N6TV in this
[http://dxlog.net/sw/files/utilities/Adding%20an%20SDR%20to%20an%20SO2R%20Station.pdf presentation].

'''Screenshot of my desktop:

[[Image:Sdrdesktop.png|800px]]

Since both DXLog and HDSDR need to communicate with the radio, you need to "split" 
the CAT communication. microHAM's USB Device Router provides a second, independent, 
CAT port that can be used via HDSDR's omniRig interface.

'''"PORT" Tab on microHamRouter:

[[Image:Sdrmicrohamrouter.png|800px]]

'''OmniRig settings in HDSDR:

[[Image:Sdromnirig.png|200px]]

With this set up, the radio, DxLog, and HDSDR will be fully synchronized. For instance, you can 
click in the waterfall to make the radio QSY, and it is easy to quickly find a clean frequency.

To make the integration even better I use a small AutoHotkey script. The script pulls entry focus 
back to DxLog after clicking on the HDSDR waterfall and in DXLog it allows you to use hotkeys to 
control HDSDR. <code>[Ctrl][Alt]+</code> and <code>[Ctrl][Alt]-</code> zooms the waterfall/spectrum 
in and out, and <code>[Ctrl][Alt]C</code> centers it.

'''AutoHotkey script:

SetTitleMatchMode, 2
#InstallKeybdHook
#IfWinActive, HDSDR
{
F4:: return ; disable F4
~LButton Up::
sleep, 1
Winactivate, DXLog
return
}
#IfWinActive, DXLog
{
^!+:: ControlSend ,, ^{+}, HDSDR
^!-:: ControlSend ,, ^{-}, HDSDR
^!c:: ControlSend ,, {c}, HDSDR
}

The script can be downloaded [http://DXLog/sw/files/utilities/dxlog_hdsr.ahk here].

If you start two instances of HDSDR with two different SDR you can even have two waterfalls 
running at the same time.

I have not yet found a way to display cluster spots in the HDSDR spectrum panel. 
But I still find it very useful to check band activity and it allows me to easily find 
a new Run frequency on a crowded band.

===Waterfall Bandmap===

The free waterfall/spot display utility "Waterfall Bandmap" by Steve N2IC is supported by DXLog.

Waterfall Bandmap supports almost any SDR that produce I/Q output either via ExtIO.DLL or a 
sound card; SDRPlay, FunCubeProPlus, HackRF, SDR-IQ, RTLSDR, SoftRock, etc.

A zip file with an executable binary and a Microsoft word document with installation and 
configuration instructions can be found here: https://groups.io/g/waterfallbandmap/files

If you are not a member of the support forum group, you need to apply for membership to download. 
Membership is free.

[[Image:Waterfallbandmap.png]]

The SDR can be connected either to a separate receive antenna, an external receiver output on 
your transceiver or to an IF output, should your transceiver have one. If connected to an antenna, 
keep in mind that you may need protection from the transmitter such as a T/R relay or a passive level limiter.

Please refer to Waterfall Bandmap's documentation for setting it up with your SDR.

Waterfall Bandmap needs two information feeds over UDP: Radio information and spot information. 
Both are provided as UDP broadcast by DXLog.

The default port for both is 13063 and this needs to be set in DXLog's Network configuration panel. 
If Waterfall Bandmap runs on the same computer as DXLog, the broadcast address can be left at the default 127.0.0.1.

[[Image:Setbroadcastportsforwfbandmap.png]]

Clicking on the waterfall display can set the frequency of DXLog. (Left click sets VFO A, right click sets VFO B.) 
To enable this functionality, check the option <code>Options|Broadcast|Receive Broadcasts</code> 
Also make sure "UDP broadcast listener" includes port 13064 in the network settings panel.

The radio information feed needs to be enabled by checking the <code>Options|Broadcast|Radio information</code> option

[[Image:radiobroadcastenable2.png]]

and the spot feed needs to be enabled by checking the <code>Options|DX Cluster|Send spots to SmartSDR</code> option.

[[Image:Enablesendspotstosmartsdr.png]]

==Time synchronization==

In a multi-station setting, the time needs to be accurately synchronized across all networked PC.

Windows' built in time synchronization is very crude and for a PC with poor clock stability the 
inaccuracy of the clock may be up to a minute. Which of course is not acceptable for contesting.

DXLog has built in support for time synchronization as described in the [[Menu Options#Configure network|Configure network section]].

Due to Windows' security system, this however requires all except the PC running as time server to 
run DXLog with elevated permissions. There is unfortunately no way around this inconvenience.

An equally accurate and less intrusive method is to use a standalone time synchronization application on each networked PC. 
This will keep each PC's clock accurate within a fraction of a second.

Contrary to a solution built into a logger it also has the great benefit of being an "install and forget" solution.

A popular application is Dimension 4 by Thinking Man Software. It is free for personal use and 
can be downloaded here: https://dxlog.net/sw/files/utilities/d4time531.msi

It runs in the background and only shows up as a tiny icon in your system tray. 
You hover the mouse above the icon to check status and right-click to open and change settings.

:::[[image:dimension4tray.png|50px]]

After installation a brief configuration is required.

First of all, allow the application to disable Windows' time service and to modify your system clock.

For maximum accuracy, select a time server geographically close to your location. 
When in doubt, you can always add the global server "pool.ntp.org" to the list and use that. 

There are also national and continental pools of time servers. You can find them here https://www.ntppool.org.

[[image:dimension4b.png]]

Make sure the check boxes "Load Dimension 4 at startup", "Start minimized", "Hide when minimized", 
and "Display icon in tray" are all checked.

[[image:dimension4advanced.png]]

Click the Advanced button and also make sure the option "Use the selected server" is selected.

Make sure the application reports a successful connection to the selected time server. 
From here on, you can basically forget the application. 
It will silently start with your PC and always keep its time accurate.

==Disabling USB power management==

In the interest of saving energy, Windows habitually power down USB interfaces 
when it believes there is inactivity. Some USB-to-serial and USB audio devices 
respond poorly to being suspended or powered down so as a rule this "feature" should 
be disabled when used in a ham radio environment.

There are two places where this functionality needs to be disabled; the device driver 
and Windows' energy management.

To disable it for each USB interface and device, open Windows settings. (Click the Windows 
icon in the lower left corner and then chose the cogwheel.) Type ''device manager'' and
select the result.

[[image:devicemanager-c.png|none|frame]]

This opens up a new window, Windows' Device Manager.

[[image:devicemanager2b.png|none|frame]]

For '''every''' USB interface component (there may be many), COM-port, and audio device, 
and '''uncheck''' the option ''Allow the computer to turn this device off to save power''.

The devices you are looking for are in the categories: ''Ports (COM & LPT)'', 
''Sound, video and game controllers'', ''Universal serial bus controllers'',

Note that some devices may not have a ''Power Management'' tab.

[[image:usbdevicemanager.png|none|frame]]

The next step is to disable Windows ''Selective suspend'' feature for USB interfaces.

Go back to Windows Settings and type ''edit power'', click the appearing ''Edit power plan'' menu entry.

[[image:editpowerplan2.png|none|frame]]

This should open the window below, the plan editing panel.

[[image:editplansettings.png|none|frame]]

Click ''Change advanced power settings''. Scroll down to ''USB settings'' and make 
sure ''USB selective suspend setting'' is '''disabled''' for all situations.

[[image:Advancedsettings.png|none|frame]]

To prevent audio devices from becoming unreachable or going into sleep mode you should also 
disable exclusive access. While changing this, also make sure all audio enhancements are disabled.

You reach the detailed audio device settings by entering Windows settings, search for Control panel, 
and in the Control panel view, select Hardware and audio, and then Sound.

[[image:Audiodevice.png]]

Reboot your computer to make sure all settings are recognized by Windows.

==Interlock and inband operation==

In contest station terminology, the term ''Interlock'' refers to a technical solution preventing 
more than one station from using a shared resource, typically an antenna, at the same time.

The most common use for interlock is for inband operation. Inband operation means to have multiple 
transmitters on a single band, interleaving their transmissions. Sometimes on a split-second basis.

As long as you never have more than one transmitter active at any time, the majority of contests allow 
an unlimited number of transmitters and receivers on a single band for multi-operator categories. 
This fact is used by most big contest stations.

For an inband solution to be effective, each station must be able to receive while the 
other station transmits. This means it requires a separate, high performance receive antenna 
with very good isolation from the transmitter antenna. The most common way to 
achieve this is physical separation and geographic orientation to minimize the situations 
when they will radiate/listen in the direction of the other antenna.

For a station operating in the M/M, M/S, or M/2 category, inband operation can boost the points 
per hour performance significantly. It is also a lot more fun.

However, as with everything else, it comes at a cost. An efficient inband solution has:

* A high performance receive antenna for each operated band(s) with very good isolation from the transmitter antenna.
* A fail-safe antenna switching hardware.
* Interlock-capable keyers and/or station controllers.
* An interlock-capable contest logging software

A typical inband configuration can be seen in the illustration below.

[[image:inbandconcept-trx.jpg|800px]]

DXLog offers a software-based interlock which can be configured in a variety of ways, e.g. based on frequency 
band, operating mode, or station role. It supports an unlimited number of stations interlocking each other 
using a great variety of strategies.

The interlock relies on UDP networking and is overlaid on the communication for multi-station logging. 
UDP networking has the benefit of speed and low latency but is, unlike TCP, susceptible to packet loss. 
This means that a '''wired LAN''' is a necessity for any station using interlock. 
For the same reason, it is also not recommended to run interlock over e.g. VLAN/VPN link for 
geographically distributed stations.

A software interlock is not 100% reliable. Computer or software malfunction, networking issues such as packet 
loss, etc. can cause interlock to fail, even if only momentarily.

For this reason it is necessary to also accompany a software interlock with a fail-safe '''hardware''' interlock. 
Without hardware supported interlock you run the risk of not only violating contest rules but also cause serious equipment damage. 
Some contests, such as CQ WW, explicitly requires hardware interlock when using multiple stations on the same band.

There are many designs and even commercial products available for hardware interlock. 
One example of a simple but effective two station hardware interlock which also supports 
power amplifier sharing can be found [https://sm7iun.se/contest/inband/ HERE].

The purpose of this section is to describe steps of setting up a basic two station in-band solution with 
DXLog and microHAM keyers. The microHAM keyers are not mandatory but offers a much better user experience 
and removes the need for additional hardware.

'''Pro tip:''' Consider checking <code>Options|Networking|Allow other stations to abort sending</code> 
which will allow your partner station to interrupt your transmission with <code>[Shift][Esc]</code> in 
critical situations. Be careful though, the use of this function requires good judgment to avoid violence.

===Networking===

Open the networking configuration panel with <code>Options|Configure network</code> and make sure each 
station has a unique name and that only UDP networking is enabled.

Make sure the two stations use the same broadcast IP address and that it is in line with your LAN's 
configuration. Pressing the <tt>Default</tt> button is a good way to ensure this.

Make sure the menu option <code>Options|Enable network</code> has a checkmark.

[[image:inbandnetworkrun.png|left|frame]][[image:inbandnetworkinband.png|none|frame]] 

===DXLog Interlock configuration===

First of all, make sure that the <code>Options|Interface specific options|Prevent TX if another radio is on same band</code> 
is '''not''' enabled. This option completely prevents transmission if more than one networked station is set to the same band 
and the whole idea with inband is to have exactly that.

Next, activate software interlock on both stations using the menu option <code>Options|Networking|Software interlock</code> 
or by typing the commmand <tt>ILOCKON</tt>.

[[image:inbandinterlock2.png|none|frame]]

There are multiple options for configuring the interlock. In a simple set up with only two stations, the topmost 
option ''Same band from status list'' is a good choice. This option will prevent more than one station transmitting 
on the same band, regardless of mode.

In an environment with many stations (such as a multi-operator-multi-transmitter station) it is 
recommended to use the bottom option to only interlock with one or several named stations. 
This will reduce both LAN traffic and inband operation latency. This is particularly important when 
running parts of the DXLog network over high latency links such as VLAN/VPN or if some stations (albeit not 
part of the interlock cluster) are connected via Wi-Fi.

For more advanced scenarios you can also use interlock based on mode or station type (e.g. Run 1, Run 2, Mult, etc.).

The "status list" listing the networked DXLog stations is displayed in the ''Status Window'' which is opened 
with <code>Windows|Status window</code> or <code>[Alt][J]</code>.

[[image:inbandstatuslist2.png]]

DXLog also offers great flexibility when it comes to interlock strategy. The most straightforward and 
most commonly used is ''First one wins''. This is also typically the behavior of "unintelligent" 
hardware solutions when not assisted by software. With this strategy, the station starting to transmit 
first can not be interrupted and always gets to finish its transmission.

[[image:inbandinterlockoptions.png]]

With a ''Last one wins'' strategy, the transmitting station can be interrupted. A carte blanche permission 
to interrupt all transmissions by the other station may however be counterproductive in a real contest situation.

For this reason, DXLog offers additional control of which transmit actions can be interrupted and which can not. 
This is a powerful tool but requires both operators to be aware of it and may require 
practice before fully effective.

[[image:inbandstrategyexceptions.png]]

''F1'' through ''F7'', ''PLUS'' and ''INS'' refers to DXLog's standard messages. ''KEYB'' means a free text transmission 
from the keyboard using the <code>[Alt][K]</code> function and ''MAN'' means manual transmission using either paddle 
break-in or a footswitch.

For CW, DXLog recognizes paddle break in from a K1EL Winkey-compatible keyer as described in the [[Menu_Options#Winkey_Configuration|Winkey configuration section]].

Since DXLog recognizes a footswitch connected to a microHAM device, this is a recommended approach for phone. 
It is also possible to connect a footswitch to the DSR pin (pin 6) on a physical COM-port on the PC, but today 
few PC have such a port and it also requires additional circuitry.
Details on how to do this is available [[Additional_Information#Connecting_a_footswitch|HERE]].

===microHAM configuration===

Open the microHAM device configuration panel with <code>Options|microHAM device configuration</code>.

[[image:Mk2r-new9.png|none|frame]]

Check the option ''Enable TX lock/unlock''. This will do two things; it will enable DXLog to prevent 
transmission and and it will make DXLog aware of the microHAM device's PTT status. The latter is particularly 
important since it means DXLog will recognize PTT assertion not only by a footswitch connected to the 
microHAM device but also by the built-in Winkeyer (requires microHAM USB Device Router version 9.3.0 or later) 
'''Paddle-based break-in in an inband solution is currently unique for microHAM with DXLog.'''

'''Important:''' Making DXLog "PTT aware" means that care has to be taken in how PTT is set up. If you, for instance, 
enable DXLog PTT for the voice keyer, this will create a self-reinforcing feedback loop and PTT will thus never drop.

Check the option ''Dual radio device'' if you are using a u2R, MK2R, or MK2R+, otherwise, leave this unchecked.

Check the option ''Device without CAT interface'' if the device lacks a CAT interface (like the u2R) 
or if its CAT interface is not connected to the radio. This option will make sure the e.g. keying and 
audio routing is always set correctly in line with the operating mode (Voice, CW, or RTTY).

===Operating===

Inband operation requires a fair amount of training and it is a good idea to define and agree 
on general rules for operation, such as hand signals for challenging QSO, beforehand.

There are more than enough YouTube videos of inband operators yelling at each other.

The operating tactics may have to be adjusted during the contest. If Run is slow, 
doing S&P on the inband station can increase the points per minute significantly. 
However, if Run is strong, an overly active inband operator doing S&P, but not working 
multipliers, may actually reduce the station's points per minute significantly.

Real-time interlock status is shown in the ''Radio status'' window, which is opened with 
<code>Windows|Radio status</code>.

[[image:inbandblocking.png]] [[image:inbandblocked.png]]

For Phone contesting, you typically rely on footswitches for PTT and the option 
<code>Options|Networking|Show QSO status when blocking</code> makes the blocking 
station send a more helpful blocking cause than ''MAN''.

With this option enabled, the blocking station will instead send ''CQ'', ''QSO'', or ''EXCHANGE'' 
as blocking cause, determined by cursor location and entry field content at the locking station.

Further reading can be found in the [[Menu_Options#microHAM_device_configuration|microHAM device configuration]] and [[Menu_Options#Networking|Networking]] sections.

==Connecting a footswitch==

To free up both hands in Phone contesting, a footswitch PTT is a great help.

Also, to use interlock in Phone contesting, a footswitch is mandatory.

There are two basic ways to interface a footswitch with DXLog; via a microHAM device (which is the recommended solution) 
or directly connected to a physical serial port on the PC (which very few PC have today).

The connection of a footswitch to a microHAM device is very straightforward and by checking the ''Enable TX lock/unlock'' 
in the ''microHAM device configuration'' panel, it is recognized by DXLog.

Lacking a microHAM device, it is also possible to use the computer's DB9 RS-232 serial port connector, providing it has one.

The required steps to do this are:
* Connect a 10k resistor between DB9 pin 6 and pin 7.
* In the port's settings (<code>Options|Configure interfaces</code>) set DTR (pin 4) to ''Always On'' and RTS (pin 7) to ''Always Off'' for the port.
* Connect the footswitch between DB9 pins 4 and pin 6. '''Important:''' Neither pole on the footswitch must be connected to ground.
* In the radio's configuration panel, check ''use CAT PTT command on Phone'' and set ''Footswitch (pin 6)'' to ''PTT''

==Support for CC Cluster==

CC Cluster is today the main choice for contest use.

It offers a high quality, database-verified, flow of skimmer spots and a rapid 3-minute respotting period for skimmer spots.

It also publishes unique spots from less common locations which are valuable for DX chasers or as contest multipliers.

To make use of the display of own spot in the world map, make sure to issue the command '''<tt>SET/OWN</tt>''' to the cluster node. 
This setting is persistent and only needs to be done once.

A list of cluster nodes that runs CC Cluster can be found here: [https://www.dxcluster.info/telnet/index.php?software=CC%20Cluster CC Cluster nodes]

A description of the command line syntax can be found here: [http://bcdxc.org/ve7cc/ccc/CCC_Commands.htm CC Cluster command syntax]

A convenient software for setting up filters etc. can be found here [http://www.bcdxc.org/ve7cc/default.htm#prog CC User]

[[Image:Ccclustersspotflow.png]]

==Support for AR Cluster 6==

With the author tragically SK, AR Cluster is no longer under development but still available as an executable binary.

In its standard configuration, AR Cluster offers no consolidation of skimmer spots meaning a very high flow of spots 
that can become extreme during a major contest weekend.

With the advent of skimmers, the traffic on the DX Cluster has risen dramatically. Even though CW skimmers are generally 
quite reliable, the absolute number of busted spots can be quite high during a busy contest.

Jose CT1BOH has developed an algorithm for evaluating spot quality which is included in version 6 of AR Cluster. 
Today many cluster nodes runs this version and thereby offer this mechanic. 
A complete list can be found here: [http://www.dxcluster.info/telnet/index.php?software=AR-Cluster AR Cluster nodes]

To enable the functionality on a cluster node running AR Cluster 6, the command

<tt>'''SET DX EXTENSION SKIMMERQUALITY'''</tt>

needs to be issued to the cluster node. The easiest way to do this in DXLog is via <code>[Alt][T]</code>. 
This setting will be remembered at subsequent logins.

The quality of the spots is indicated by a character ("tag") in the last column of the comment field and, 
in some cases, a corrected callsign within parenthesis. This syntax is recognized by DXLog and can reduce the 
number of bad spots in your bandmap.

The CT1BOH skimmer quality algorithm is based on three parts:

; Validation : When a callsign is first spotted, it is tagged with "?" in the last column of the spot's comment field. If the callsign of an unverified spot closely resembles an already verified one on the same frequency, the verified callsign is provided within parenthesis in the spot's comment field. When two or more skimmers agree on the spot, it is considered verified and the tag becomes "V".

; Frequency : When a verified spot appears more than 0.35kHz off its verified frequency, the spot is tagged "Q" for QSY. Once verified, this becomes the new verified frequency and it is tagged "V".

; Probability : The algorithm checks uncertain spots for resemblance with already verified spots and spots at or near the same frequency. If the resemblance is high enough, the spot is considered busted "B" and the corrected callsign is provided within parenthesis in the spot's comment field.

Below you can see an example of the spot flow from W9PA-4 with skimmer quality enabled. 
The flow contains one unverified and one busted spot.

[[image:spotquality.png]]

DXLog's policy for spots with CT1BOH skimmer quality tags is the following:

: '''V''' - Accept spot.
: '''Q''' - Accept spot.
: '''?''' - Accept spot. Use corrected call when provided.
: '''B''' - Accept spot if corrected call provided. Else ignore.

DXLog recognizes the skimmer quality tags but consolidates them for consistency 
with other cluster nodes' quality tags and to minimize confusion when mixing spot flows. 
The legend is:

: '''?''' means a spot with ? This is an unreliable spot.
: '''P''' means a spot with Q or B with correction. This is a fairly reliable spot.
: '''V''' means a spot with V. This spot is considered validated.

This basic policy can be modified by using additional filters at the cluster node end. Some examples are:

: <tt>'''SET DX FILTER NOT SKIMBUSTED'''</tt> - Do not send busted spots at all
: <tt>'''SET DX FILTER NOT SKIMQSY'''</tt> - Do not send QSY spots
: <tt>'''SET DX FILTER SKIMVALID'''</tt> - Only send verified spots
: <tt>'''SET DX FILTER NOT SKIMUNKNOWN'''</tt> - Do not send unreliable spots
: <tt>'''SET DX FILTER SKIMMER'''</tt> - Do not send manual spots

You can also compose more complex filters such as:

: <tt>'''SET DX FILTER SKIMVALID OR SKIMBUSTED OR NOT SKIMMER'''</tt>

This can be a good filter for most contests. It will will only provide valid or busted skimmer spots together with manual spots. 
It is safe to receive busted spots since DXLog will ignore them if there is no corrected callsign included. 

For assisted operation in serious contesting you however need to allow also unknown spots since weak stations spotted 
only by one or a few skimmers may never reach validated status. You do this by adding <tt>'''OR SKIMUNKNOWN'''</tt> to the filter.

Both the bandmap and the DX cluster announcement windows have the option to display the spot quality tag. 
These windows will show two additional tags; L and C. L stands for local spot, created by yourself or one of your team members. 
C stands for corrected, i.e., a B or ? spot where a corrected call has been included in the spot's comment field.

The AR6 filtering syntax offers a lot of flexibility. Another example:

: <tt>'''SET DX FILTER (SKIMVALID OR NOT SKIMMER OR ((SKIMQSY OR SKIMUNKNOWN) AND (CTY <> K AND CONT <> EU )))'''</tt>

will provide only validated and human spots except if they are from outside the US and EU.

If you get lost in the filter settings you can always reset with : <tt>'''SET DX DEFAULT'''</tt>.

Some more guidance on how to work with filters on AR-Cluster nodes can be found in [http://dxlog.net/sw/files/utilities/AR_Cluster_v6_User_Manual.pdf this document].

==Support for DXSpider==

DXSpider is the by far most dominant DX cluster software but has historically not been a good choice for contesters. 
The reasons for this include: Long respotting time, lack of pass function for own spots, and suppression of spots from a single skimmer.

The good news is however that the author Dirk G1TLH has worked hard to address these aspects of the otherwise brilliant software.

From '''version 1.57 release 440''' the respotting time is now 3 minutes and there is a <tt>SET/SEEME</tt> command that passes all spots 
without consolidation of your own callsign.

So if your favorite cluster node is not running this version, ask the owner to upgrade asap.

Yet another reason for its popularity is its extreme resource-efficiency which allows it to run virtually 
any Linux capable hardware, including a $20 Raspberry Pi Zero.

A list of all DX cluster nodes running DX Spider can be found here: [https://www.dxcluster.info/telnet/index.php?software=DX%20Spider DX Spider cluster nodes]

[[image:dxspiderflow.png]]

DXLog recognizes the <tt>Q:#</tt> skimmer quality tag in the comment field and converts them into "CT1BOH-like" quality 
tags that can be displayed in DXLog's bandmap. The legend is:

: '''?''' means a spot with Q:1, i.e. heard by only one skimmer. This is an unreliable spot.
: '''P''' means a spot with Q:2, i.e. heard by only two skimmers. This is a fairly reliable spot.
: '''V''' means a spot with Q:3 or higher, i.e. heard by several skimmers. This spot is considered validated.

Since a DXSpider node currently needs to be specially configured by the owner to publish Q:1 spots, very few do this. 
Also, since DXSpider lacks busted call detection, the the quality of the spot flow will suffer if this is done.

There is a wealth of information to be found on the [http://wiki.dxcluster.org/index.php/Main_Page DXSpider wiki].

==Support for N2WQ Cluster==

Introduced in late 2025, Rudy N2WQ has developed the first new DX cluster node software in decades.

The N2WQ-2 cluster has some unique features like a more advanced callsign validation than 
AR 6 and propagation estimation tags embedded in the spot comments. An example can be seen below.

[[image:n2wpspotflow.png]]

When you connect to dxc.n2wq.com port 8300 and you have set your 4-digit Maidenhead grid (SET GRID), there 
will be a single character just before the DX’s grid locator. This character is the path prediction glyph.

It is a crowdsourced, real-time estimate of how reliable the path is between you and the DX on that band right now, 
based on recent on-air propagation reports from RBN and PSKreporter. Its values and meaning are:

: > High: Strong path. If you can hear them, you should be able to work them.
: = Medium: Decent path. Workable with normal contest/DX technique.
: < Low: Weak path. Possible, but expect repeats, timing, and patience.
: - Unlikely: Marginal. Try only if it’s rare/needed, or you have a strong station advantage.

A missing glyph means insufficient data to estimate the path.

the glyph is mode-aware. A path that looks great for a very sensitive mode (FT8) can look 
more moderate for a less sensitive one (SSB).

You can filter spots by path reliability using the PASS/REJECT PATH command.

It is important to be aware that the glyph does not know:

: Your antenna gain/pattern, height, or takeoff angle
: Your transmit power and duty cycle constraints
: Your operating technique (timing, split discipline, pileup strategy)
: Short-lived phenomena the network has not yet “seen” such as sporadic E or aurora.

The cluster ingests upwards of 50,000 CW, FT, RTTY, and WSPR spots per minute. To compare different modes 
fairly, the system normalizes reports onto a common “FT8-equivalent” scale (so a CW SNR can be compared 
to an FT8 SNR).

Your grid and the DX grid are mapped into small geographic cells and the cluster calculates propagation 
at two levels:

: Fine (local): what’s happening close to your area (~180 miles).
:: On averages there are about 90,000 DE/DX pairs being tracked
: Coarse (regional): what’s happening in the broader region around
:: you (~480 miles). On average, there are about 30,000 DE/DX pairs.

If there isn’t enough local data, the system leans more on regional behavior. 
If there’s plenty of local data, it uses that more heavily.

Sometimes you can hear them better than they can hear you (or the reverse) due to noise 
floors, antennas, geography, or ionospheric effects. The system tracks both:

: Receive direction: DX to you (can you hear them?)
: Transmit direction: you to DX (can they hear you?)

It combines these into one “path reliability” estimate, weighting receive a bit more 
because if you can’t hear them, you can’t work them.

Propagation changes fast, so older reports get discounted using a half-life (data fades 
in influence over time). Typical behavior by band:

: Low bands (160/80m): slower changes (longer half-life)
: Mid bands (40–20m): medium pace
: High bands (15–6m): fast changes (shorter half-life)

In practice, this means glyphs can shift in minutes on 10m/6m, and more slowly on 80m/160m. 
Also, new openings take time to show up. A "insufficient" can simply mean “the path just opened 
and the cluster hasn’t collected enough recent reports yet.”

Your local noise floor heavily affects what you can receive, so the cluster lets you tell 
it what your noise environment is. This mainly tunes the receive-side expectation (DX to you).

Set it with SET NOISE SUBURBAN. Available profiles per ITU:

: QUIET: very low noise, rural/remote
: RURAL: mild noise
: SUBURBAN: typical neighborhood QRM
: URBAN: elevated noise, dense housing
: INDUSTRIAL: severe noise

If you don’t set it, the system may assume a quieter environment than you actually 
have, and your receive-side glyphs can look too optimistic.

Treat the glyph as a real-time probability hint that helps you spend your operating 
time where the odds are best. When you see > on a needed multiplier, move fast. 
When you see -, be intentional about whether it’s worth the time. 
And when you see a space, fall back to classic DX/contest instincts and your own ears.

The N2WQ cluster also offers spot quality tags between the DX grid and the time.

A quality (in terms of callsign reliability) tag can be V, P, S, C, or ? where V means validated, 
P highly likely, S less likely, C corrected, and ? unsure.

The propagation and quality tags can be displayed in the bandmaps and the DX cluster announcement window.

DXLog recognizes the skimmer quality tags but consolidates them before display for consistency 
with other cluster nodes' quality tags and to minimize confusion when mixing spot flows. 
The legend is:

: '''?''' means a spot with ? or S. This is an unreliable spot.
: '''P''' means a spot with P or C. This is a fairly reliable spot.
: '''V''' means a spot with V. This spot is considered verified.

==Interacting with WSJT-X==

Important: When in a DXpedition/multi-station setting, always use local host 127.0.0.1 as the 
broadcast address to prevent packets being picked up by other stations in the network. 
Also, enabling the creation of local spots from decodes may overwhelm DXLog.

DXLog can add QSO performed with WSJT-X to its log. Note that this functionality only works 
for contests with grid as the first and only exchange or for DXPedition type logs.

DXLog can also create local spots from WSJT-X decodes by checking 
<code>Options|Broadcast|Spot WSJT-X decodes</code>.

To enable logging of WSJT-X QSO, set up WSJT-X to broadcast information:

[[image:Wsjt-x-udp.png]]

[[image:Radiobroadcastenable3.png]]

Activate DXLog's UDP listener by checking <code>Options|Broadcast|Receive broadcasts</code> and set 
the same port number as in WSTJ-X in DXLog's network configuration panel.

[[image:Dxlog-udp.png]]

==Using Winkey FSK==

Winkey FSK is not natively supported by DXLog's digital mode engines MMVARI or MMTTY but 
Rafal EI6LA has developed a plugin for MMTTY that makes this possible.

You can find it [https://github.com/RafalLukawiecki/WinKeyerMMTY here].

==Interfacing with LogHX==

Christian F8GHE has prepared a guide on how to do this.

You can find it [http://dxlog.net/sw/files/utilities/DXLOG-LogHX_UDP-config_v2.pdf here].

==Self-spotting==

More and more contests allow spotting your own station on the DX cluster.

DXLog supports this, even when operating unassisted, as long as you connect to the cluster.

DXLog has three mechanics for self-spotting.

DXLog blocks self spotting unless specifically allowed in the contest rules. 
Should you find that DXLog incorrectly allows or blocks self-spotting, please make 
the development team aware via the support reflector.

* The <tt>$SPOTME</tt> macro command. This macro will create a cluster spot of the station's
: call at the earliest 15 seconds after being invoked the first time on a new frequency.
: Thereafter it will spot as frequent as allowed by the contest. If the contest rules do not
: specify a minimum period, 10 minutes will be used.

* Checking the menu option <code>Tools|Data entry|Run F1 message self-spots when permitted</code>.
: Works exactly like the <tt>$SPOTME</tt> macro command but is triggered by sending the
: Run F1 message which happens when pressing <code>[Enter]</code> with an empty entry line
: in Run, pressing <code>[F1]</code> in Run, or with Auto-CQ.

* Clicking the menu item <code>Commands|Self-spot</code> or pressing its shortcut key <code>[Ctrl][S]</code>.
: This will immediately create a spot of the station's call but no more often than
: every two seconds to avoid accidental multiple spots.

==DXpedition use==

DXLog is a popular choice for top tier dxpeditions. Below we have collected advice based on experience 
on how to best use DXLog in a dxpedition setting.

* Use client/server networking between stations. Never use UDP over Wi-Fi or WAN links.
* Use the "Minimal data" option in ADIF export to save on satellite link cost.
* For Club Log real time upload, use [[https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads Club Log's upload app]]
* Club Log truncate QSO time to minutes so to avoid creating dupes when mixing manual and real time
: upload to Club Log, check "QSO time in minutes" when doing ADIF export.
* Use the "Minimal data" option in ADIF export to save on satellite link cost.
* Follow [[Additional_Information#Interacting_with_WSJT-X|the instructions]] to log QSO made with WSJT-X and MSHV.
* Check <code>Options|Broadcast|Spot WSJT-X decodes</code> to make decoded calls appear in e.g., DX cluster announcements.
* You can extend the number of digits in the QSO count with <code>Options|Log|QSO number digits</code>

==Beacon spots on DX cluster==

Although propagation measurements based on FT8 communications has reduced the
value of beacons, there are still hundreds of them in operation.

Identifying with CW, they are typically reported on reported on the DX cluster.

When beacon spots are received by DXLog, they are always displayed in the bandmap. 
In DXLog, beacon spots are recognized by having a trailing <tt>/B</tt>.

The DX cluster announcement window never shows or counts beacon spots.

Beacon spots can be enabled and disabled in the cluster node.

For CC Cluster, the commands are <tt>SET/BEACON</tt> and <tt>UNSET/BEACON</tt>.

For DXSpider, command is part of the <tt>SET/SKIMMER</tt> command where <tt>SET/SKIMMER</tt> 
or e.g., <tt>SET/SKIMMER CW BCN FT RTTY</tt> will pass beacon spots and <tt>UNSET/SKIMMER</tt> 
or any <tt>SET/SKIMMER</tt> listing modes but not BCN will block them.

AR 6 cluster nodes always pass beacon spots when skimmer spots are enabled. They cannot be disabled.

Contest definition

2026-03-30T04:47:21Z

Sm7iun: /* Other keys */

==Introduction==

Contest rules vary greatly and are typically defined by the contest organizers. 
The differences can be in points per QSO, multiplier determination and calculations, etc. 
To support a wide variety of rules and to allow for easy adding/changing of contest rules in DXLog, 
contest rules are defined and controlled through a contest config file. 

Contest config files are "semi human readable", plain text files located in the '''Contest''' subdirectory in 
DXLog's installation directory. A wide range of contest definition files are included in the DXLog standard installation. 
The contest config files in the protected installation directory are however not intended for editing or modification 
For this, there is a copy of the directory in Windows' unprotected AppData directory structure. 
Since this is a hidden directory, a drop down menu item is provided for easy access. (File | Open configuration directory) 

Each time DXLog is started, the content of the installation subdirectory and the AppData subdirectory is compared. 
If a contest config file in the installation subdirectory is newer than its copy in the AppData subdirectory 
(e.g. due to it being updated as part of a new DXLog release), the AppData file is overwritten. 

In the opposite case (e.g. due to own modifications of a contest config file), the AppData file remains unchanged. 
This means that any modifications of existing contest config files should be done in the AppData directory, but that 
such modifications may be overwritten if a newer version is distributed in a later DXLog release. 
To secure that a contest config file is not overwritten by future DXLog releases, create a file with a new name. 
The same mechanic, with a master directory and an AppData copy, applies to data base (i.e. pre-fill or call history) files. 

If you have developed a contest config file that is proven to be correct and that could be useful others, Please contact 
the development team to discuss adding it to DXLog's standard contest repertoire.

[[image:Configurationpaneltagged3.png|800px]] 
Relation between configuration keys and macros and their related text boxes and drop down menus in the contest configuration panel.
 

==File structure==

Each line in a contest definition file usually contains '''KEY + VALUE''' pairs. 
The pair is always separated by the "=" sign. For example:

<code>CONTESTNAME=9A CW</code>

This means the ''field key'' is '''CONTESTNAME''' and the ''field value'' is '''9A CW'''.

==Regular expressions==

You will see that in many cases DXLog is using regular expressions to verify condition validation and process entries.

If you are not familiar with regular expressions (regex for short) there are many online resources available. 
One tutorial can be found [https://www.regular-expressions.info/tutorial.html here].

For example, regular expressions are used to check if the user keyboard entry is valid against a condition or 
set of conditions, for QSO points calculations etc.

Regular expressions in the contest configuration file can be defined as fixed values, but they can 
also compare QSO data against fixed values.

Example: We want to validate the user entered data in some of the fields. For example, we want 
to validate that the user is allowed to enter NY, FL, GA, or MA in the EXCHANGE field on the contest 
configuration screen.

The contest configuration key for this operation is: <code>CFG_MULT_RGX_CHECK</code>. 

So to create a validation, as per the previous example, we need the following definition 
in the contest config file:

: <code>CFG_MULT_RGX_CHECK=^NY$|^FL$|^GA$|^MA$</code>

: <code>^</code> denotes start of the string <code>$</code> denotes end of the string <code>|</code> separates alternative matching patterns, forming a logical or

Another example is to validate that the Exchange field is a two digit number or a six position grid:

: <code>CFG_MULT_RGX_CHECK=^([0-9]{2}|[A-R]{2}[0-9]{2}[A-X]{2})$</code>

: <code>()</code> surrounds alternative matching patterns <code>{}</code> forms a repetition of the preceding matching pattern

QSO data is addressed using a origin key (CONFIG, SOURCE, or DEST) and a content key (CALLSIGN, EXCHANGE, DXCC, etc.). 
They are combined using "->". Examples of QSO data keys are CONFIG->POWER, SOURCE->DXCC, and DEST->RCVD.

Not all possible combinations of origin keys and content keys are valid. Please see below for valid combinations.

{|class="wikitable"
|+style="text-align:Left;"|Available origin keys
|-
| '''CONFIG'''
| Information originating from contest configuration panel. If empty, derived from callsign.
|-
| '''SOURCE'''
| Information relating to own station. Always derived from station callsign.
|-
| '''DEST'''
| Information relating to other station.
|}

{|class="wikitable"
|+style="text-align:Left;"|Available content key combinations
|-
| '''CONFIG'''
| '''->'''
| '''ARRLRR'''
| A regular expression that matches the two last digits of the current and the three previous years. As an example it is <tt><nowiki>^(20|19|18|17)$</nowiki></tt> in 2020.
|-
| '''CONFIG''' or '''SOURCE''' or '''DEST'''
| '''->'''
| '''CALL'''
| Callsign.
|-
| '''CONFIG'''
| '''->'''
| '''CATEGORY'''
| The dropdown menu text of the entry category selected in the contest configuration panel in upper case.
|-
| '''CONFIG'''
| '''->'''
| '''CLASS'''
| The contest's active power class as selected in the contest configuration panel in upper case.
|-
| '''SOURCE''' or '''DEST'''
| '''->'''
| '''CONT'''
| Continent. Two letter acronym.
|-
| '''CONFIG'''
| '''->'''
| '''CQZONE'''
| CQ zone as entered in the contest configuration panel zero padded to two digits.
|-
| '''SOURCE''' or '''DEST'''
| '''->'''
| '''CQZONE'''
| CQ zone derived from the callsign zero padded to two digits.
|-
| '''CONFIG'''
| '''->'''
| '''DXCC'''
| DXCC prefix as entered in the contest configuration panel.
|-
| '''SOURCE''' or '''DEST'''
| '''->'''
| '''DXCC'''
| Official DXCC prefix derived from the callsign where international airspace/waters is "-".
|-
| '''CONFIG'''
| '''->'''
| '''EXCHANGE'''
| The content of the contest exchange field in the contest configuration panel.
|-
| '''CONFIG'''
| '''->'''
| '''GRID'''
| The content of the grid field in the contest configuration panel.
|-
| '''CONFIG'''
| '''->'''
| '''ITUZONE'''
| ITU zone as entered in the contest configuration panel zero padded to two digits.
|-
| '''SOURCE''' or '''DEST'''
| '''->'''
| '''ITUZONE'''
| ITU zone derived from the callsign zero padded to two digits.
|-
| '''CONFIG'''
| '''->'''
| '''MODE'''
| The chosen contest mode in upper case.
|-
| '''DEST'''
| '''->'''
| '''MODE'''
| The current QSO mode.
|-
| '''CONFIG'''
| '''->'''
| '''OPNAME'''
| The content of the operator name field in the contest configuration panel.
|-
| '''CONFIG'''
| '''->'''
| '''OVERLAY'''
| The overlay menu selection text in upper case. (Note that this is not the Cabrillo overlay)
|-
| '''SOURCE''' or '''DEST'''
| '''->'''
| '''WPX'''
| Callsign prefix per WPX rules.
|-
| '''SOURCE''' or '''DEST'''
| '''->'''
| '''PFX_AREA'''
| The callsign prefix formatted as main DXCC prefix plus "." and the prefix digit. E.g. "SM.0" or "EA.7". Note that DXCC prefixes containing a number keeps this, e.g., OH0DX is prefix area "OH0.0".
|-
| '''CONFIG'''
| '''->'''
| '''POWER'''
| The content of the power field in the contest configuration panel.
|-
| '''DEST'''
| '''->'''
| '''RCVD'''
| First element in the received contest exchange.
|-
| '''DEST'''
| '''->'''
| '''RECINFO'''
| Second element in the received contest exchange.
|-
| '''DEST'''
| '''->'''
| '''RECINFO2'''
| Third element in the received contest exchange.
|-
| '''DEST'''
| '''->'''
| '''RECINFO3'''
| Fourth element in the received contest exchange.
|-
| '''CONFIG'''
| '''->'''
| '''STATE'''
| The content of the State/Province/Other field in the contest configuration panel.
|-
| '''CONFIG'''
| '''->'''
| '''STATION'''
| The station category text in upper case. (Not the Cabrillo station category)
|-
| '''DEST'''
| '''->'''
| '''TIME_HOUR'''
| The hour of the QSO time as a string with values from "0" to "23".
|}

===Formatting suffix===

An origin/content key combination can have a formatting suffix, similar to that for <tt>CABRILLO_LINE</tt>. 
For instance,

<code>DEST->RCVD{F=R,2,0}:SOURCE->ITUZONE</code>

will zero pad the received exchange to a length of two before comparing. ITUZONE and CQZONE are always two digits.

===Extension suffix===

An origin/content key combination can have an extension suffix, which can also be a regular expression. 
For instance

<code>DEST->RCVD:DEST->CONT+[MQY]</code>

will evaluate true when the received exchange is identical to your own continent abbreviation followed by either M, Q, or Y.

===Examples===

1. We want to validate a value which could change on each entry into the log.

For example, we want to calculate points for each QSO with the same country, on the 160m band, in the CW and SSB mode, with 1 point.

The relevant contest configuration key for QSO points calculation is <code>POINTS_FIELD_BAND_MODE</code>. 
To create the calculation, as per the previous example, we need the following definition in the contest config file:

<code>POINTS_FIELD_BAND_MODE=SOURCE->DXCC:DEST->DXCC;ALL;^160$;^(CW|SSB)$;1</code>

We can read this definition in the following way: 
If the <code>SOURCE</code> (our) DXCC is the same as <code>DEST</code> (other station's) DXCC and the 
band is 160 and the mode is CW or SSB then the QSO is worth 1 point. In the above definition notice 
the <code>SOURCE</code> and <code>DEST</code> keys. We can also use the <code>CONFIG</code> key.

2. We want to display a per-mode QSO breakdown for mixed mode contest entry

<code>SCORE=BY_BAND_MODE</code> 
<code>SCORE_DISPLAY=BAND;QSO;*RGX:CONFIG->MODE:MIX>>QSO(CW){CW};*RGX:CONFIG->MODE:MIX>>QSO(SSB){SSB};MULT1(CTY);DUP;POINTS</code>

'''Important:''' The first "QSO" key can not be made conditional due to internal limitations.

==Functions and FX expressions==

Some keys allow not only keywords but also functions as arguments.

Functions follow C# syntax and have access to all string, number, and boolean manipulation functions in the language plus a number of helper functions.

The keywords available for regular expressions (see above) area also available in functions.

Some keywords assume an expression that returns a string, like MULT1_FX and FIELD_RCVD_CHECK_FORMAT_FX.

Examples: 
<tt><nowiki>MULT1_FX=$FIELDVALUE.Substring(0,4)</nowiki></tt> 
<tt><nowiki>MULT1_FX=$FIELDVALUE.Substring(0,$FIELDVALUE.IndexOf('/'))</nowiki></tt>

The first example picks the first four characters in the string as multiplier. 
The second example picks the string following the first slash ("/") character as multiplier. 
Two variables are available: $FIELDVALUE which is the multiplier or exchange itself, and $CALLSIGN which is the other station's call.

===String helper functions===

{|class="wikitable"
|+style="text-align:Left;"|Available string helper functions
|-
| <tt><nowiki>Helpers.GetBrazilUF($FIELDVALUE,$CALLSIGN)</nowiki></tt>
| Returns the two letter Brazilian region. Uses the exchange if valid, otherwise derives it from the callsign.
|-
| <tt><nowiki>Helpers.GetLastLetter($FIELDVALUE)</nowiki></tt>
| Returns the last character of a callsign, including slashed number suffixes.
|-
| <tt><nowiki>Helpers.GetLastLetterPure($FIELDVALUE)</nowiki></tt>
| Returns the last character of a callsign with a slashed prefix and suffixes removed.
|-
| <tt><nowiki>Helpers.GetOblast($FIELDVALUE)</nowiki></tt>
| Returns the Russian region based on field which should be callsign.
|-
| <tt><nowiki>Helpers.GetOblastSPLO($FIELDVALUE,$CALLSIGN)</nowiki></tt> 
| Returns the Russian region based on field which should be RCVD. Uses the RDA exchange for SP/LO stations to determine oblast and the callsign for all others. Used in UA1DZ Memorial contest. Multiplier field must be FROM_DXCC.
|-
| <tt><nowiki>Helpers.GetPureCall($FIELDVALUE)</nowiki></tt> 
| Returns the field (callsign) without prefix, slashes, etc.
|-
| <tt><nowiki>Helpers.GetPrefixArea($FIELDVALUE, $CALLSIGN)</nowiki></tt> 
| Returns the prefix area as NN.0. Multiplier field must be FROM_DXCC.
|-
| <tt><nowiki>Helpers.GetPrefixAreaVEGeo($FIELDVALUE, $CALLSIGN)</nowiki></tt>
| Returns the prefix area as NN.0 but treats Canadian geographical prefixes (VY2, etc.) as own call areas. Multiplier field must be FROM_DXCC.
|-
| <tt><nowiki>Helpers.GetSARLArea($FIELDVALUE)</nowiki></tt>
| Returns the SARL contest call area based on field which should be callsign.
|-
| <tt><nowiki>Helpers.GetSuffix($FIELDVALUE)</nowiki></tt>
| Returns the callsign suffix (characters after last number) based on field which should be callsign.
|-
| <tt><nowiki>Helpers.PadNumber3($FIELDVALUE)</nowiki></tt>
| Returns a single or double digit string string padded to three digits. Useful for contests with mixed serial and letter exchange.
|-
| <tt><nowiki>Helpers.PadNumber2($FIELDVALUE)</nowiki></tt>
| Returns a single digit string padded to two digits. Useful for contests with mixed zone and letter exchange.
|-
| <tt><nowiki>Helpers.ExtendCountyLine($FIELDVALUE,length)</nowiki></tt>
| Extends abbreviated county line exchanges in North American QSO parties. E.g., MABAR/BER is converted into MABAR/MABER.
|-
| <tt><nowiki>Helpers.Canada13($FIELDVALUE)</nowiki></tt>
| Returns NL when exchange is NF or LB. Does nothing for all other values, such as ELBE or NFX.
|}

===String list helper functions===

Some keywords assume an expression that returns a '''list of strings''', like WINDOWS_CML_LIST_FX. 

{|class="wikitable"
|+style="text-align:Left;"|Available string list helper functions
|-
| <tt><nowiki>GetList_PrefixArea(dxccList,regex)</nowiki></tt>
| Creates a multiplier list with all call areas prefixes
|-
| <tt><nowiki>GetList_PrefixAreaVEGeo(dxccList,regex)</nowiki></tt>
| Creates a multiplier list including Canadian (VY1, etc.) call areas
|-
| <tt><nowiki>GetList_CustomRange(format,start,end)</nowiki></tt>
| Creates a list of numbered multipliers
|-
| <tt><nowiki>GetList_CustomArray(string,separator)</nowiki></tt>
| Creates a custom list
|-
| <tt><nowiki>GetList_BrazilUF()</nowiki></tt>
| Creates a list containing the 27 Brazilian regions
|-
| <tt><nowiki>GetList_Oblast()</nowiki></tt>
| Creates a list containing the 85 Russian regions
|-
| <tt><nowiki>GetList_SARLArea()</nowiki></tt>
| Creates a list containing the 13 SARL contest call areas
|-
| <tt><nowiki>GetList_GridArray(center,height,width))</nowiki></tt>
| Creates a list of four letter grids around center
|}

'''Examples'''

<tt><nowiki>GetList_PrefixArea(dxccList,"^LA$")</nowiki></tt> - Creates a multiplier list with all Norwegian call areas. 
<tt><nowiki>GetList_PrefixAreaVEGeo(dxccList,"^(VE|K)$)</nowiki></tt> - Creates a multiplier list with all US and Canadian prefixes. 
<tt><nowiki>GetList_CustomRange("00",1,6)</nowiki></tt> - Creates the list 00, 01, 02, 03, 04, 05, and 06. 
<tt><nowiki>GetList_CustomArray("AB|AC|AD|AK|AM","|")</nowiki></tt> - Creates the list AB, AC, AD, AK, and AM. 
<tt><nowiki>GetList_GridArray(ownGrid,11,11)</nowiki></tt> - Creates a list of 121 grids centered around own location. 
<tt><nowiki>GetList_GridArray("JP81",9,9)</nowiki></tt> - Creates a list of 81 grids centered around JP81. 

===Number helper functions===

Some keywords assume an expression returning '''a number''', such as <tt>SCORE_TOTAL_FX</tt> and the second element of <tt>POINTS_CALC_F</tt>.

These assume FLEE syntax (see below).

<tt>SCORE_TOTAL_FX</tt> is the formula for the score for an individual QSO. 
Available variables available are <tt>$FIELDVALUE.Points</tt>, <tt>$FIELDVALUE.Mult1</tt>, 
<tt>$FIELDVALUE.Mult2</tt>, and <tt>$FIELDVALUE.Mult3</tt> having the values of the corresponding 
sums in the Summary window.

Example: <tt>SCORE_TOTAL_FX=$FIELDVALUE.Points+$FIELDVALUE.Mult1*2+$FIELDVALUE.Mult2*5</tt>
Example: <tt>SCORE_TOTAL_FX=$FIELDVALUE.Points*($FIELDVALUE.Mult1+If($FIELDVALUE.Mult2>10,10,$FIELDVALUE.Mult2))</tt>

<tt>POINTS_CALC_F</tt> is the formula for the points for certain QSO conditions.

===Boolean helper functions===

Other keys assume a '''boolean expression''' which can be either a regular expression (as described above) or 
an FX() expression. Examples are FIELD_RCVD_FX_CHECK and the first argument of MULT1_EXCEPTION. 
The syntax and operator repertoire is C#.

Examples: 
<tt><nowiki>MULT1_EXCEPTION=FX(Helpers.GetLastLetter("CONFIG->CALLSIGN").Equals(Helpers.GetLastLetter("DEST->CALL")));NONE</nowiki></tt> 
<tt><nowiki>MULT1_EXCEPTION=FX(("CONFIG->CALLSIGN").Substring(0,3).Equals(("DEST->CALL").Substring(0,3)));NONE</nowiki></tt> 
<tt><nowiki>MULT1_EXCEPTION=DEST->RCVD:^[KNS]DE;FX(("DEST->RCVD").Substring(1,2))</nowiki></tt> 

The first example does not count the QSO as a multiplier if the last letter is the same in the station's 
callsign and own callsign. The second example does not count the QSO as a multiplier if the first three characters 
is the same in the station's callsign and own callsign. The third example counts the first two characters of the 
exchange as multiplier if it starts with KDE, NDE or SDE.

The only available boolean helper function is:

<tt><nowiki>Helpers.Between(number, min, max)</nowiki></tt> - Returns true if number is between min and max.

===Available syntax for arithmetic expressions===

[[image:fleesyntax.png|500px]]

==Custom multiplier lists==

A custom multiplier list can only be used for multiplier type CUSTOM. FX type multipliers can not use a 
a listed set of multipliers but rely on a helper function to create its multiplier list, such as <tt>GetList_CustomRange()</tt>.

===Plain list of custom multipliers===

A list of custom multipliers is started by <tt>[MULTIPLIERS START]</tt> and ends with <tt>[MULTIPLIERS END]</tt>. 
The syntax for a multiplier having more than one name is shown below. In this example both NK and NR 
will count as the same multiplier; Norwich.

Example:
<tt>
: [MULTIPLIERS START]
: ...
: NL=London N1-22
: NN=Northampton
: NP=Newport
: NK{NK;NR}=Norwich
: NW=London NW1-11
: OL=Oldham
: OX=Oxford
: ...
: [MULTIPLIERS END]
</tt>

===Conditional lists of custom multipliers===

For contests such as US state QSO parties there are two types of participants with different sets of custom multipliers. 
To support this, a multiplier list can be conditional just like default messages. The regular expression can be of any type 
and check EXCHANGE, DXCC, CONT or whatever is suitable.

Syntax:
<tt>
: [MULTIPLIERS START]
: [VALID FOR=Regex1]
: M1=First multiplier 1
: M2=First multiplier 2
: ...
: [END VALID FOR]
: [VALID FOR=Regex2]
: L1=Second multiplier 1
: L2=Second multiplier 2
: ...
: [END VALID FOR]
: [MULTIPLIERS END]
</tt>

Example:
<tt>
: [MULTIPLIERS START]
: [VALID FOR=CONFIG->EXCHANGE:^(ADA|ALL|ARM|BEA|BED|BER|BLA|BRA|BUX)$]
: AK=Alaska
: AL=Alabama
: AR=Arkansas
: AZ=Arizona
: CO=Colorado
: ...
: [END VALID FOR]
: ...
: [MULTIPLIERS END]
</tt>

===Grouped list of custom multipliers===

Multipliers can be grouped for better display in the custom worked multipliers window enabled 
with the <tt>WINDOWS_CML_ENABLED</tt> key. The string following <tt>Group-></tt> is the displayed 
name of the group. The name has no impact on scoring. The syntax for alternative names for the same 
multiplier is different from the straight list. Alternative names for the same multiplier are 
instead separated with a slash. In the example below, QU, QC, and QUE will all count as the same 
multiplier; Quebec.

Example:
<tt>
: [MULTIPLIERS START]
: Group->K1_: CT,MA,ME,NH,RI,VT
: Group->K2_: NJ,NY
: Group->K3_: DE,PA,MD/DC
:...
: Group->VE1: NS
: Group->VE2: QC/QU/QUE
: Group->VE3: ON/ONT
: Group->VE4: MB/MAN
: ...
: [MULTIPLIERS END]
</tt>

Tip: In group names, the underscore character will be displayed as space. This is a simple way to 
create an even column width when groups have different length.

==General contest description keys==
{|class="wikitable"
|+style="text-align:Left;"|These keys are used for general contest description in the contest config file, such as the contest name, link to the rules etc.
|'''CONTESTGROUP'''
| Used for group contest when displaying the config screen for contest selection.
| e.g., DIGITAL MODES, 9A LOCAL CONTEST, etc.
|-
|'''CONTESTNAME'''
| The contest name as it will be shown and recognized in the contest selection box. Note: this can be same as the Cabrillo contest name, but usually it is the full contest name.
| This field is mandatory and must be unique for all files in contest definition directory.
|-
|'''CONTESTEXCH'''
| Web link to definition of contest exchange. Shown when entering invalid data in configuration panel's exchange field.
| e.g., https://www.iota-world.org/
|-
|'''CONTESTRULES'''
| External HTTP Link to contest rules. Adds "Contest rules" item to Help menu.
| e.g., https://www.cqww.com/rules.htm
|-
|'''CONTESTWEB'''
| External HTTP Link to contest rules. Adds "Contest web" item to Help menu.
| e.g., https://www.cqww.com
|-
|'''CONTEST_INFORMATION'''
| String with helpful information about operating the current contest. Adds "Contest information" item to Help menu and "Info" button in the Contest configuration window.
| e.g., Bonus stations are not recognized.\nLog non-members as 0000.
|}

==Contest configuration panel control keys==

{|class="wikitable"
|+style="text-align:Left;"|These keys are used for setting the contest configuration variables in the user configuration window.
|'''CATEGORIES'''
| Semicolon-separated list of contest categories shown in the category selection dropdown menu in the contest configuration panel. '''Important''': When defining own categories, the values of CABRILLO_OPERATOR, CABRILLO_TRANSMITTER, and CABRILLO_ASSISTED may have to be changed from their defaults. Also contests with only EDI export needs correct Cabrillo export keys. C.f the Cabrillo section below.
| Default value: Single operator, assisted;Single operator;Multi-operator, single transmitter; Multi-operator, two transmitters;Multi-operator, multi-transmitter;Checklog
|-
|'''CATEGORY_MODES'''
| Semicolon-separated list of contest modes shown in the mode selection dropdown menu in the contest configuration panel. '''Important:''' There is no contest mode key for CATEGORY-MODE. Phone, SSB, and AM are SSB. CW is CW. RTTY is RTTY. Mixed is MIXED. Digital, PSK31, JT65, FT8, and other digital modes are DIGI.
| Default value: CW;SSB;Mixed
|-
|'''CLASS'''
| Semicolon-separated list of contest power classes shown in the class selection dropdown menu in the contest configuration panel.
| Default value: High;Low;QRP
|-
|'''CFG_EMAIL_MANDATORY'''
| Controls if the Email field in the contest configuration panel requires an entry or can be empty. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_MULT'''
| Controls the use of the exchange field in contest configuration panel. Valid values are: ON and OFF. If OFF, the exchange field is greyed out.
| Default value: OFF
|-
|'''CFG_MULT_DX_ALLOWED'''
| Controls if "DX" is an acceptable entry in exchange field. For example in ARRL DX Contest, all USA/VE stations needs to enter their state/province, while all other stations enters DX here. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_MULT_SLASH_ALLOWED'''
| Allows the use of "/" in the Exchange field as separator for contests where the exchange can be one or more elements of the same type, such as county-line stations in some US QSO parties where a station can belong to more than one counties and thereby represent more than one multiplier in one QSO. '''Important:''' CFG_MULT_SLASH_IGNORED and CFG_MULT_SLASH_ALLOWED must never both be YES. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_MULT_SLASH_IGNORED'''
| Allows the use of "/" in the Exchange field as part of the exchange itself rather than as a separator '''Important:''' CFG_MULT_SLASH_IGNORED and CFG_MULT_SLASH_ALLOWED must never both be YES. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_MULT_MANDATORY'''
| Controls if the exchange field requires an entry or can be empty. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_MULT_ERRORTEXT'''
| Defines error text which is shown if the validity test for the exchange field fails. For example, in ARRL DX Contest, if the user enters a state abbreviation which is not in the approved list.
| Default value: "Invalid value in exchange field!"
|-
|'''CFG_MULT_FROM'''
| Alternative to using a regular expression to check validity of entry in Exhange field. Valid values are CUSTOM_MULT_LIST, CQZONE, and ITUZONE. '''Important''': CUSTOM_MULT_LIST obviously cannot be used if own exchange is not a valid multiplier
| Default value: Unused
|-
|'''CFG_MULT_RGX_CHECK'''
| Regular expression used to test validity of entry in Exchange field. Note that the regular expression can include the key CUSTOM_MULT_LIST meaning that any entry listed in the custom multiplier list is considered valid. Example: <tt><nowiki>CFG_MULT_RGX_CHECK=^AF$|^AS$|^EU$|^NA$|^OC$|^SA$|CUSTOM_MULT_LIST</nowiki></tt>
| Default value: ALL
|-
|'''CFG_CQZONE_ERRORTEXT'''
| Defines the error text shown if the entry in the CQ zone field fails the validity test.
| Default value: "Invalid CQ zone!"
|-
|'''CFG_CQZONE_MANDATORY'''
| Controls if the CQ zone field requires an entry or can be empty. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_GRID_ERRORTEXT'''
| Defines the error text shown if the entry in the GRIDSQUARE field fails the validity test.
| Default value: "Invalid entry in gridsquare field!"
|-
|'''CFG_GRID_MANDATORY'''
| Controls if the GRIDSQUARE field requires an entry or can be blank. Valid values are: YES and NO. Is automatically set to YES if contest has QRB-based scoring.
| Default value: NO
|-
|'''CFG_GRID_RGX_CHECK'''
| Regular expression used to test validity of data entered in the GRIDSQUARE field.
| Default value: <tt><nowiki>^[A-R][A-R][0-9][0-9][A-X][A-X]$</nowiki></tt>
|-
|'''CFG_ITUZONE_ERRORTEXT'''
| Defines error text shown if the entry in the ITU zone field fails the validity test.
| Default value: "Invalid ITU zone!"
|-
|'''CFG_ITUZONE_MANDATORY'''
| Controls if the ITU zone field requires an entry or can be empty. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_MYDXCC_ERRORTEXT'''
| Defines the error text shown if the entry in the DXCC field fails the validity test.
| Default value: "Unrecognized DXCC from DXCC field. Please enter valid country prefix in DXCC field"
|-
|'''CFG_MYDXCC_MANDATORY'''
| Controls if the DXCC field requires an entry or can be empty. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_OPNAME_ERRORTEXT'''
| Defines the error text shown if the entry in the operator name field fails the validity test.
| Default value: "Operator name field is mandatory!"
|-
|'''CFG_OPNAME_MANDATORY'''
| Controls if the operator name field requires an entry or can be empty. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_POWER_ERRORTEXT'''
| Defines the error text shown if the entry in the power field fails the validity test.
| Default value: "Invalid value in power field!"
|-
|'''CFG_POWER_MANDATORY'''
| Controls if the power field requires an entry or can be empty. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_POWER_RGX_CHECK'''
| Regular expression used to determine the validity of the power field entry.
| Default value: ALL
|-
|'''CFG_STATE_ERRORTEXT'''
| Defines the error text shown if the entry in the state/province/other field fails the validity test.
| Default value: "Invalid value in state/other field!"
|-
|'''CFG_STATE_FROM=CUSTOM_MULT_LIST'''
| Defines a list-based validity test for the state/province/other field. Alternative to to using a regular expression.
| Default value: absent
|-
|'''CFG_STATE_MANDATORY'''
| Controls if the state/province/other field requires an entry or can be empty. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_STATE_RGX_CHECK'''
| Regular expression used to test validity of entry in state/province/other field. Note that the regular expression can include the key CUSTOM_MULT_LIST meaning that any entry listed in the custom multiplier list is considered valid. Example: <tt><nowiki>CFG_STATE_RGX_CHECK=^YL$|^OM$|CUSTOM_MULT_LIST</nowiki></tt>
| Default value: ALL
|-
|'''OVERLAY'''
| Semicolon-separated list of contest overlays shown in the Overlay dropdown menu in the contest configuration panel. Disable CATEGORY-OVERLAY in the Cabrillo export by assigning OVERLAY one single value.
| Default value: ---;Classic;Rookie;Tribander/Single element;Youth;Novice/Tech;Over 50
|-
|'''OVERLAY_ASSISTED'''
| Single keyword or semicolon-separated list of YES/NO controlling if an overlay represents an unassisted category. With a single keyword, this applies to all overlays. Must have one or the same number of entries as OVERLAY. If the selected overlay corresponds to a NO, incoming cluster spots are blocked. In other cases, CABRILLO_ASSISTED decides.
| Default value: YES
|-
|'''STATION'''
| Semicolon-separated list of contest station categories shown in the Station dropdown menu in the contest configuration panel.
| Default value: Fixed;Distributed;Headquarter;Mobile;Portable; Rover;Rover-Limited;Rover-Unlimited;Expedition;School
|}

==Cabrillo export keys==

===Contest configuration keys===

{|class="wikitable"
|+style="text-align:Left;"|
| '''CABRILLO_ASSISTED'''
| Semicolon-separated list of mapping of categories to Cabrillo assistance types. MUST have the same number of entries as the defined contest categories. Valid list items are ASSISTED and NON-ASSISTED. '''Important: When a NON-ASSISTED category is selected, incoming cluster spots are blocked.'''
| Default value: ASSISTED;NON-ASSISTED;ASSISTED;ASSISTED;ASSISTED;ASSISTED
|-
| '''CABRILLO_ASSISTED_DISABLED'''
| No CATEGORY-ASSISTED line will be included in exported file. Tip: With this set to YES, cluster spots are never blocked.
| Default value: NO.
|-
| '''CABRILLO_BAND''' '''CABRILLO_BAND_SPECIAL'''
| Semicolon-separated list of band definition names for contests with band-limited categories. For value AUTO the band category will be ALL unless the log only contains QSO from a single band. In this case the band category will be this single band. For all other values of the key, log content is ignored. If only assigned a single value, such as 10M, ALL, or AUTO, this will be valid for all categories. Must be accompanied by a LIVESCORE_BANDS key when non standard values are used. Band names are Cabrillo convention 160M, ...6M, 2M, 222, 432, .... CABRILLO_BAND_SPECIAL allows the use of non-WWROF-standard values.
| Default value: AUTO;AUTO;ALL;ALL;ALL;ALL
|-
| '''CABRILLO_CLUB_FIELD'''
| Club name for Cabrillo export. Overrides the club field in the contest configuration window. Valid values are STATE or EXCHANGE.
| No default value
|-
| '''CABRILLO_CONTEST_NAME'''
| Formal contest name for Cabrillo export. If name contains <tt>{MODE}</tt> this will be replaced by the selected contest mode capitalized.
| No default value
|-
| '''CABRILLO_DEF_RECINFO''' '''CABRILLO_DEF_RECINFO2''' '''CABRILLO_DEF_RECINFO3'''
| Value to use in Cabrillo export if field is empty.
| Default value: Empty
|-
| '''CABRILLO_EXPORT_TYPE'''
| Controls structure of Cabrillo export. Valid values: PER_MODE and ALL.
| Default value: ALL
|-
| '''CABRILLO_LINE'''
| Use: <tt>CABRILLO_LINE=FREQ;MODE;DATE;TIME;MYCALL;SENT;NR{F=R,3,0,4}</tt> Data is taken from the field names and added to the Cabrillo line in the order entered. FREQ represents frequency of QSO, MODE represents mode etc. For more details on valid keywords and the use of conditional entries, see below.
| No default value
|-
| '''CABRILLO_LOCATION'''
| Semicolon-separated list of mapping of contest categories to Cabrillo LOCATION key. If defined, MUST have the same number of entries as the defined contest categories. Any string is a valid value. If left undefined, contest category has no effect on LOCATION in Cabrillo export. Alternative to CABRILLO_LOCATION_FIELD.
| Default value: Disabled
|-
| '''CABRILLO_LOCATION_FIELD'''
| Defines the source of the LOCATION: key in the Cabrillo export. Valid values are EXCHANGE, STATE, GRID, GRID4, GRID2, ITUZONE, and CQZONE. Alternative to CABRILLO_LOCATION.
| Default value: Disabled
|-
| '''CABRILLO_MODES'''
| Semicolon-separated list of mapping of the contest's modes (as defined by the MODES key) to Cabrillo modes in QSO lines. MUST have the same number of entries as the defined number of modes for the contest. WWROF defined values are CW, PH, DG, RY, and FM. See below for the full list of de-facto standard mode acronyms. Must be accompanied by a LIVESCORE_MODES key when non standard values are used.
| Default value: CW;PH
|-
| '''CABRILLO_OPERATOR''' '''CABRILLO_OPERATOR_SPECIAL'''
| Semicolon-separated list of mapping of categories to to Cabrillo operator count. MUST have the same number of entries as the defined contest categories. Valid list items are SINGLE-OP, MULTI-OP, and CHECKLOG. Must be accompanied by a LIVESCORE_OPERATOR key when non standard values are used. CABRILLO_OPERATOR_SPECIAL allows the use of non-WWROF-standard values.
| Default value: SINGLE-OP;SINGLE-OP; MULTI-OP;MULTI-OP;MULTI-OP;CHECKLOG
|-
| '''CABRILLO_OVERLAY''' '''CABRILLO_OVERLAY_SPECIAL'''
| Semicolon-separated list of mapping of category overlays to Cabrillo overlays. MUST have the same number of entries as the defined overlays. Any string is a valid entry. It is possible to block incoming cluster spots for one or several overlays. C.f. OVERLAY_ASSISTED. CABRILLO_OVERLAY_SPECIAL allows the use of non-WWROF-standard values.
| Default value: ;CLASSIC;ROOKIE;TB-WIRES;YOUTH;NOVICE-TECH;OVER-50
|-
| '''CABRILLO_OVERLAY_DISABLED'''
| Suppresses CATEGORY-OVERLAY in export.
| Default value: NO
|-
| '''CABRILLO_POWER''' '''CABRILLO_POWER_SPECIAL'''
| Semicolon-separated list of mapping of category power classes to Cabrillo power classes. MUST have the same number of entries as the contest's power classes. List items can be any string but WWROF defined keywords are HIGH, LOW, and QRP. Must be accompanied by a LIVESCORE_POWER key when non standard values are used. CABRILLO_POWER_SPECIAL allows the use of non-WWROF-standard values.
| Default value: HIGH;LOW;QRP
|-
| '''CABRILLO_QTC_LINE'''
| Definition of Cabrillo output for QTC. C.f. '''CABRILLO_LINE'''. Valid keywords are: FREQ, MODE, DATE, TIME, RCVDBY, GRNUM, SENTBY, QTCTIME, QTCCALL, and QTCSERIAL.
| Default value: Disabled
|-
| '''CABRILLO_STATION''' '''CABRILLO_STATION_SPECIAL'''
| Semicolon-separated list of mapping of station categories to Cabrillo station categories. MUST have the same number of entries as the defined station categories. CABRILLO_STATION_SPECIAL allows the use of non-WWROF-standard values.
| Default value: FIXED;DISTRIBUTED;HQ;EXPLORER;MOBILE;PORTABLE;ROVER; ROVER-LIMITED;ROVER-UNLIMITED;EXPEDITION;SCHOOL
|-
| '''CABRILLO_TIME''' '''CABRILLO_TIME_SPECIAL'''
| Semicolon-separated list of duration for each contest category. '''Important:''' Must have the same number of entries as there are contest categories. WWROF defined values are 6-HOURS, 8-HOURS, 12-HOURS, and 24-HOURS. CABRILLO_TIME_SPECIAL allows the use of non-WWROF-standard values.
| Default value: Disabled
|-
| '''CABRILLO_TRANSMITTER''' '''CABRILLO_TRANSMITTER_SPECIAL'''
| Semicolon-separated list of mapping of categories to Cabrillo operator counts. '''Important:''' Must have the same number of entries as the defined contest categories. WWROF defined values are ONE, TWO, LIMITED, UNLIMITED, and SWL. Must be accompanied by a LIVESCORE_TRANSMITTER key when non standard values are used. CABRILLO_TRANSMITTER_SPECIAL allows the use of non-WWROF-standard values.
| Default value: ONE;ONE;ONE;TWO;UNLIMITED;UNLIMITED
|}

===CABRILLO_LINE keywords===

Important note: If you want to take full control of the columns to e.g. concatenate fields in the export, 
this is done by adding a trailing asterisk ("*") to the keys below. This will remove the extra space 
following a field to guarantee separation. Extra spaces required to align to certain character positions 
can be added using the <tt>DUMMY</tt> keyword.

Surrounding the keyword with parentheses (e.g., <tt>(EXCHANGE)</tt>) means the key is optional at import. 
This typically only works for keywords at the end of the line, such as STN.

{|class="wikitable"
|+style="text-align:Left;"|
| '''Key'''
| '''Content'''
| '''Default format'''
|-
| <tt>CALL</tt>
| Logged station's call.
| <tt>{F=L,13, }</tt>
|-
| <tt>DATE</tt>
| Date of QSO. Format YYYY-MM-DD.
| <tt>{F=L,10, }</tt>
|-
| <tt>DUMMY</tt>
| Only spaces.
| <tt>{F=L,5, }</tt>
|-
| <tt>DXCC</tt>
| DXCC of logged station. Derived from CTY database.
| <tt>{F=L,6, }</tt>
|-
| <tt>EXCHANGE</tt>
| Exchange as entered in the contest configuration panel. Can optionally take a string function instead of formatting arguments within curly brackets. E.g. <tt><nowiki>EXCHANGE{FX=$FIELDVALUE.Substring(0,4)}</nowiki></tt> Breaks up slashed entries.
| <tt>{F=L,6, }</tt>
|-
| <tt>FREQ</tt>
| Frequency in kilohertz.
| <tt>{F=R,6, }</tt>
|-
| <tt>FREQMHZ</tt>
| Frequency in Megahertz.
| <tt>{F=R,6, }</tt>
|-
| <tt>GRID</tt>
| Grid locator as entered in the contest configuration panel.
| <tt>{F=L,6, }</tt>
|-
| <tt>GRID4</tt>
| First four positions of the grid locator entered in the contest configuration panel.
| <tt>{F=L,6, }</tt>
|-
| <tt>MODE</tt>
| QSO mode with Cabrillo coding.
| <tt>{F=L,2, }</tt>
|-
| <tt>MYCALL</tt>
| Own call as entered in the contest configuration panel.
| <tt>{F=L,13, }</tt>
|-
| <tt>MYCQZONE</tt>
| Own CQ zone as entered in the contest configuration panel.
| <tt>{F=L,2,0,6}</tt>
|-
| <tt>MYDXCC</tt>
| Own DXCC prefix as entered in the contest configuration panel.
| <tt>{F=L,6, }</tt>
|-
| <tt>MYITUZONE</tt>
| Own ITU zone as entered in the contest configuration panel.
| <tt>{F=L,2,0,6}</tt>
|-
| <tt>NOTHING</tt>
| An empty string. Add a trailing asterisk for literally nothing.
| <tt>{F=L,0, }</tt>
|-
| <tt>NR</tt>
| Own serial number for the QSO.
| <tt>{F=R,3,0,6}</tt>
|-
| <tt>OPNAME</tt>
| Operator name as entered in the contest configuration panel.
| <tt>{F=L,10, }</tt>
|-
| <tt>PERIOD</tt>
| Contest period.
| <tt>{F=L,2, }</tt>
|-
| <tt>POWER</tt>
| Station power string as entered in the contest configuration panel.
| <tt>{F=L,6, }</tt>
|-
| <tt>PREV_RCVD</tt>
| First element in previously received exchange.
| <tt>{F=L,3,0}</tt>
|-
| <tt>PREV_RECINFO</tt>
| Second element in previously received exchange.
| <tt>{F=L,3,0}</tt>
|-
| <tt>PREV_RECINFO2</tt>
| Third element in previously received exchange.
| <tt>{F=L,3,0}</tt>
|-
| <tt>PREV_RECINFO3</tt>
| Fourth element in previously received exchange.
| <tt>{F=L,3,0}</tt>
|-
| <tt>PTS</tt>
| Points of QSO.
| <tt>{F=R,3,0}</tt>
|-
| <tt>RCVD1</tt>
| Received RST.
| <tt>{F=L,3, }</tt>
|-
| <tt>RCVD2</tt>
| First element in received exchange without RST. Can optionally take a string function instead of formatting arguments within curly brackets. E.g., <tt><nowiki>RCVD2{FX=$FIELDVALUE.Substring(0,4)}</nowiki></tt>
| <tt>{F=L,6, }</tt>
|-
| <tt>RECINFO</tt>
| Second element of received exchange. Can optionally take a string function instead of formatting arguments within curly brackets. E.g., <tt><nowiki>RECINFO{FX=$FIELDVALUE.Substring(0,4)}</nowiki></tt>
| <tt>{F=L,5, }</tt>
|-
| <tt>RECINFO2</tt>
| Third element of received exchange. Can take optionally a string function instead of formatting arguments within curly brackets. E.g., <tt><nowiki>RECINFO2{FX=$FIELDVALUE.Substring(0,4)}</nowiki></tt>
| <tt>{F=L,5, }</tt>
|-
| <tt>RECINFO3</tt>
| Fourth element of received exchange. Can optionally take a string function instead of formatting arguments within curly brackets. E.g., <tt><nowiki>RECINFO3{FX=$FIELDVALUE.Substring(0,4)}</nowiki></tt>
| <tt>{F=L,5, }</tt>
|-
| <tt>SENT</tt>
| Sent RST.
| <tt>{F=L,3, }</tt>
|-
| <tt>SLASH</tt>
| The character '/'. Add trailing asterisk to remove separating space.
| <tt>{F=L,1, }</tt>
|-
| <tt>STATE</tt>
| State or province as entered in the contest configuration panel.
| <tt>{F=L,5, }</tt>
|-
| <tt>STN</tt>
| Station. "0" for all stations except radio 2 in SO2R, the multiplier station in Multi/Single, and Run2 in Multi/Two which all are "1". '''Important:''' It is a good idea to wrap STN in parentheses to make it optional at import. Some loggers only include it for certain categories.
| <tt>{F=L,2, }</tt>
|-
| <tt>TIME</tt>
| Time of QSO. Format HHMM.
| <tt>{F=L,4, }</tt>
|-
| <tt>'</tt>
| A literal. E.g., <tt>'ABC{F=L,6,}</tt> means "ABC ". Add * after the literal (<tt>'ABC*</tt>) avoid a trailing space.
| <tt>{F=L,6, }</tt>
|-
|}

===CABRILLO_LINE formatting and conditionals===

<tt>CABRILLO_LINE</tt> formatting information is contained within curly brackets with the following syntax: 

<tt>{''F=AL'',''PS'',''PC''(,''TS'')}</tt>

: ''F='': Formatting flag
: ''AL'': Alignment, can be ''L'' (for left) or ''R'' (for right)
: ''PS'': Padded size. Total size of text including character padding.
: ''PC'': Character used for padding. E.g., 0 for serial numbers.
: ''TS'': Total size of field. Space padding to the right is used to reach this size. Optional.

Example: <tt>RCVD2{F=R,3,0,4}</tt> 

Means <tt>RCVD2</tt> field value will be aligned right, to a length of 3 characters. The "0" character is 
used to pad to the specified length. Total size will be 4 characters (padding with spaces to reach 4). 
This means that if <tt>RCVD2</tt> field value is "1", it will be formatted as " 001" in the Cabrillo QSO line.

Regardless if total size is specified or not, each field will always be surrounded by spaces.

For some keys it is possible to replace the formatting information with a string operation, using an <tt>FX=</tt> 
syntax and the <tt>$FIELDVALUE</tt> keyword to represent a string containing the field's characters.

<tt>CABRILLO_LINE</tt> also supports conditional formatting using a <tt>*RGX:</tt> syntax.

Example: <tt><nowiki>*RGX:SOURCE->DXCC:^(DL|OE)$>>EXCHANGE{F=L,6, }/NR{F=R,3,0,6};</nowiki></tt> 

means the content of the Exchange box in the contest configuration panel station for German and Austrian 
stations, otherwise a three position serial number. Both of total length 6.

per-own-DXCC conditional formatting is also supporting using a <tt>*NN></tt> syntax

Example: <tt><nowiki>*DL>EXCHANGE{F=L,6, }/NR{F=R,3,0,6};</nowiki></tt> 

means the same as the above example, but only for German stations. This conditional can 
also be repeated, to cover several DXCC entities.

===CABRILLO_QTC_LINE keywords===

{|class="wikitable"
|+style="text-align:Left;"|
| '''Key'''
| '''Content'''
| '''Format'''
|-
| <tt>FREQ</tt>
| Frequency in kilohertz
| 6 positions, right adjusted
|-
| <tt>MODE</tt>
| Mode when receiving QTC
| 3 positions, left adjusted
|-
| <tt>DATE</tt>
| Date QTC exchanged
| 12 positions
|-
| <tt>TIME</tt>
| Time QTC exchanged
| 4 positions
|-
| <tt>RCVDBY</tt>
| Call of receiving station
| 13 positions, left adjusted
|-
| <tt>GRNUM</tt>
| Group number of QTC
| 10 positions, left adjusted
|-
| <tt>SENTBY</tt>
| Call of sending station
| 13 positions, left adjusted
|-
| <tt>QTCTIME</tt>
| Time in QTC line
| 4 positions
|-
| <tt>QTCCALL</tt>
| Call in QTC line
| 13 positions, left adjusted
|-
| <tt>QTCSERIAL</tt>
| Serial in QTC line
| 3 positions, right adjusted
|-
|}

===Configuration keys' relation to Cabrillo export===

{|class="wikitable"
|+style="text-align:Left;"|Default relation between contest category configuration and Cabrillo export 
!'''Key type'''
!'''DXLog Key'''
!'''Cabrillo key'''
!colspan="6"|'''Default values'''
|-
| Configuration
| CATEGORIES
|
| Single operator, assisted
| Single operator
| Multi-operator, single transmitter
| Multi-operator, two transmitter
| Multi-operator, multi-transmitter
| Checklog
|-
| Cabrillo
| CABRILLO_OPERATOR
| CATEGORY-OPERATOR
| style="white-space: nowrap;" | SINGLE-OP
| style="white-space: nowrap;" | SINGLE-OP
| MULTI-OP
| MULTI-OP
| MULTI-OP
| CHECKLOG
|-
| Cabrillo
| CABRILLO_TRANSMITTER
| CATEGORY-TRANSMITTER
| ONE
| ONE
| ONE
| TWO
| UNLIMITED
| UNLIMITED
|-
| Cabrillo
| CABRILLO_ASSISTED
| CATEGORY-ASSISTED
| ASSISTED
| style="white-space: nowrap;" | NON-ASSISTED
| ASSISTED
| ASSISTED
| ASSISTED
| ASSISTED
|-
| Cabrillo
| CABRILLO_BAND
| CATEGORY-BAND
| AUTO
| AUTO
| ALL
| ALL
| ALL
| ALL
|}

{|class="wikitable"
|+style="text-align:Left;"|Default relation between contest overlay configuration and Cabrillo export 
!'''Key type'''
!'''DXLog Key'''
!'''Cabrillo key'''
!colspan="5"|'''Default values'''
|-
| Configuration
| OVERLAY
|
| style="width:150px;"|<nowiki>---</nowiki>
| style="width:150px;"|School
| style="width:150px;"|Dxpedition
| style="width:150px;"|Headquarter
| style="width:150px;"|...
|-
| Cabrillo
| style="white-space: nowrap;" | CABRILLO_OVERLAY
| style="white-space: nowrap;" | CATEGORY-OVERLAY
| style="white-space: nowrap;" | Key omitted
| CLASSIC
| ROOKIE
| TB-WIRES
| ...
|}

{|class="wikitable"
|+style="text-align:Left;"|Default relation between contest power class configuration and Cabrillo export 
!'''Key type'''
!'''DXLog Key'''
!'''Cabrillo key'''
!colspan="5"|'''Default values'''
|-
| Configuration
| CLASS
|
| style="width:150px;"|High
| style="width:150px;"|Low
| style="width:150px;"|QRP
|-
| Cabrillo
| CABRILLO_POWER
| CATEGORY-POWER
| HIGH
| LOW
| QRP
|}

{|class="wikitable"
|+style="text-align:Left;"|Default relation between contest mode category and Cabrillo export 
!'''Key type'''
!'''DXLog Key'''
!'''Cabrillo key'''
!colspan="5" | '''Default values'''
|-
| Configuration
| CATEGORY_MODES
|
| style="width:170px;" | CW
| style="width:170px;" | SSB
| style="width:170px;" | Mixed
|-
| Cabrillo
| N/A
| CATEGORY-MODE
| CW
| SSB
| MIXED
|}

{|class="wikitable"
|+style="text-align:Left;"|CATEGORY_MODE to CATEGORY-MODE mapping
!'''Value of CATEGORY_MODE'''
!'''Resulting CATEGORY-MODE'''
|-
| Phon*
| SSB
|-
| SSB
| SSB
|-
| FM
| FM
|-
| AM
| AM
|-
| CW
| CW
|-
| RTTY*
| RTTY
|-
| FT*
| DIGI
|-
| Digi*
| DIGI
|-
| *PSK*
| BPSK
|-
| All others
| MIXED
|-

{|class="wikitable"
|+style="text-align:Left;"|Default relation between available contest QSO modes and Cabrillo export 
!'''Key type'''
!'''DXLog Key'''
!'''Cabrillo key'''
!colspan="5" | '''Default values'''
|-
| Configuration
| MODES
|
| style="width:150px;" | CW
| style="width:150px;" | SSB
|-
| Cabrillo
| CABRILLO_MODES
| style="width:150px;" | QSO
| CW
| PH
|}

{|class="wikitable"
|+style="text-align:Left;"|Default relation between contest band category and Cabrillo export 
!'''Key type'''
!'''DXLog Key'''
!'''Cabrillo key'''
!colspan="6" | '''Default values'''
|-
| Configuration
| BANDS
| style="width:130px;" |
| style="width:130px;" | 160
| style="width:130px;" | 80
| style="width:130px;" | 40
| style="width:130px;" | 20
| style="width:130px;" | 15
| style="width:130px;" | 10
|-
| Cabrillo
| style="width:130px;" | N/A
| style="white-space: nowrap;" | CATEGORY-BAND
|colspan="7" | Value is determined automatically for single operator entries. For multi-operator entries it is always ALL.
|}

=== De-facto standard Cabrillo QSO line ===

[[image:cabrilloqsocolumns.png]]

{|class="wikitable"
|+style="text-align:Left;"| De-facto standard Cabrillo mode codes
| '''Cabrillo'''
| '''Mode'''
|-
| AM
| AMTOR
|-
| AX
| Packet AX.25
|-
| CO
| Contestia
|-
| CW
| CW
|-
| DO
| Domino
|-
| FM
| FM
|-
| HE
| Hellschreiber
|-
| MF
| MFSK16
|-
| OL
| Olivia
|-
| PH
| SSB, AM
|-
| PM
| PSK63
|-
| PO
| PSK125
|-
| PS
| PSK31
|-
| PT
| PACTOR
|-
| RM
| RTTYM
|-
| RY
| RTTY
|-
| TH
| THROB
|-
| TV
| SSTV
|-
|}

==Band and mode keys==

{|class="wikitable"
|+style="text-align:Left;"|
| '''BANDS'''
| A semicolon-separated list of allowed bands for the contest. Valid band names are: 2190, 630, 560, 160, 80, 60, 40, 30, 20, 17, 15, 12, 10, 50, 70, 144, 222, 432, 902, 1296, 2300, 3400, 5650, 10G, and 24G.
| Default value: 160;80;40;20;15;10
|-
| '''MODES'''
| A semicolon-separated list of modes allowed in the contest. Not to be confused with CATEGORY_MODES.
| Default value: CW;SSB
|-
| '''EDI_BANDS'''
| A semicolon-separated list of EDI values for bands specified in BANDS key. Must contain same number of entries as BANDS key. Used for generating EDI log files for VHF/UHF/SHF contests in IARU Region I. Valid values are: 28 MHz, 50 MHz, 70 MHz, 144 MHz, 432 MHz, 1,3 GHz, 2,3 GHz, 3,4 GHz, 5,7 GHz, 10 GHz, 24 GHz, 47 GHz, 76 GHz, 120 GHz, 144 GHz, and 248 GHz. Note the space between the number and the frequency multiplier and that commma is used as decimal separator. '''Very important: To support EDI export the <tt>SCORE</tt> key must contain BAND.'''
| No default value and if not set, EDI export is disabled.
|-
| '''DISPLAY_MODE_GROUPING'''
| Formatting of display of modes in check multiplier window. Should always be used if <tt>DOUBLE_QSO_MODE_CHECK=PER_MODE_GROUP</tt> is used. Syntax: <tt>DISPLAY_MODE_GROUPING=modename1:mode1+mode2;modename2:mode3+mode4</tt> Tip: An emtpy mode name can be used to avoid showing modes with per band multipliers.
| No default value
|}

==QSO entry field definition keys==

{|class="wikitable"
|+style="text-align:Left;"|These keys are used to control the layout and behavior of QSO entry fields. The keys set the visibility, length, labels, checking procedures etc. for each of the fields which the user can enter data or display for any QSO.
| '''FIELD_AZ_VISIBLE'''
| Controls the visibility of the Azimuth field. Mostly used on VHF/UHF/SHF to get the azimuth angle from a gridsquare. Valid values are YES and NO.
| Default value: NO
|-
| '''FIELD_CALLSIGN_GRID_CHECK'''
| If YES, an entry in the log callsign field be checked for a gridsquare entry. If a gridsquare closer than 4000km away is found, the callsign field value be copied to the gridsquare entry field and the azimuth angle be calculated and shown. Recommended for VHF/UHF contests where you turn your antenna a lot. Valid values are YES and NO.
| Default value: NO
|-
| '''FIELD_DISPLAYED_EXCHANGE'''
| Controls which of several exchange elements is displayed in the bandmap. With -1, the first static exchange element is displayed. With 0, 1, 2, or 3, Rcvd, Recinfo, Recinfo2, or Recinfo3 is displayed, respectively. Valid values are -1, 0, 1, 2, or 3.
| Default value: -1
|-
| '''FIELD_MODE_VISIBLE'''
| If YES, or MIXED and contest mode category name contains "mixed" or "digi", overrides menu option <code><nowiki>Options|Log|Always show mode in QSO lines</nowiki></code> and makes the mode column always visible in the log. If NO, has no effect. Valid values are YES, NO, and MIXED.
| Default value: NO
|-
| '''FIELD_MODE_NAME'''
| Heading for mode column.
| Default value: "Mode"
|-
| '''FIELD_MULT_NAME'''
| Heading for multiplier column.
| Default value: "Mult"
|-
| '''FIELD_MULT_VISIBLE'''
| If MULT field is visible on the screen. Valid values are YES and NO.
| Default value: YES
|-
| '''FIELD_MULT_MAX_LENGTH'''
| Width of MULT column.
| Default value: 5
|-
| '''FIELD_NR_VISIBLE'''
| If sent QSO SERIAL NUMBER is visible on the QSO entry line. Valid values are YES and NO.
| Default value: NO
|-
| '''FIELD_NR_HIDDEN_DXCC'''
| Semicolon separated list of DXCC. If our own DXCC is on this list, sent serial number field be hidden. Useful for contests where some stations are sending a serial number exchange and other stations are sending other data (for example a local province).
| Default is to hide none
|-
| '''FIELD_NR_HIDDEN_RGX'''
| Semicolon separated list of regular expressions. If one of the expressions are valid, sent serial number field be hidden. Useful for contests where some stations are sending a serial number exchange and other stations are sending other data (for example a local province).
| No default value
|-
| '''FIELD_PERIOD_VISIBLE'''
| If PERIOD number column is visible. Valid values: YES and NO.
| Default value: NO
|-
| '''FIELD_PERIOD_NAME'''
| Heading for PERIOD number column.
| Default value: "P"
|-
| '''FIELD_PTS_VISIBLE'''
| If POINTS column is visible. Valid values: YES and NO.
| Default value: YES
|-
| '''FIELD_PTS_NAME'''
| Heading for POINTS column. Width of column scales with string.
| Default value: "Pts"
|-
| '''FIELD_RCVD_CHECK_FORMAT_FX'''
| C# expression to reformat entered value in the field before further validity checking. The value in the field is represented as $FIELDVALUE. Example: <tt>FIELD_RCVD_CHECK_FORMAT_FX=$FIELDVALUE.Substring(0,2)+$FIELDVALUE.Substring(2).TrimStart('0')</tt> reshape RCVD by taking the first two characters and then remove any leading zeroes in the remainder before further validity or multiplier checking.
| Default value: $FIELDVALUE
|-
| '''FIELD_RECINFO_CHECK_FORMAT_FX''' '''FIELD_RECINFO2_CHECK_FORMAT_FX''' '''FIELD_RECINFO3_CHECK_FORMAT_FX'''
| One or several, semicolon separated, regular expressions to conditionally reformat the entered value in the field before further validity checking. The regular expression and the formatting expression are separated by ">>" as in CABRILLO_LINE. The entered value is represented as $FIELDVALUE. Example: <tt><nowiki>FIELD_RECINFO_CHECK_FORMAT_FX=!DEST->DXCC:^YO$>>'.'+$FIELDVALUE</nowiki></tt> add a period before the second part of the exchange for all stations that are not from Romania. <tt><nowiki>FIELD_RECINFO_CHECK_FORMAT_FX=!DEST->DXCC:^K$|^KL$|^KH6$|^VE$>>""</nowiki></tt> ignore any value in the second exchange field for all stations not from US, Hawaii, Alaska, or Canada.
| Default value: ALL>>$FIELDVALUE
|-
| '''FIELD_RCVD_COPY''' '''FIELD_RECINFO_COPY''' '''FIELD_RECINFO2_COPY''' '''FIELD_RECINFO3_COPY'''
| If the field's value is automatically copied from previous QSO with same station. Also controls if the exchange is shown with callsign in bandmap when <code><nowiki>Display options|Exchange</nowiki></code> is selected. Valid values: YES and NO.
| Default value: NO
|-
| '''FIELD_RCVD_COPY_EXC_DXCC''' '''FIELD_RECINFO_COPY_EXC_DXCC'''
| Semicolon separated list DXCC entities for which RCVD/RECINFO is copied from earlier QSO in spite of FIELD_RCVD_COPY/FIELD_RECINFO_COPY=NO. Useful in case only some DXCC have a fixed exchange in the contest.
| Default value: NONE
|-
| '''FIELD_RCVD_COPY_EXC_RGX''' '''FIELD_RECINFO_COPY_EXC_RGX'''
| Semicolon separated list of regular expressions. For QSO where any of the conditions are true, the content of the field be copied from earlier QSO in spite of FIELD_RCVD_COPY/FIELD_RECINFO_COPY=NO. Useful if only certain types of exchanges are fixed for stations in contest.
| No default value
|-
| '''FIELD_RCVD_COPY_FX'''
| C# expression used to determine value to be copied from earlier QSO. The value of the field is $FIELDVALUE. For example: <tt>FIELD_RCVD_COPY_FX=$FIELDVALUE.Substring(0,6)</tt> copy the first six characters from the RCVD field from the previous QSO with the same station.
| Default value: $FIELDVALUE
|-
| '''FIELD_RCVD_DEFAULT_VALUE'''
| Value to be used in as prefill if RCVD field is empty. Valid values are: CQZONE, ITUZONE, CONT, or any string, which be used verbatim.
| No default value
|-
| '''FIELD_RCVD_EXC_CHECK_DXCC'''
| List of destination DXCC countries separated by ":" (or keyword ALL for all) for which multiplier list validity checking is enforced. E.g. <tt>FIELD_RCVD_EXC_CHECK_DXCC=K:KL:KH6:VE:XE;CUSTOM_MULT_LIST</tt> Note that this key only applies to <tt>FIELD_RCVD_TYPE=MULT</tt>. Also note that this key does not override <tt>FIELD_RCVD_RGX_CHECK</tt>, so if used, this key needs to accept all possible values of RCVD. E.g. <tt><nowiki>FIELD_RCVD_RGX_CHECK=DEST->RCVD:^[0-8][0-9]?$|^90$;DEST->RCVD:CUSTOM_MULT_LIST</nowiki></tt> '''Important:''' There is no such key for <tt>RECINFO</tt> etc. since validity checking is automatic for those of MULT type.
| No default value
|-
| '''FIELD_RCVD_FORMAT_FX''' '''FIELD_RECINFO_FORMAT_FX''' '''FIELD_RECINFO2_FORMAT_FX''' '''FIELD_RECINFO3_FORMAT_FX'''
| C# expression used to format entered value before saving.
| No default value
|-
| '''FIELD_RCVD_FX_CHECK''' '''FIELD_RECINFO_FX_CHECK''' '''FIELD_RECINFO2_FX_CHECK''' '''FIELD_RECINFO3_FX_CHECK'''
| Boolean C# expression used to check if value entered in the field is valid. For example: <tt>FIELD_RCVD_FX_CHECK=Helpers.Between($FIELDVALUE,1,40)</tt> checks if RCVD is between 1 and 40.
| No default value
|-
| '''FIELD_RCVD_MANDATORY''' '''FIELD_RECINFO_MANDATORY''' '''FIELD_RECINFO2_MANDATORY''' '''FIELD_RECINFO3_MANDATORY'''
| If RCVD field entry is mandatory. Valid values are YES and NO.
| Default value: NO
|-
| '''FIELD_RCVD_MANDATORY_RGX_EXC''' '''FIELD_RECINFO_MANDATORY_RGX_EXC''' '''FIELD_RECINFO2_MANDATORY_RGX_EXC''' '''FIELD_RECINFO3_MANDATORY_RGX_EXC'''
| Defines exceptions from mandating rule via a regular expression. For example: <tt><nowiki>FIELD_RCVD_MANDATORY_RGX_EXC=!DEST->DXCC:^(G|GD|GI|GJ|GM|GU|GW)$</nowiki></tt> means RCVD is not mandatory for non-UK stations. You can only have one exception per entry field.
| No default value
|-
| '''FIELD_RCVD_MAX_LENGTH'''
| Maximum number of characters accepted in the field.
| Default value: 10
|-
| '''FIELD_RECINFO_MAX_LENGTH''' '''FIELD_RECINFO2_MAX_LENGTH''' '''FIELD_RECINFO3_MAX_LENGTH'''
| Maximum number of characters accepted in the field.
| Default value: 6
|-
| '''FIELD_RCVD_MIN_LENGTH''' '''FIELD_RECINFO_MIN_LENGTH''' '''FIELD_RECINFO2_MIN_LENGTH''' '''FIELD_RECINFO3_MIN_LENGTH'''
| Minimum number of characters accepted in the field.
| Default value: 0
|-
| '''FIELD_RCVD_NUMERIC''' '''FIELD_RECINFO_NUMERIC''' '''FIELD_RECINFO2_NUMERIC''' '''FIELD_RECINFO3_NUMERIC'''
| Controls if the field accepts only numeric characters. Valid values are YES and NO.
| Default value: NO
|-
| '''FIELD_RCVD_NAME'''
| Column heading for RCVD field.
| Default value: Rcvd
|-
| '''FIELD_RCVD_SLASH_ALLOWED''' '''FIELD_RECINFO_SLASH_ALLOWED''' '''FIELD_RECINFO2_SLASH_ALLOWED''' '''FIELD_RECINFO3_SLASH_ALLOWED'''
| Controls if the field accepts a slash "/" character. Valid values are YES and NO.
| Default value: NO
|-
| '''FIELD_RCVD_RGX_CHECK'''
| Semicolon separated list of logical expressions for entry validity checking. For contests with more than one type of exchange (e.g. grid and serial number or oblast and grid), more than one rule can be listed, separated by semicolon. The check is then done against the rules combined with logical OR, i.e. if any of the rules checks OK, the entry is approved.
| No default value
|-
| '''FIELD_RECINFO_RGX_CHECK''' '''FIELD_RECINFO2_RGX_CHECK''' '''FIELD_RECINFO3_RGX_CHECK'''
| A single regular expression for entry validity checking.
| No default value
|-
| '''FIELD_RCVD_TYPE'''
| Defines data type of the field. Valid values are: GRID, GRID4, GRID6, CONT, NR, CUSTOM (any text), MULT (a listed keyword, associated with <tt>MULT#_TYPE=CUSTOM</tt>), CQZONE, ITUZONE, and NAME. Note that there is no automatic validity checking for CUSTOM, CQZONE, NAME, and ITUZONE. Validity checking of MULT is enabled using the key <tt>FIELD_RCVD_EXC_CHECK_DXCC</tt>. This means a <tt>FIELD_RCVD_RGX_CHECK</tt> or key may be required. The type can also be per-DXCC using the syntax <tt>DXCC:regex=type1;!DXCC:regex=type2</tt> where regex is matched against the station's main DXCC prefix and can be e.g. <tt><nowiki>^(JA|JD/o|JD/m)$</nowiki></tt> '''Important:''' Since the types are used to determine e.g. ADIF export, only use NAME for a real name and only use NR for the exchange serial number.
| Default value: Empty
|-
| '''FIELD_RECINFO_TYPE''' '''FIELD_RECINFO2_TYPE''' '''FIELD_RECINFO3_TYPE'''
| Defines data type of the field. Valid values are: GRID, GRID4, GRID6, NR, CONT, CUSTOM, MULT, CQZONE, ITUZONE, and NAME. There is an automatic validity check on all types except CUSTOM and NAME. '''Important:''' Since the types are used to determine e.g. ADIF export, only use NAME for a real name and only use NR for the exchange serial number.
| Default value: Empty
|-
| '''FIELD_RCVD_GRID_CHECK'''
| If YES, entry in RCVD field be checked if it can be possible gridsquare entry. It it is gridsquare, then RCVD field value be moved to the RECINFO entry field and Azimuth be calculated and shown. Valid values are YES and NO.
| Default value: NO
|-
| '''FIELD_RECINFO_NAME''' '''FIELD_RECINFO2_NAME''' '''FIELD_RECINFO3_NAME'''
| Heading for field's column.
| Default value: Empty
|-
| '''FIELD_RECINFO_RGX_SEL_POS''' '''FIELD_RECINFO2_RGX_SEL_POS''' '''FIELD_RECINFO3_RGX_SEL_POS'''
| Filtering function for composite multipliers. Exact function is unclear.
| No default value
|-
| '''FIELD_RECINFO_VISIBLE''' '''FIELD_RECINFO2_VISIBLE''' '''FIELD_RECINFO3_VISIBLE'''
| Controls if the the field is visible. Valid values: YES, NO, HIDDEN, and READONLY.
| Default value: NO
|-
| '''FIELD_RST_3RD_LETTER'''
| Semicolon-separated list of allowed third characters apart from numbers. For example: <tt>FIELD_RST_3RD_LETTER=A;S</tt> allows 59A and 59S as reports.
| Default value: None
|-
| '''FIELD_RST_VISIBLE'''
| Controls visibility of RST field. Valid values are: YES and NO.
| Default value: YES
|-
| '''FIELD_SENT_VISIBLE'''
| Controls visibility of Sent field in log. Valid values are: YES and NO.
| Default value: YES
|-
|}

==Default message keys==

{|class="wikitable"
|+style="text-align:Left;"|Default messages for F-keys, Plus and Ins.
| '''Message'''
| '''Usage'''
| '''Default value'''
|-
| '''CW_MESSAGE_1'''
| Default F1 message for Run
| <nowiki>"CQ $MYCALL $MYCALL TEST"</nowiki>
|-
| '''CW_MESSAGE_2'''
| Default F2 message for Run
| "$RST $EXCHANGE"
|-
| '''CW_MESSAGE_3'''
| Default F3 message for Run
| "$EXCHANGE"
|-
| '''CW_MESSAGE_4'''
| Default F4 message for Run
| "$MYCALL"
|-
| '''CW_MESSAGE_5'''
| Default F5 message for Run
| "$LOGGEDCALL"
|-
| '''CW_MESSAGE_6'''
| Default F6 message for Run
| "AGN?"
|-
| '''CW_MESSAGE_7'''
| Default F7 message for Run
| "?"
|-
| '''CW_MESSAGE_INS'''
| Default Insert message for Run
| "$F2"
|-
| '''CW_MESSAGE_PLUS'''
| Default Plus message for Run
| "$CORRECT TU $CR $MYCALL"
|-
| '''SP_CW_MESSAGE_1'''
| Default F1 message for S&P
| "$MYCALL"
|-
| '''SP_CW_MESSAGE_2'''
| Default F2 message for S&P
| "$RST $EXCHANGE"
|-
| '''SP_CW_MESSAGE_3'''
| Default F3 message for S&P
| "$EXCHANGE"
|-
| '''SP_CW_MESSAGE_4'''
| Default F4 message for S&P
| "$MYCALL"
|-
| '''SP_CW_MESSAGE_5'''
| Default F5 message for S&P
| "$LOGGEDCALL"
|-
| '''SP_CW_MESSAGE_6'''
| Default F6 message for S&P
| "AGN?"
|-
| '''SP_CW_MESSAGE_7'''
| Default F7 message for S&P
| "?"
|-
| '''SP_CW_MESSAGE_INS'''
| Default Insert message for S&P
| "$F2$CR"
|-
| '''SP_CW_MESSAGE_PLUS'''
| Default Plus message for S&P
| "TU$CR"
|-
| '''CW_MESSAGE_EXCHANGE_FILTER'''
| Controls selection of alternative standard messages
|
|-
|}

Message definitions following the <tt>CW_MESSAGE_EXCHANGE_FILTER</tt> key will only be effective if regular expression after equal sign evaluates true for content in exchange entry box. Example: <tt>CW_MESSAGE_EXCHANGE_FILTER=^DX$</tt> means that messages below this line will be used for stations entering DX in the exchange entry box. '''Important:''' Only has effect for the first log created or when the Defaults button is clicked in the Standard messages panel. All subsequent logs for the same contest will inherit the messages from the previous log.

==Additional configuration keys==

=== DXCC related keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''DXCC_DB_TYPE'''
| This entry allows the use of a custom country file (for example, R150S.dat). If a custom country file is defined, the selection in <tt><nowiki>Option|Data files|Country files</nowiki></tt> will be ignored and the country file defined in the contest config file will be used. Valid values are: <tt>CUSTOM_CTY</tt> and <tt>CTY</tt>
|Default value is CTY which will use the data base set in the <tt><nowiki>Options|Data files|Country files</nowiki></tt> panel.
|-
| '''DXCC_DB_FILENAME'''
| Used to enable the use of an alternative country data base. Used in conjunction with the <tt>DXCC_DB_TYPE</tt> key to define the data file name. The file format is the same as the normal <tt>CTY.DAT</tt> file.
| Default value: <tt>CTY.DAT</tt>
|-
| '''DXCC_DB_USE_ARRL_LIST'''
| Controls the use of the ARRL country list instead of CQ/WAE country list. Valid values: YES and NO.
| Default value: NO
|}

=== Contest timing and period keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''MIN_OFF_TIME'''
| Minimum time in minutes without QSO to count as off time. C.f. OFF_TIME_ROUND_UP.
| style="white-space: nowrap;" | Default value: 30
|-
| '''OFF_TIME_ROUND_UP'''
| Off time is calculated based on time difference between QSO instead of minutes without QSO. YES means that QSO at e.g. 4:12 and 5:12 represents 60 minutes of off time. NO means that QSO at e.g. 4:12 and 5:13 represents 60 minutes of off time. Valid values: YES and NO.
| Default value: NO
|-
| '''CONTEST_LENGTH'''
| Duration of contest in minutes. Ignored for contests without periods.
| No default value
|-
| '''CONTEST_FIRST_HOUR'''
| Time of day for start of contest in UTC. Ignored for contests without periods. If the value is negative, DXLog will assume the contests starts a the beginning of the current hour. Valid formats: -1, H, HH, HMM, and HHMM.
| No default value
|-
| '''PERIOD'''
| Whether the contest has periods. Valid values: ON and OFF.
| style="white-space: nowrap;" | Default value: OFF
|-
| '''PERIOD_LENGTH'''
| The length of each contest period in minutes. Valid values: Any integer.
| Default value: 0
|-
| '''PERIOD_AUTOSWITCH'''
| If the next period should start automatically. '''Important: Does not work if contests stretches past midnight UTC.''' Valid values: YES and NO.
| Default value: NO
|-
| '''PERIOD_NUMBER'''
| Number of periods in contest. CALC_FROM_TIME means duration divided by period length. Valid values: CALC_FROM_TIME or any integer. '''Important:''' When CALC_FROM_TIME is used, it must be preceded by CONTEST_LENGTH and PERIOD_LENGTH.
| Default value: 0
|-
| '''PERIOD_MODES'''
| Optional, semicolon-separated list of modes for each period in the contest. Must have the same number of items as number of periods. Valid values: Mode acronyms supported by DXLog.
| No default value
|-
|}

=== Database, prefill, and check keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''DB_FILE''' or '''DB_FILE1''' '''DB_FILE2''' '''DB_FILE3''' '''DB_FILE4''' '''DB_FILE5'''
| File name of prefill data base. '''Important: File name casing must be correct for online update to work.''' For file format etc., see the [[Menu_Options#Prefill_database_settings|Prefill database settings]] section.
|
|-
| '''DB_FILE_TYPE''' or '''DB_FILE1_TYPE''' '''DB_FILE2_TYPE''' '''DB_FILE3_TYPE''' '''DB_FILE4_TYPE''' '''DB_FILE5_TYPE'''
| Extension of data base file.
| style="white-space: nowrap;" | Default value: TXT
|-
| '''DB_FILE_COL_RCVD''' or '''DB_FILE1_COL_RCVD''' '''DB_FILE2_COL_RCVD''' '''DB_FILE3_COL_RCVD''' '''DB_FILE4_COL_RCVD''' '''DB_FILE5_COL_RCVD'''
| Column number of RCVD field in data base file. '''Important: At least one DB_FILE_COL* statement must be included for each data base file.''' '''Important: Since look-up for RCVD is enabled by default, it needs to be actively disabled if not wanted. Set it to -1 to disable undesired look-up. '''
|
|-
| '''DB_FILE_COL_RECINFO''' or '''DB_FILE1_COL_RECINFO''' '''DB_FILE2_COL_RECINFO''' '''DB_FILE3_COL_RECINFO''' '''DB_FILE4_COL_RECINFO''' '''DB_FILE5_COL_RECINFO'''
| Column number of RECINFO field in data base file.
|
|-
| '''DB_FILE_COL_RECINFO2''' or '''DB_FILE1_COL_RECINFO2''' '''DB_FILE2_COL_RECINFO2''' '''DB_FILE3_COL_RECINFO2''' '''DB_FILE4_COL_RECINFO2''' '''DB_FILE5_COL_RECINFO2'''
| Column number of RECINFO2 field in data base file.
|
|-
| '''DB_FILE_COL_RECINFO3''' or '''DB_FILE1_COL_RECINFO3''' '''DB_FILE2_COL_RECINFO3''' '''DB_FILE3_COL_RECINFO3''' '''DB_FILE4_COL_RECINFO3''' '''DB_FILE5_COL_RECINFO3'''
| Column number of RECINFO3 field in data base file.
|
|-
| '''DB_FILE_FILL_FORMAT''' or '''DB_FILE1_FILL_FORMAT''' '''DB_FILE2_FILL_FORMAT''' '''DB_FILE3_FILL_FORMAT''' '''DB_FILE4_FILL_FORMAT''' '''DB_FILE5_FILL_FORMAT'''
| C# <code>string.Format</code> expression defining how prefill from data base file will be used. Example: <tt>/{0}</tt> will precede prefill with a slash. This function is often combined with the menu option to use INSERT mode in the RCVD field.
|
|-
| '''RGX_GUESS_DB'''
| Regular expression "rule base" for guessing exchange of unworked stations. Syntax is <tt>RGX_GUESS_DB=Field;DXCC Regex;Callsign Regex2;Filename[;Result regex]</tt>. A look-up is done for stations fulfilling at least one of the regular expressions. An empty regular expression or "ALL" matches everything and "NONE" never matches. If the Result regex is used, the look-up only returns values that matches it. The syntax of the file is callsign regex=prefill, DXCC:regex=prefill, !DXCC:regex=prefill, CONT:regex=prefill, or !CONT:regex=prefill where "prefill" is either a literal string or <tt>$DXCC</tt>, <tt>$CONT</tt>, <tt>$ITUZONE</tt>, or <tt>$CQZONE</tt>. The file is parsed from top to bottom and the first match is used.
|
|-
| '''DXC_COMMENT_EXTRACT'''
| This entry is used to extract exchange or multiplier information from DX cluster comments. For example, the line: <tt><nowiki>DXC_COMMENT_EXTRACT=RECINFO;(AF|AN|AS|EU|NA|OC|SA)[ /\-\.]?\d{1,3};[ /\-\.]</nowiki></tt> will extract a typical IOTA designation such as AF-025 and insert it into the <tt>RECINFO</tt> prefill field for the spot. The first part of the configuration (before the ;) defines into which entry field the data should be placed. The second part of the configuration is a regular expression that defines the data that is to be matched. The third part defines which characters should be removed from the matched result. It is mandatory but can be empty. A fourth part is optional. It is a regular expression and all comments matching it are ignored. This can, for instance, be used to ignore skimmer spots. '''Important''': All comments are converted to upper case before comparison.
|
|-
| '''CALLSIGN_EXTRACT'''
| This entry is used to extract exchange information from an entered or spotted callsign. For example, the line: <tt><nowiki>CALLSIGN_EXTRACT=RCVD;/(ABC|DEF|KIJ)$;[/]</nowiki></tt> will extract the string after the slash into the RCVD field into the entry line or in the spot. The first part of the configuration (before the ;) defines into which entry field the data should be placed. The second part of the configuration is a regular expression that defines the data that is to be matched. The third part defines which characters should be removed from the matched result. It is mandatory but can be empty.
|
|-
| '''SCP_DATABASE_DISABLE'''
| Disable file-based prefill and check partials database. (for e.g., WRTC). Valid values are: YES and NO or a semicolon separated list of YES or NO with the same number of elements as defined contest categories.
| Default value: NO
|-
| '''DB_SCP_FROM_EXCHANGE'''
| Enables reverse look-up. Searches for all instances of either RCVD or RECINFO in first and second column of all data base files. Search is triggered when pressing space and all entry fields are empty except either RCVD or RECINFO. Search hits are displayed in Check Partials window.
| Default value: NO
|-
|}

=== QSO exchange and numbering keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''INITIAL_SERIAL_NUMBER'''
| Starting value of sent serial number.
| Default value: 1
|-
| '''QSO_NUMBER'''
| QSO numbering principle. Valid values: ALL, PER_MODE, PER_BAND, PER_PERIOD, PER_BAND_MODE, PER_PERIOD_MODE. ALL means chronological numbering.
| Default value: ALL
|-
| '''QSO_NUMBER_CATEGORY'''
| Semicolon-separated list of numbering principles for each contest category. Must contain the same number of elements as contest categories. Valid values: ALL, PER_MODE, PER_BAND, PER_PERIOD, PER_BAND_MODE, PER_PERIOD_MODE.
| If absent, the value of QSO_NUMBER is used.
|-
| '''FIRST_PREV_RCVD'''
| Initial return value of macro $PREV_RCVD. Any string is allowed but also the keyword <tt>EXCHANGE</tt>
| style="white-space: nowrap;" | Default value: "000"
|-
| '''FIRST_PREV_RECINFO'''
| Initial return value of macro $PREV_RECINFO. Any string is allowed but also the keyword <tt>EXCHANGE</tt>
| Default value: "000"
|-
| '''FIRST_PREV_RECINFO2'''
| Initial return value of macro $PREV_RECINFO2. Any string is allowed but also the keyword <tt>EXCHANGE</tt>
| Default value: "000"
|-
| '''FIRST_PREV_RECINFO3'''
| Initial return value of macro $PREV_RECINFO3. Any string is allowed but also the keyword <tt>EXCHANGE</tt>
| Default value: "000"
|-
| '''SLASH_MULTIPLE_QSOS'''
| Controls whether slashed ("/") multipliers in sent and received exchanges are scored as separate QSO.
| Default value: NO
|-
|}

=== Duplicate QSO keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''DOUBLE_QSO'''
| The definition of a dupe. Valid values: PER_PERIOD, PER_BAND, PER_MODE, PER_PERIOD_BAND, PER_PERIOD_MODE, PER_BAND_MODE, PER_BAND_MODE_RECINFO, PER_BAND_MODE_RCVD, PER_BAND_MODE_RCVD_DAY, PER_PERIOD_BAND_MODE, PER_MINUTE_DIFFERENCE, PER_BAND_DAY '''Important: ALL is not a valid value.'''
| PER_BAND
|-
| '''DOUBLE_QSO_MINUTE_DIFFERENCE'''
| Minimum time difference in QSO time to not be counted as a dupe. Used in conjunction with DOUBLE_QSO=PER_MINUTE_DIFFERENCE.
| Default value: 0
|-
| '''DOUBLE_QSO_MODE_CHECK'''
| Definition of dupe principle when it comes to mode. Valid values: PER_MODE, PER_CABRILLO_MODE, and PER_MODE_GROUP. '''Important''': When not using PER_MODE, only use CW, Phone, Digital, and Mixed for CATEGORY_MODES values.
| style="white-space: nowrap;" | Default value: PER_MODE
|-
| '''DOUBLE_QSO_RULE_DURATION'''
| Expiration time of dupe QSO rule. Cannot be used together with DOUBLE_QSO=PER_MINUTE_DIFFERENCE or MIN_VALID_QSO_DIFFERENCE.
| Default value: 0
|-
| '''MIN_VALID_QSO_DIFFERENCE'''
| Minimum allowed time between QSO with the same station (on e.g., another mode). Once this time has passed, the regular dupe rules apply. Cannot be used together with DOUBLE_QSO=PER_MINUTE_DIFFERENCE or DOUBLE_QSO_RULE_DURATION.
| Default value: 0
|-
| '''MODE_GROUP'''
| Semicolon-separated list of mode group names. Used as an alternative to CABRILLO_MODES to group modes together for special dupe rules. One list entry per MODES mode entry. Valid group names are CW, SSB, FM, PH, and DG.
| No default value
|-
|}

=== Multiplier keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''MULT_SUM'''
| Summing method for multipliers. Valid values: NO, ALL, PER_BAND, and PER_PERIOD.
| Default value: ALL
|-
| '''OWN_MULT_VALID'''
| Controls if own multiplier is valid. '''Important:''' Controls the validity of ALL own multipliers but does not consider calculated or derived multipliers, e.g. DXCC or WPX. This means that for the NO option to work, the own multiplier must be specified in the Exchange field in the contest configuration window and only this multiplier will not count.
| Default value: NO
|-
| '''CUSTOM_MULT_LENGTH'''
| Length of an enumerated numeric multiplier. If number is shorter, it is left padded with zeroes. Used with enumerated multipliers, e.g. "=1-1999".
| Default value: 0
|-
| '''CONTINENT_LIST'''
| Custom, semicolon-separated continent list. Syntax is: <tt>CONTINENT_LIST=</tt>''continent1;continent2;continent3''
| Default value: EU;NA;SA;AS;AF;OC
|-
| '''MULT1_CONT_LIST''' '''MULT2_CONT_LIST''' '''MULT3_CONT_LIST'''
| Custom, semicolon-separated continent list. Syntax is: <tt>MULT1_CONT_LIST=</tt>''continent1;continent2;continent3''
| Default value: EU;NA;SA;AS;AF;OC
|-
| '''MULT1_TYPE''' '''MULT2_TYPE''' '''MULT3_TYPE'''
| Multiplier type. Can be <tt>CALLSIGN, DXCC, CQZONE, WPX, CUSTOM, HQ, NUM, FIELD, LASTLETTER, LETTER1</tt>, or <tt>FX</tt>. <tt>FX</tt> is a calculated multiplier and requires an <tt>MULT#_FX</tt> key. <tt>CUSTOM</tt> requires an explicit multiplier list. For contests with more than one multiplier, the use of LIVESCORE_MULT may be necessary for correct reporting. Check [https://contestonlinescore.com/settings/ here] for valid live score multiplier attributes and below for more details about how to use the types.
| Default value: None
|-
| '''MULT1_FX''' '''MULT2_FX''' '''MULT3_FX'''
| A C# expression used to create the effective value of an <tt>FX</tt> type multiplier. The entered string is available in the object <tt>$FIELDVALUE</tt>. For example <tt>MULT1_FX=$FIELDVALUE.Substring(0,$FIELDVALUE.IndexOf('/'))</tt> will make the characters before the slash the actual multiplier.
|
|-
| '''MULT1_COUNT''' '''MULT2_COUNT''' '''MULT3_COUNT'''
| Counting method for <tt>MULT1, MULT2</tt>, and <tt>MULT3</tt>. Can be <tt>PER_BAND, PER_PERIOD, PER_MODE, PER_BAND_MODE, PER_PERIOD_MODE, PER_PERIOD_BAND, PER_PERIOD_BAND_MODE,</tt> or <tt>ALL</tt>. '''Important:''' Do not use e.g. <tt>PER_BAND</tt> for a single band contest or <tt>PER_MODE</tt> for a single mode contest.
| Default value: None
|-
| '''MULT1_ADD_DXCC''' '''MULT2_ADD_DXCC''' '''MULT3_ADD_DXCC'''
| Only used with multiplier type <tt>HQ</tt>. Adds an asterisk and the DXCC entities main prefix to the entered string. Can be reversed using the multiplier exception <tt>REMOVE_DXCC</tt>. Example: <tt>MULT2_EXCEPTION=DEST->RCVD:^R[1-3]$;REMOVE_DXCC</tt> means that HQ stations sending R1, R2, or R3 as exchange will not count for DXCC multipliers. Valid values: YES and NO.
| Default value: NO
|-
| '''MULT1_FIELD''' '''MULT2_FIELD''' '''MULT3_FIELD'''
| Source of the multiplier string. Valid values: <tt>RCVD, CALLSIGN, FROM_DXCC, FROM_WPX, RECINFO, RECINFO2, RECINFO3,<tt> and <tt>NONE</tt>.
| Default value: None
|-
| '''MULT1_DISPLAY''' '''MULT2_DISPLAY''' '''MULT3_DISPLAY'''
| Text to show in MULT column. Syntax: MULT1_DISPLAY=''regex;string''. The ''regex'' can be omitted. Example: <tt><nowiki>MULT1_DISPLAY=DEST->DXCC:^(K|KL|KH6)$;S</nowiki></tt> Example: <tt>MULT1_DISPLAY=FN</tt>
| Default value: None
|-
| '''MULT1_BAND_BONUS''' '''MULT2_BAND_BONUS''' '''MULT3_BAND_BONUS'''
| Per band multiplier scaling factor. Syntax <tt>MULT1_BAND_BONUS=<tt>''band;scaling''. Example: <tt>MULT1_BAND_BONUS=80;2.0</tt> doubles the multiplier count for the 80m band.
| Default value: 1
|-
| '''MULT1_BONUS''' '''MULT2_BONUS''' '''MULT3_BONUS'''
| Bonus score for a defined achievement in V/U/SHF contests with EDI log submission. Example: With country defined as a "multiplier" number one, <tt>MULT1_BONUS=100</tt> will add 100 points to the total score for each new country worked. Affects the EDI keys <tt>CWWLs</tt>, <tt>CExcs</tt>, and <tt>CDXCs</tt>. '''Has no effect on on-screen scoring or Cabrillo export.'''
| Default value: 0
|-
| '''MULT1_EXCEPTION''' '''MULT2_EXCEPTION''' '''MULT3_EXCEPTION'''
| Exception from the general rule for the multiplier. Syntax: <tt>MULT1_EXCEPTION=boolean;multiplier definition</tt>. The boolean function can either be a regular expression (c.f. above) or <tt>FX()</tt> expression. Example: <tt><nowiki>MULT1_EXCEPTION=DEST->DXCC:^K$|^VE$;CUSTOM_MULT_LIST</nowiki></tt> will use the custom list (normally last in the contest definition file) to determine multipliers for US and Canadian stations. Example: <tt><nowiki>MULT1_EXCEPTION=FX("CONFIG->CALLSIGN"<>"K1DG");NONE</nowiki></tt> will not count this multiplier for anyone except Doug K1DG. However, a less roundabout way to achieve the same is <tt><nowiki>MULT1_EXCEPTION=!CONFIG->CALLSIGN:^K1DG$;NONE</nowiki></tt> For valid values, see table below.
|
|-
| '''MULT1_MULTIPLIER''' '''MULT2_MULTIPLIER''' '''MULT3_MULTIPLIER'''
| Multiplication factor for a selected value. Syntax ''value;factor''. For instance <tt>MULT1_MULTIPLIER=AZ;4</tt> means all "AZ" are worth four multipliers. One <tt>MULT1_MULTIPLIER</tt> line is required for each value of <tt>MULT1</tt> which has a multiplier but ALL matches all values.
|
|-
| '''MULT1_REPEAT''' '''MULT2_REPEAT''' '''MULT3_REPEAT'''
| Specifies a list of values of the multiplier and the number of times they count as multipliers. For instance <tt>MULT1_REPEAT=VD[3];PA[2]</tt> means the first three "VD" and the first two "PA" count as multipliers. If only a multiplier without a bracketed number is listed, the number is one. '''Important: This function is not correctly implemented in DXLog's bandmap.'''
| By default multipliers only count once
|-
| '''MULT1_CONT_LIST''' '''MULT2_CONT_LIST''' '''MULT3_CONT_LIST'''
| List used when MULT is of type CONT. '''Important: Antarctica is not included by default.'''
| Default value: EU;NA;SA;AS;AF;OC
|-
| '''MULT1_NO_ALERT''' '''MULT2_NO_ALERT''' '''MULT3_NO_ALERT'''
| Hides the multiplier and QSY alert at the bottom of the screen for the multiplier. Valid values: YES and NO.
| Default value: NO
|-
|}

'''Multiplier field considerations'''

<tt>CALLSIGN</tt> 
Ignores multiplier type for processing but a MULT#_FX key is always honored. 
Multiplier type can still be used for creating a list of valid multiplier values so 
CUSTOM can be useful for a derived multiplier (such as the last letter of a callsign). 
A dummy multiplier type CALLSIGN can be used for clarity.

<tt>FROM_DXCC</tt> 
Valid multiplier types are DXCC and FX. With DXCC, worked multipliers are displayed in the 
Worked DXCC window. With FX, the list of workable multipliers need to be defined, e.g., 
using <code>WINDOWS_CML_LIST_FX=GetList_...</code>.

<tt>FROM_WPX</tt> 
The multiplier type is ignored but a dummy type WPX can be used for clarity. Worked multipliers are 
displayed in a growing window.

'''Multiplier type considerations'''

<tt>HQ</tt> 
Like FIELD but with the exception that the multiplier will only be valid if the QSO does not 
represent a multiplier with lower number. For instance, if MULT3 is HQ, it will only be valid 
if neither MULT1 nor MULT2 are valid. A DXCC entity qualifier can be added using the 
<tt>MULT#_ADD_DXCC</tt> key, making sure the same multiplier is valid once per country. 
For example if you receive ARRL from W1AW, the multiplier's value will be "ARRL*K". 
Worked multipliers are displayed in a growing window.

<tt>CQZONE</tt> and <tt>ITUZONE</tt> 
Can be used with the RCVD, RECINFO, RECINFO2, and RECINFO3 fields. 
The set of workable multipliers is created automatically.

<tt>FX</tt> 
Can be used with the CALLSIGN, RCVD, RECINFO, RECINFO2, and RECINFO3 fields. 
The set of workable multipliers need to be defined, e.g., using <tt>WINDOWS_CML_LIST_FX=GetList_...</tt>.

<tt>FIELD</tt> 
Can be used with the RCVD, RECINFO, RECINFO2, and RECINFO3 fields. 
This is typically used for multipliers with too many possible values 
that visual tracking is infeasible. But it is still possible, 
The set of valid multiplier values is undefined by default and 
typically created using <tt>WINDOWS_CML_LIST_FX=GetList_...</tt>.

<tt>CUSTOM</tt> 
Can be used with the RCVD, RECINFO, RECINFO2, RECINFO3, and CALLSIGN fields. 
The list of valid multiplier values is created by a values listed between 
<code>[MULTIPLIERS START]</code> and <code>[MULTIPLIERS END]</code>.

<tt>NUM</tt> 
Can be used with the CALLSIGN, RCVD, RECINFO, RECINFO2, and RECINFO3 fields. 
Like FIELD but strips leading zeroes.

<tt>LASTLETTER</tt> and <tt>LETTER1</tt> 
Can be used with the CALLSIGN, RCVD, RECINFO, RECINFO2, and RECINFO3 fields. 
The list of workable multipliers is automatically created.

'''Multiplier exception considerations'''

{|class="wikitable"
|+style="text-align:Left;"|
| '''Exception'''
| '''Value when triggered'''
|-
| <tt>PFX_AREA</tt>
| The prefix area of the QSO's callsign.
|-
| <tt>WPX</tt>
| The WPX prefix of the QSO's callsign.
|-
| <tt>NONE</tt>
| An empty string, i.e., no multiplier.
|-
| <tt>CUSTOM_MULT_LIST</tt>
| The value of the multiplier, if it matches an item in the list of valid multipliers.
|-
| <tt>REMOVE_DXCC</tt>
| The value of the multiplier with a "*BBB" suffix stripped. Only meaningful for HQ multiplier.
|-
| <tt>LETTER1</tt>
| The first letter of the multiplier.
|-
| <tt>LASTLETTER</tt>
| The last letter of the multiplier.
|-
| <tt>VALUE</tt>
| The value of the multiplier.
|-
| <tt>VALUE:ABC</tt>
| The string following the colon.
|-
|}

=== Rate window keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''STATS_TYPE'''
| Type of statistics in Rate window. Valid values: STANDARD and WRTC.
| Default value: STANDARD
|-
| '''DISPLAY_TIME_ON_PER_MODE'''
| Display time on per mode in Rate window.
| Default value: NO
|-
| '''DISPLAY_LAST_MODE_CHANGE'''
| Display time of last mode change in Rate window.
| Default value: NO
|-
|}

=== Band change rule keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''BAND_MIN_LIMITS'''
| Bandwise minimum and maximum times. Only used by Bande Basse local Italian contest. Syntax: <tt>BAND_MIN_LIMITS=band;maxminutes;minfromlastqsominutes.</tt>
|
|-
| '''MULTISINGLE_RULE10_ENABLED'''
| 10-minute rule for Multi-Single operation.
| Default value: YES
|-
| '''MULTISINGLE_RULE10_FOR_MULT'''
| 10-minute rule applies to multiplier station.
| Default value: YES
|-
| '''MULTISINGLE_RULE10_MINUTES'''
| Actual number of minutes for 10-minute rule.
| Default value: 10
|-
| '''MULTISINGLE_RULE10_CHECKMODE'''
| Checking principle for 10-minute rule. Valid values: PER_BAND or PER_BAND_MODE
| style="white-space: nowrap;" | Default value: PER_BAND
|-
| '''MULTITWO_RULE10_ENABLED'''
| 10-minute rule for Multi-Two operation.
| Default value: NO
|-
| '''MULTIOP_BANDCHANGECOUNTER_ENABLED'''
| Band change counter for multi operator operation enabled.
| Default value: YES
|-
| '''MULTIOP_BANDCHANGES_ALLOWED'''
| Semicolon-separated list with number of band changes allowed in one hour in multi operator operation. Must have same number of entries as MULTIOP_BANDCHANGES_CBR_TRANSMITTERS.
| Default value: 8
|-
| '''MULTIOP_BANDCHANGES_CHECKMODE'''
| Type of counting method for band changes in multi operator operation. Valid values: PER_BAND or PER_BAND_MODE
| Default value: PER_BAND
|-
| '''MULTIOP_BANDCHANGES_TYPE'''
| Semicolon-separated list with type of band changes counted for band change rule in multi operator operation. Valid values are R, RM, or ALL. R is for M/2 and keeps two separate counters. RM is for M/1 where you have a separate counter for the Run and Multiplier stations. ALL means a single, common counter for all station types. The list must have the same number of entries as MULTIOP_BANDCHANGES_CBR_TRANSMITTERS.
| Default value: R
|-
| '''MULTIOP_BANDCHANGES_CBR_CATEGORIES'''
| Semicolon-separated list of Cabrillo operator categories subject to band change rule.
| Default value: MULTI-OP
|-
| '''MULTIOP_BANDCHANGES_CBR_TRANSMITTERS'''
| Semicolon-separated list of Cabrillo transmitter categories subject to band change rule.
| Default value: TWO
|-
|}

=== Contest score keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''SCORE'''
| Scoring principle. Valid values: BY_BAND, BY_BAND_MODE, BY_PERIOD, BY_PERIOD_BAND, and BY_PERIOD_BAND_MODE. Additional values are BY_MODE_GROUP and BY_BAND_GROUP. Their function is unknown. '''Important: BY_MODE does not exist.'''
| Default value: BY_BAND
|-
| '''SCORE_DISPLAY'''
| Displayed columns in Summary window. Available elements in their standard order: PERIOD, BAND, MODE, QSO, DUP, MULT1, MULT2, MULT3, QTC, POINTS, AVG, AVG0, and AVG1. A string within parenthesis following the element name will set the column header. Per mode display can be achieved by including the relevant mode(s) within curly brackets. Multiple modes are separated by '+'. Example: <tt>SCORE_DISPLAY=BAND;QSO(SSB){SSB};QSO(CW){CW};QSO(DIGI){RTTY+PSK31+PSK63};DUP</tt> will group all RTTY, PSK31, and PSK63 QSO under the same heading. Elements can be conditional using the <tt>*+NN:MM:LL></tt> syntax or <tt>*RGX:</tt> followed by a regular expressions (see above). Example: <tt>*-K:VE></tt> will display the column if your station is not a K or VE station. Example: <tt>*+SM:OZ:LA:OH></tt> will display the column only if you are a SM, OZ, LA, or OH station.
| Default value: BAND;QSO;DUP;MULT1(MULT);POINTS
|-

| '''SCORE_TOTAL_FX'''
| Formula for calculating total score for a QSO. Uses FLEE syntax which includes e.g. If(). Example: <tt>SCORE_TOTAL_FX=$FIELDVALUE.Points*$FIELDVALUE.Mult1+$FIELDVALUE.Mult3</tt>
| Default value: SCORE_TOTAL_FX= $FIELDVALUE.Points*($FIELDVALUE.Mult1+ $FIELDVALUE.Mult2+$FIELDVALUE.Mult3)
|-

|}

=== QSO points keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''POINTS_TYPE'''
| Type of points. Valid values: CALC, QRB, QRB_EXCHANGE+CALCF, QRB+CALCF, QRB+GRIDP2, RAEM, and FROM_TABLE() CALC expects the presence of POINTS_FIELD_BAND_MODE keys. QRB means one point per kilometer. QRB_EXCHANGE+CALCF requires at least one POINTS_CALC_F key and uses a grid in the configuration panel's Exchange field for QRB calculation. QRB only works with 6-position grids. QRB+CALCF requires at least one POINTS_CALC_F key and uses the configuration panel's Grid field for QRB calculation. RAEM uses the special RAEM contest point system. QRB+GRIDP2 is the number of large grids in distance plus two. FROM_TABLE(''filename;keytype;sourcekey;destkey'') requires a database text file that maps an exchange value to points. ''keytype'' is always INT, ''sourcekey'' is always "EXCHANGE", ''destkey'' can be RCVD, RECINFO, RECINFO2, or RECINFO3. The format of each line in the file is ''sourcekey value;destkey value=points''.
| style="white-space: nowrap;" | Default value: CALC
|-
| '''POINTS_BAND_BONUS'''
| Per band scaling factor. Syntax POINTS_BAND_BONUS=band;scaling. Example: <tt>POINTS_BAND_BONUS=160;2</tt> doubles the points number on the 160m band.
| Default value: 1 on all bands.
|-
| '''POINTS_FIELD_BAND_MODE'''
| Conditional point calculation. Syntax: <tt>POINTS_FIELD_BAND_MODE=</tt>''regex1;regex2;bandregex;moderegex;points;optionalregex'' The points item can be either a numeric (1, 10, etc.) or an aritmetic expression involving RCVD, RECINFO, RECINFO2, or RECINFO3. '''Important: When designing points rules, keep in mind the first valid rule encountered, reading from the top, overrides all subsequent rules. This can simplify rule-writing greatly.'''
| No default value
|-
| '''POINTS_CALC_F'''
| Formula for points calculation with <tt>POINTS_TYPE</tt> <tt>QRB_EXCHANGE+CALCF</tt> and <tt>QRB+CALCF</tt>. Syntax: <tt>POINTS_CALC_F=</tt>''sourceregex;pointsformula;bandregex;calculationregex'' Example: <tt>POINTS_CALC_F=ALL;VALUE*5.0;^15$;QRB>=100&&QRB<=800</tt> multiplies points with 5 on 15m if QRB is between 100 and 800km. All mathematical functions in C# syntax, plus the points number (<tt>VALUE</tt>) are available for expressions. In the ''calculationregex'', the keyword <tt>QRB</tt> can also be used for e.g. comparisons. Additionally, three additional syntax elements are available: <tt>VALUE{QRB:''grid''}</tt> which has the value of the distance (in km) from you to ''grid'', <tt>VALUE{*QRB:''grid''}</tt> which has the value of distance from ''grid'' to the party station, and <tt>VALUE{QRB:IARU}</tt> which has the value of the distance according to the IARU R1 rules for 6 and 4m MGM contests which is the distance between the centers of the origin and destination large square (four first characters) rounded up and if same, 50 points.
| No default value
|-
|}

=== Progress tracking keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''WINDOWS_CML_ENABLED'''
| Enable custom multiplier window #1.
| style="white-space: nowrap;" | Default value: NO
|-
| '''WINDOWS_CML2_ENABLED'''
| Enable custom multiplier window #2.
| Default value: NO
|-
| '''WINDOWS_CML3_ENABLED'''
| Enable custom multiplier window #3.
| Default value: NO
|-
| '''WINDOWS_CML_NAME'''
| Name of custom multiplier #1.
| No default value
|-
| '''WINDOWS_CML2_NAME'''
| Name of custom multiplier #2.
| style="white-space: nowrap;" | No default value
|-
| '''WINDOWS_CML3_NAME'''
| Name of custom multiplier #3.
| No default value
|-
| '''WINDOWS_CML_LIST_FX''' '''WINDOWS_CML2_LIST_FX''' '''WINDOWS_CML3_LIST_FX'''
| C# expression for the multipliers listed in custom multiplier window for MULT. Syntax: <tt>WINDOWS_CML_LIST_FX=function</tt>. Example: <tt><nowiki>WINDOWS_CML_LIST_FX=GetList_PrefixArea(dxccList,"^(VK|ZL)$")</nowiki></tt> Example:<tt> <nowiki>WINDOWS_CML_LIST_FX=GetList_CustomArray("A|C|CA|CC|CE|V|VI|Z","|")</nowiki></tt>
| No default value
|-
| '''WINDOWS_CML_DATA''' '''WINDOWS_CML2_DATA''' '''WINDOWS_CML3_DATA'''
| Source of data for custom multiplier window 1, 2, and 3. Valid values: MULT1, MULT2, MULT3, QSODIFF, QSODIFF_SP, and QSODIFF_CQ.
| No default value
|-
| '''WINDOWS_CML_SHOW_GROUP''' '''WINDOWS_CML2_SHOW_GROUP''' '''WINDOWS_CML3_SHOW_GROUP'''
| Controls if custom multiplier window 1, 3, and 3 show the multipliers grouped, if groups are defined. Valid values: YES and NO.
| Default value: NO
|-
| '''WINDOWS_CML_RESIZABLE''' '''WINDOWS_CML2_RESIZABLE''' '''WINDOWS_CML3_RESIZABLE'''
| Controls if custom multiplier windows are resizable.
| Default value: NO
|-
| '''WINDOWS_CML_LABELS_IN_ROW''' '''WINDOWS_CML2_LABELS_IN_ROW''' '''WINDOWS_CML3_LABELS_IN_ROW'''
| Controls number of MULT labels in each row of its custom multiplier window. Valid values: -1 and positive integers. -1 means DXLog default 10.
| Default value: -1
|-
| '''WINDOWS_CML_ALL_LABELS_IN_ROW''' '''WINDOWS_CML2_ALL_LABELS_IN_ROW''' '''WINDOWS_CML3_ALL_LABELS_IN_ROW'''
| Controls the number of MULT labels in each row of its custom multiplier window when all bands are displayed. Valid values: -1 and positive integers. -1 means DXLog default 20.
| Default value: -1
|-
| '''WINDOWS_CML_HIDDEN_CONT''' '''WINDOWS_CML2_HIDDEN_CONT''' '''WINDOWS_CML3_HIDDEN_CONT'''
| Hides a custom multiplier window for stations from selected continents. Currently not used in any contest.
| style="white-space: nowrap;" | Default value: None
|-
| '''WINDOWS_CML_HIDDEN_DXCC''' '''WINDOWS_CML2_HIDDEN_DXCC''' '''WINDOWS_CML3_HIDDEN_DXCC'''
| Hides a custom multiplier window for stations from selected DXCC. Syntax: <tt>WINDOWS_CML_HIDDEN_DXCC=list</tt> Example: <tt>WINDOWS_CML_HIDDEN_DXCC=*+G;GI;GW;GM;GJ;GU;GD</tt> hides the custom multiplier window for UK stations. Example: <tt>WINDOWS_CML_HIDDEN_DXCC=*-SM;LA;OZ;OH</tt> shows the custom multiplier window only for Scandinavian stations.
| No default value
|-
| '''WINDOWS_WKD_DXCC_ENABLED'''
| Enables worked DXCC window. '''Important:''' The worked DXCC window will only update on logging if DXCC is a valid multiplier for the contest. If you want to use this window for e.g., a VHF contests, you must define a zero-worth DXCC multiplier. E.g. <tt>MULT2_TYPE=DXCC</tt> <tt>MULT2_FIELD=FROM_DXCC</tt> <tt>MULT_SUM=NO</tt> Valid values: YES and NO.
| Default value: NO
|-
| '''WINDOWS_WKD_DXCC_HIDDEN_CONT'''
| Hides worked DXCC window for stations from selected continent. Example: <tt>WINDOWS_WKD_DXCC_HIDDEN_CONT=*-AS<tt> shows only the worked DXCC window for Asian stations.
| No default value
|-
| '''WINDOWS_WKD_DXCC_HIDDEN_DXCC'''
| Hides worked DXCC window for stations from selected DXCC. C.f. WINDOWS_CML_HIDDEN_DXCC above for syntax.
| No default value
|-
| '''WINDOWS_WKD_DXCC_SHOW_ONLY_CONT'''
| Show only entities from the listed continents in the worked DXCC window. Example: <tt>WINDOWS_WKD_DXCC_SHOW_ONLY_CONT=NA;SA</tt> shows only NA and SA entities in the worked DXCC window.
| No default value
|-
| '''WINDOWS_WKD_DXCC_CONT_FILTER'''
| Defines which DXCC entities from a selected continent to show in the worked DXCC window. Example: <tt>WINDOWS_WKD_DXCC_CONT_FILTER=SA:9Y;P4;PJ2;PJ4</tt> will only include 9Y, P4 and PJ2 from South America. You can have several of this key.
| No default value
|-
| '''WINDOWS_WKD_DXCC_HIDE_DXCC'''
| Hides a list of DXCC entities from the worked DXCC window. Example: <tt>WINDOWS_WKD_DXCC_HIDE_DXCC=K;VE</tt> hides US and Canada from the worked DXCC window.
| No default value
|-
| '''WINDOWS_WKD_GRID_ENABLED'''
| Enables worked grids window. Valid values: YES and NO.
| Default value: NO
|-
| '''WINDOWS_WKD_PFX_ENABLED'''
| Enables worked prefixes window. Valid values: YES and NO.
| Default value: NO
|-
| '''WINDOWS_WKD_PFX_HIDDEN_CONT'''
| Hides worked prefixes window for stations from selected continent. C.f. WINDOWS_WKD_DXCC_HIDDEN_CONT above for syntax.
| Default is to hide nothing
|-
| '''WINDOWS_WKD_PFX_HIDDEN_DXCC'''
| Hides worked prefixes window for stations from selected DXCC. C.f. WINDOWS_CML_HIDDEN_DXCC above for syntax.
| Default is to hide nothing
|-
| '''WINDOWS_WKD_PFX_DATA'''
| Source of worked prefixes data. Valid values: MULT1, MULT2, and MULT3.
| No default value
|-
|}

=== Livescore keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''LIVESCORE_ASSISTED'''
| List of assistance categories used for live score reporting. List must have the same number of items as mode CATEGORIES.
| Default value: Value of CABRILLO_ASSISTED
|-
| '''LIVESCORE_BAND''' '''LIVESCORE_BAND_SPECIAL'''
| List of band categories used for live score reporting. List must either have one single value of the same number of items as CABRILLO_BAND. If a single value, this is valid for all categories. Band names are Cabrillo convention. Non standard band categories recognized by score boards are: 2-BAND, 3-BAND, LOW-BAND, and HIGH-BAND. LIVESCORE_BAND_SPECIAL allows the use of non-standard values.
| Default value: Value of CABRILLO_BAND
|-
| '''LIVESCORE_CATEGORY_MODES'''
| List of contest mode categories used for live score reporting. List must have the same number of items as CATEGORY_MODES.
| Default value: Value of CATEGORY_MODES
|-
| '''LIVESCORE_CONTEST_NAME'''
| Contest name used for live score reporting. If the string contains <tt>{MODE}</tt> this will be replaced by the current contest mode capitalized.
| Default value: Value of CABRILLO_CONTEST_NAME
|-
| '''LIVESCORE_MODES'''
| List of modes used for live score reporting. List must have the same number of items as MODES.
| Default value: Value of CABRILLO_MODE
|-
| '''LIVESCORE_MULT'''
| List of multiplier "names" in numerical order used for live score reporting. Must have the same number of items as contest multipliers, but names may be repeated. Used when the multiplier type is not explicit, such as grid square. Valid multiplier types are <tt>ZONE, COUNTRY, STATE, GRIDSQUARE, WPXPREFIX, PREFIX, HQ</tt> and <tt>NONE</tt>.
| By default DXLog recognizes "country", "zone", "hq", "wpxprefix", and "state".
|-
| '''LIVESCORE_OPERATOR''' '''LIVESCORE_OPERATOR_SPECIAL'''
| List of types of operation used for live score reporting. List must have the same number of items as CATEGORIES. LIVESCORE_OPERATOR_SPECIAL allows the use of non-standard values.
| Default value: Value of CABRILLO_OPERATOR
|-
| '''LIVESCORE_POWER'''
| List of output power classes used for live score reporting. List must have the same number of items as CLASS.
| Default value: Value of CABRILLO_POWER
|-
| '''LIVESCORE_RTC_SENT_EXCHANGE'''
| List of the exchange elements sent by own station. Accepts *RGX conditionals like CABRILLO_LINE. Valid keywords are NR, OPNAME, EXCHANGE, POWER, MYCQZONE, MYITUZONE, MYDXCC, STATE, GRID4, GRID, and NOTHING. A literal string must be preceded by a single quote '. '''Important: This key is required in contest definition file to enable Real Time Contest QSO upload.'''
| Default value: None
|-
| '''LIVESCORE_TRANSMITTER'''
| List of number of transmitters categories used for live score reporting. List must have the same number of items as CATEGORIES.
| Default value: Value of CABRILLO_TRANSMITTER
|-
|}

=== QTC keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''QTC_ENABLED'''
| Enables QTC mechanics.
| Default value: NO
|-
| '''QTC_SEND_ENABLED'''
| Enables QTC sending.
| Default value: !SOURCE->CONT:^EU$
|-
| '''QTC_RECV_ENABLED'''
| Enables QTC receiving.
| Default value: SOURCE->CONT:^EU$
|-
| '''QTC_SEND_RGX'''
| Regular expression controlling the transmission of QTC.
|Default value: DEST->CONT:^EU$
|-
| '''QTC_RECV_RGX'''
| Regular expression controlling the reception of QTC.
|Default value: !DEST->CONT:^EU$
|-
|}

=== Other keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''ADIF_KEYS'''
| Allows for including custom keys in ADIF export. The syntax is <tt>ADIF_KEYS=</tt>''ADIFKEY;expression;regex1;regex2''. ''regex1'' and ''regex2'' are optional but must both evaluate as true for the key to be included in the export. The syntax for ''expression'' is C# and based on internal <tt>DXQSO</tt> object structure. Received exchanges are <tt>$VALUE.Rcvd</tt>, <tt>$VALUE.Rcvd4</tt>, <tt>$VALUE.RecInfo</tt>, <tt>$VALUE.RecInfo2</tt>, and <tt>$VALUE.RecInfo3</tt>. <tt>Rcvd4</tt> is the <tt>Rcvd</tt> object without the signal report. So to, for instance, export the received exchange as US/VE state use <tt><nowiki>ADIF_KEYS=STATE;$VALUE.Rcvd4;DEST->DXCC:^(K|KL|KH6|VE)$;DEST->RCVD:^[A-Z]{2}$</nowiki></tt>. To export the second exchange as operator name use <tt>ADIF_KEYS=NAME;$VALUE.RecInfo</tt> but note that DXLog will export a field of type NAME automatically. The following <tt>$VALUE.xxx</tt> keys are available: <tt>Sent, Rcvd, Rcvd4, RecInfo, RecInfo2, RecInfo3, Az, Mult, Mult1, Mult2, Mult3, Lp, Period, Band, Mode, Callsign, QRB (integer), Nr (integer), Stn, OriginStnID, Operator,</tt> and <tt>RadioVFO</tt>. Please note that you can also use C# style string manipulation such as <tt>Substring(start, length)</tt> etc. There is no limit on the number of <tt>ADIF_KEYS</tt> lines in a contest definition file, but with the exception of COMMENT, only one per key is allowed to be valid at one time. Multiple COMMENT keys are appended. The keywords $EXCHANGE, $POWER, $ITUZONE, $CQZONE, $DXCC, $TIME, $SERIAL, $GRID, $GRID4, $OPNAME, $STATE, or any C# string expression are also allowed, e.g., <tt>ADIF_KEYS=MY_SIG;WWFF</tt> and <tt>ADIF_KEYS=MY_SIG_INFO;$EXCHANGE</tt>. The following keys are reserved and cannot be customized QSO_DATE, TIME_ON, STATION_CALLSIGN, FREQ, BAND, CONTEST_ID, MODE, CALL, RST_SENT, RST_RCVD, OPERATOR, APP_DXLOG_RCVD, APP_DXLOG_RECINFO, APP_DXLOG_RECINFO2, APP_DXLOG_RECINFO3, APP_DXLOG_POINTS, APP_DXLOG_STNID, APP_DXLOG_STN, APP_DXLOG_MULT1, APP_DXLOG_MULT2, APP_DXLOG_MULT3, APP_DXLOG_NR, MY_GRIDSQUARE, MY_NAME, MY_CQ_ZONE, MY_ITU_ZONE, PFX, OWNER_CALLSIGN, and TX_PWR.
|Default value: None
|-
| '''ASTROPHYSICS'''
| Enables DXLog's propagation enhancing features. Valid values: YES and NO.
| Default value: NO
|-
| '''EDI_TOTAL_SCORE'''
| Defines how CToSc in EDI export is calculated. Valid values: ALL or PER_BAND.
| Default value: PER_BAND
|-
| '''OVERRIDE_INVALID_QSO_MESSAGE'''
| Suppress invalid QSO message for selected cases. Syntax is <tt>OVERRIDE_INVALID_QSO_MESSAGE=</tt>''IncaseRegex;AndRegex'' Example: <tt>OVERRIDE_INVALID_QSO_MESSAGE=DEST->DXCC:^K$;DEST->RCVD:^$</tt> will suppress complaints about invalid QSO when the RCVD field is empty US stations. '''This is however a legacy function with limited usefulness.''' To ensure stations without valid exchanges are correctly displayed in the bandmap you typically need to add zero-points dummy rules that will prevent error messages anyway.
| style="white-space: nowrap;" | Default value: None
|-
| '''SATELLITE_BAND'''
| Makes all QSO on a particular band or bands treated as satellite QSO. Example: <tt>SATELLITE_BAND=2300;QO-100;8089500</tt> will make all 13cm QSO in the log QO-100 satellite QSO with a receive frequency 8089500kHz higher than the logged frequency. Only affects UDP broadcast and ADIF export. More than one per contest definition is allowed.
| Default value: None
|-
| '''SELF_SPOT_ALLOWED'''
| Enables spotting of own station. Either a single YES/NO or a semicolon separated list of YES/NO with the same number of entries as CATEGORIES.
| Default value: NO
|-
| '''SELF_SPOT_MINPERIOD'''
| Controls the minimum time in minutes between spots of own station.
| Default value: 10
|-
| '''SELF_SPOT_MODES'''
| Controls the modes for which self spotting is allowed. Either ALL or a semicolon separated list of modes.
| Default value: ALL
|-
| '''SELF_SPOT_PER_RADIO'''
| Controls whether the self spotting period is per radio or per station.
| Default value: YES
|-
| '''SPRINT_LOGIC_ALLOWED'''
| Enable "sprint logic" check box in the Standard Messages panel's Options tab.
| Default value: NO
|-
| '''WARNING_FILE'''
| Name of a frequency range warning file located in <tt>%appdata%\DXLog\Database</tt>. The format of each line in the warning file is: <tt>Mode regular expression;frequency range;Message</tt> Example: <tt><nowiki>CW;3400-3520;Warning: Operation not allowed on this frequency</nowiki> <nowiki>CW;3550-3900;Warning: Operation not allowed on this frequency</nowiki> <nowiki>SSB;3400-3600;Warning: Operation not allowed on this frequency</nowiki> <nowiki>SSB;3675-3700;Warning: Operation not allowed on this frequency</nowiki> <nowiki>SSB;3725-3900;Warning: Operation not allowed on this frequency</nowiki></tt> '''Important: File name casing must be correct for online update to work.'''
| No default value
|-
| '''WINDOWS_ON4KST_ENABLED'''
| Enables ON4KST messaging window
| Default value: NO
|-
|}

==Less obvious constructs==

Entry type based on DXCC of logged station.

<tt>FIELD_RCVD_TYPE=DXCC:^PA$=MULT;!DXCC:^PA$=NR</tt> 

The first match in the line is used, allowing "all others" type of constructs

<tt>FIELD_RCVD_TYPE=DXCC:^(K|KH6|KL|VE)$=MULT;DXCC:.=NR</tt>

Other multiplier than the defined.

<tt>MULT1_EXCEPTION=!SOURCE->DXCC:^(JW|JX|LA|OH|OH0|OJ0|OX|OY|OZ|SM|TF)$;PFX_AREA</tt>

Zero padding of an exchange. Normally not needed since DXLog zero pads several input types.

<tt>POINTS_FIELD_BAND_MODE=DEST->CONT:SOURCE->CONT;!SOURCE->ITUZONE:DEST->RCVD{F=R,2,0};ALL;ALL;3</tt>

Using a field value as the QSO score

<tt>POINTS_FIELD_BAND_MODE=!CONFIG->EXCHANGE:^ZZ$;ALL;ALL;ALL;RECINFO2</tt>

Adding alternative exchanges to multiplier list

<tt>CFG_MULT_RGX_CHECK=^0?[1-9]$|^[1-8][0-9]?$|^90$|CUSTOM_MULT_LIST 
FIELD_RCVD_RGX_CHECK=DEST->RCVD:^0?[1-9]$|^[1-8][0-9]?$|^90$;DEST->RCVD:CUSTOM_MULT_LIST</tt>

Disabling exchange checking for certain stations

<tt>FIELD_RECINFO_MANDATORY_RGX_EXC=!DEST->DXCC:^(K|KL|KH6|VE)$;DEST->CALL:/[AM]M$ 
FIELD_RECINFO_CHECK_FORMAT_FX=!DEST->DXCC:^(K|KL|KH6|VE)$>>""</tt>

Contest definition

2026-03-30T04:46:30Z

Sm7iun: /* Other keys */

==Introduction==

Contest rules vary greatly and are typically defined by the contest organizers. 
The differences can be in points per QSO, multiplier determination and calculations, etc. 
To support a wide variety of rules and to allow for easy adding/changing of contest rules in DXLog, 
contest rules are defined and controlled through a contest config file. 

Contest config files are "semi human readable", plain text files located in the '''Contest''' subdirectory in 
DXLog's installation directory. A wide range of contest definition files are included in the DXLog standard installation. 
The contest config files in the protected installation directory are however not intended for editing or modification 
For this, there is a copy of the directory in Windows' unprotected AppData directory structure. 
Since this is a hidden directory, a drop down menu item is provided for easy access. (File | Open configuration directory) 

Each time DXLog is started, the content of the installation subdirectory and the AppData subdirectory is compared. 
If a contest config file in the installation subdirectory is newer than its copy in the AppData subdirectory 
(e.g. due to it being updated as part of a new DXLog release), the AppData file is overwritten. 

In the opposite case (e.g. due to own modifications of a contest config file), the AppData file remains unchanged. 
This means that any modifications of existing contest config files should be done in the AppData directory, but that 
such modifications may be overwritten if a newer version is distributed in a later DXLog release. 
To secure that a contest config file is not overwritten by future DXLog releases, create a file with a new name. 
The same mechanic, with a master directory and an AppData copy, applies to data base (i.e. pre-fill or call history) files. 

If you have developed a contest config file that is proven to be correct and that could be useful others, Please contact 
the development team to discuss adding it to DXLog's standard contest repertoire.

[[image:Configurationpaneltagged3.png|800px]] 
Relation between configuration keys and macros and their related text boxes and drop down menus in the contest configuration panel.
 

==File structure==

Each line in a contest definition file usually contains '''KEY + VALUE''' pairs. 
The pair is always separated by the "=" sign. For example:

<code>CONTESTNAME=9A CW</code>

This means the ''field key'' is '''CONTESTNAME''' and the ''field value'' is '''9A CW'''.

==Regular expressions==

You will see that in many cases DXLog is using regular expressions to verify condition validation and process entries.

If you are not familiar with regular expressions (regex for short) there are many online resources available. 
One tutorial can be found [https://www.regular-expressions.info/tutorial.html here].

For example, regular expressions are used to check if the user keyboard entry is valid against a condition or 
set of conditions, for QSO points calculations etc.

Regular expressions in the contest configuration file can be defined as fixed values, but they can 
also compare QSO data against fixed values.

Example: We want to validate the user entered data in some of the fields. For example, we want 
to validate that the user is allowed to enter NY, FL, GA, or MA in the EXCHANGE field on the contest 
configuration screen.

The contest configuration key for this operation is: <code>CFG_MULT_RGX_CHECK</code>. 

So to create a validation, as per the previous example, we need the following definition 
in the contest config file:

: <code>CFG_MULT_RGX_CHECK=^NY$|^FL$|^GA$|^MA$</code>

: <code>^</code> denotes start of the string <code>$</code> denotes end of the string <code>|</code> separates alternative matching patterns, forming a logical or

Another example is to validate that the Exchange field is a two digit number or a six position grid:

: <code>CFG_MULT_RGX_CHECK=^([0-9]{2}|[A-R]{2}[0-9]{2}[A-X]{2})$</code>

: <code>()</code> surrounds alternative matching patterns <code>{}</code> forms a repetition of the preceding matching pattern

QSO data is addressed using a origin key (CONFIG, SOURCE, or DEST) and a content key (CALLSIGN, EXCHANGE, DXCC, etc.). 
They are combined using "->". Examples of QSO data keys are CONFIG->POWER, SOURCE->DXCC, and DEST->RCVD.

Not all possible combinations of origin keys and content keys are valid. Please see below for valid combinations.

{|class="wikitable"
|+style="text-align:Left;"|Available origin keys
|-
| '''CONFIG'''
| Information originating from contest configuration panel. If empty, derived from callsign.
|-
| '''SOURCE'''
| Information relating to own station. Always derived from station callsign.
|-
| '''DEST'''
| Information relating to other station.
|}

{|class="wikitable"
|+style="text-align:Left;"|Available content key combinations
|-
| '''CONFIG'''
| '''->'''
| '''ARRLRR'''
| A regular expression that matches the two last digits of the current and the three previous years. As an example it is <tt><nowiki>^(20|19|18|17)$</nowiki></tt> in 2020.
|-
| '''CONFIG''' or '''SOURCE''' or '''DEST'''
| '''->'''
| '''CALL'''
| Callsign.
|-
| '''CONFIG'''
| '''->'''
| '''CATEGORY'''
| The dropdown menu text of the entry category selected in the contest configuration panel in upper case.
|-
| '''CONFIG'''
| '''->'''
| '''CLASS'''
| The contest's active power class as selected in the contest configuration panel in upper case.
|-
| '''SOURCE''' or '''DEST'''
| '''->'''
| '''CONT'''
| Continent. Two letter acronym.
|-
| '''CONFIG'''
| '''->'''
| '''CQZONE'''
| CQ zone as entered in the contest configuration panel zero padded to two digits.
|-
| '''SOURCE''' or '''DEST'''
| '''->'''
| '''CQZONE'''
| CQ zone derived from the callsign zero padded to two digits.
|-
| '''CONFIG'''
| '''->'''
| '''DXCC'''
| DXCC prefix as entered in the contest configuration panel.
|-
| '''SOURCE''' or '''DEST'''
| '''->'''
| '''DXCC'''
| Official DXCC prefix derived from the callsign where international airspace/waters is "-".
|-
| '''CONFIG'''
| '''->'''
| '''EXCHANGE'''
| The content of the contest exchange field in the contest configuration panel.
|-
| '''CONFIG'''
| '''->'''
| '''GRID'''
| The content of the grid field in the contest configuration panel.
|-
| '''CONFIG'''
| '''->'''
| '''ITUZONE'''
| ITU zone as entered in the contest configuration panel zero padded to two digits.
|-
| '''SOURCE''' or '''DEST'''
| '''->'''
| '''ITUZONE'''
| ITU zone derived from the callsign zero padded to two digits.
|-
| '''CONFIG'''
| '''->'''
| '''MODE'''
| The chosen contest mode in upper case.
|-
| '''DEST'''
| '''->'''
| '''MODE'''
| The current QSO mode.
|-
| '''CONFIG'''
| '''->'''
| '''OPNAME'''
| The content of the operator name field in the contest configuration panel.
|-
| '''CONFIG'''
| '''->'''
| '''OVERLAY'''
| The overlay menu selection text in upper case. (Note that this is not the Cabrillo overlay)
|-
| '''SOURCE''' or '''DEST'''
| '''->'''
| '''WPX'''
| Callsign prefix per WPX rules.
|-
| '''SOURCE''' or '''DEST'''
| '''->'''
| '''PFX_AREA'''
| The callsign prefix formatted as main DXCC prefix plus "." and the prefix digit. E.g. "SM.0" or "EA.7". Note that DXCC prefixes containing a number keeps this, e.g., OH0DX is prefix area "OH0.0".
|-
| '''CONFIG'''
| '''->'''
| '''POWER'''
| The content of the power field in the contest configuration panel.
|-
| '''DEST'''
| '''->'''
| '''RCVD'''
| First element in the received contest exchange.
|-
| '''DEST'''
| '''->'''
| '''RECINFO'''
| Second element in the received contest exchange.
|-
| '''DEST'''
| '''->'''
| '''RECINFO2'''
| Third element in the received contest exchange.
|-
| '''DEST'''
| '''->'''
| '''RECINFO3'''
| Fourth element in the received contest exchange.
|-
| '''CONFIG'''
| '''->'''
| '''STATE'''
| The content of the State/Province/Other field in the contest configuration panel.
|-
| '''CONFIG'''
| '''->'''
| '''STATION'''
| The station category text in upper case. (Not the Cabrillo station category)
|-
| '''DEST'''
| '''->'''
| '''TIME_HOUR'''
| The hour of the QSO time as a string with values from "0" to "23".
|}

===Formatting suffix===

An origin/content key combination can have a formatting suffix, similar to that for <tt>CABRILLO_LINE</tt>. 
For instance,

<code>DEST->RCVD{F=R,2,0}:SOURCE->ITUZONE</code>

will zero pad the received exchange to a length of two before comparing. ITUZONE and CQZONE are always two digits.

===Extension suffix===

An origin/content key combination can have an extension suffix, which can also be a regular expression. 
For instance

<code>DEST->RCVD:DEST->CONT+[MQY]</code>

will evaluate true when the received exchange is identical to your own continent abbreviation followed by either M, Q, or Y.

===Examples===

1. We want to validate a value which could change on each entry into the log.

For example, we want to calculate points for each QSO with the same country, on the 160m band, in the CW and SSB mode, with 1 point.

The relevant contest configuration key for QSO points calculation is <code>POINTS_FIELD_BAND_MODE</code>. 
To create the calculation, as per the previous example, we need the following definition in the contest config file:

<code>POINTS_FIELD_BAND_MODE=SOURCE->DXCC:DEST->DXCC;ALL;^160$;^(CW|SSB)$;1</code>

We can read this definition in the following way: 
If the <code>SOURCE</code> (our) DXCC is the same as <code>DEST</code> (other station's) DXCC and the 
band is 160 and the mode is CW or SSB then the QSO is worth 1 point. In the above definition notice 
the <code>SOURCE</code> and <code>DEST</code> keys. We can also use the <code>CONFIG</code> key.

2. We want to display a per-mode QSO breakdown for mixed mode contest entry

<code>SCORE=BY_BAND_MODE</code> 
<code>SCORE_DISPLAY=BAND;QSO;*RGX:CONFIG->MODE:MIX>>QSO(CW){CW};*RGX:CONFIG->MODE:MIX>>QSO(SSB){SSB};MULT1(CTY);DUP;POINTS</code>

'''Important:''' The first "QSO" key can not be made conditional due to internal limitations.

==Functions and FX expressions==

Some keys allow not only keywords but also functions as arguments.

Functions follow C# syntax and have access to all string, number, and boolean manipulation functions in the language plus a number of helper functions.

The keywords available for regular expressions (see above) area also available in functions.

Some keywords assume an expression that returns a string, like MULT1_FX and FIELD_RCVD_CHECK_FORMAT_FX.

Examples: 
<tt><nowiki>MULT1_FX=$FIELDVALUE.Substring(0,4)</nowiki></tt> 
<tt><nowiki>MULT1_FX=$FIELDVALUE.Substring(0,$FIELDVALUE.IndexOf('/'))</nowiki></tt>

The first example picks the first four characters in the string as multiplier. 
The second example picks the string following the first slash ("/") character as multiplier. 
Two variables are available: $FIELDVALUE which is the multiplier or exchange itself, and $CALLSIGN which is the other station's call.

===String helper functions===

{|class="wikitable"
|+style="text-align:Left;"|Available string helper functions
|-
| <tt><nowiki>Helpers.GetBrazilUF($FIELDVALUE,$CALLSIGN)</nowiki></tt>
| Returns the two letter Brazilian region. Uses the exchange if valid, otherwise derives it from the callsign.
|-
| <tt><nowiki>Helpers.GetLastLetter($FIELDVALUE)</nowiki></tt>
| Returns the last character of a callsign, including slashed number suffixes.
|-
| <tt><nowiki>Helpers.GetLastLetterPure($FIELDVALUE)</nowiki></tt>
| Returns the last character of a callsign with a slashed prefix and suffixes removed.
|-
| <tt><nowiki>Helpers.GetOblast($FIELDVALUE)</nowiki></tt>
| Returns the Russian region based on field which should be callsign.
|-
| <tt><nowiki>Helpers.GetOblastSPLO($FIELDVALUE,$CALLSIGN)</nowiki></tt> 
| Returns the Russian region based on field which should be RCVD. Uses the RDA exchange for SP/LO stations to determine oblast and the callsign for all others. Used in UA1DZ Memorial contest. Multiplier field must be FROM_DXCC.
|-
| <tt><nowiki>Helpers.GetPureCall($FIELDVALUE)</nowiki></tt> 
| Returns the field (callsign) without prefix, slashes, etc.
|-
| <tt><nowiki>Helpers.GetPrefixArea($FIELDVALUE, $CALLSIGN)</nowiki></tt> 
| Returns the prefix area as NN.0. Multiplier field must be FROM_DXCC.
|-
| <tt><nowiki>Helpers.GetPrefixAreaVEGeo($FIELDVALUE, $CALLSIGN)</nowiki></tt>
| Returns the prefix area as NN.0 but treats Canadian geographical prefixes (VY2, etc.) as own call areas. Multiplier field must be FROM_DXCC.
|-
| <tt><nowiki>Helpers.GetSARLArea($FIELDVALUE)</nowiki></tt>
| Returns the SARL contest call area based on field which should be callsign.
|-
| <tt><nowiki>Helpers.GetSuffix($FIELDVALUE)</nowiki></tt>
| Returns the callsign suffix (characters after last number) based on field which should be callsign.
|-
| <tt><nowiki>Helpers.PadNumber3($FIELDVALUE)</nowiki></tt>
| Returns a single or double digit string string padded to three digits. Useful for contests with mixed serial and letter exchange.
|-
| <tt><nowiki>Helpers.PadNumber2($FIELDVALUE)</nowiki></tt>
| Returns a single digit string padded to two digits. Useful for contests with mixed zone and letter exchange.
|-
| <tt><nowiki>Helpers.ExtendCountyLine($FIELDVALUE,length)</nowiki></tt>
| Extends abbreviated county line exchanges in North American QSO parties. E.g., MABAR/BER is converted into MABAR/MABER.
|-
| <tt><nowiki>Helpers.Canada13($FIELDVALUE)</nowiki></tt>
| Returns NL when exchange is NF or LB. Does nothing for all other values, such as ELBE or NFX.
|}

===String list helper functions===

Some keywords assume an expression that returns a '''list of strings''', like WINDOWS_CML_LIST_FX. 

{|class="wikitable"
|+style="text-align:Left;"|Available string list helper functions
|-
| <tt><nowiki>GetList_PrefixArea(dxccList,regex)</nowiki></tt>
| Creates a multiplier list with all call areas prefixes
|-
| <tt><nowiki>GetList_PrefixAreaVEGeo(dxccList,regex)</nowiki></tt>
| Creates a multiplier list including Canadian (VY1, etc.) call areas
|-
| <tt><nowiki>GetList_CustomRange(format,start,end)</nowiki></tt>
| Creates a list of numbered multipliers
|-
| <tt><nowiki>GetList_CustomArray(string,separator)</nowiki></tt>
| Creates a custom list
|-
| <tt><nowiki>GetList_BrazilUF()</nowiki></tt>
| Creates a list containing the 27 Brazilian regions
|-
| <tt><nowiki>GetList_Oblast()</nowiki></tt>
| Creates a list containing the 85 Russian regions
|-
| <tt><nowiki>GetList_SARLArea()</nowiki></tt>
| Creates a list containing the 13 SARL contest call areas
|-
| <tt><nowiki>GetList_GridArray(center,height,width))</nowiki></tt>
| Creates a list of four letter grids around center
|}

'''Examples'''

<tt><nowiki>GetList_PrefixArea(dxccList,"^LA$")</nowiki></tt> - Creates a multiplier list with all Norwegian call areas. 
<tt><nowiki>GetList_PrefixAreaVEGeo(dxccList,"^(VE|K)$)</nowiki></tt> - Creates a multiplier list with all US and Canadian prefixes. 
<tt><nowiki>GetList_CustomRange("00",1,6)</nowiki></tt> - Creates the list 00, 01, 02, 03, 04, 05, and 06. 
<tt><nowiki>GetList_CustomArray("AB|AC|AD|AK|AM","|")</nowiki></tt> - Creates the list AB, AC, AD, AK, and AM. 
<tt><nowiki>GetList_GridArray(ownGrid,11,11)</nowiki></tt> - Creates a list of 121 grids centered around own location. 
<tt><nowiki>GetList_GridArray("JP81",9,9)</nowiki></tt> - Creates a list of 81 grids centered around JP81. 

===Number helper functions===

Some keywords assume an expression returning '''a number''', such as <tt>SCORE_TOTAL_FX</tt> and the second element of <tt>POINTS_CALC_F</tt>.

These assume FLEE syntax (see below).

<tt>SCORE_TOTAL_FX</tt> is the formula for the score for an individual QSO. 
Available variables available are <tt>$FIELDVALUE.Points</tt>, <tt>$FIELDVALUE.Mult1</tt>, 
<tt>$FIELDVALUE.Mult2</tt>, and <tt>$FIELDVALUE.Mult3</tt> having the values of the corresponding 
sums in the Summary window.

Example: <tt>SCORE_TOTAL_FX=$FIELDVALUE.Points+$FIELDVALUE.Mult1*2+$FIELDVALUE.Mult2*5</tt>
Example: <tt>SCORE_TOTAL_FX=$FIELDVALUE.Points*($FIELDVALUE.Mult1+If($FIELDVALUE.Mult2>10,10,$FIELDVALUE.Mult2))</tt>

<tt>POINTS_CALC_F</tt> is the formula for the points for certain QSO conditions.

===Boolean helper functions===

Other keys assume a '''boolean expression''' which can be either a regular expression (as described above) or 
an FX() expression. Examples are FIELD_RCVD_FX_CHECK and the first argument of MULT1_EXCEPTION. 
The syntax and operator repertoire is C#.

Examples: 
<tt><nowiki>MULT1_EXCEPTION=FX(Helpers.GetLastLetter("CONFIG->CALLSIGN").Equals(Helpers.GetLastLetter("DEST->CALL")));NONE</nowiki></tt> 
<tt><nowiki>MULT1_EXCEPTION=FX(("CONFIG->CALLSIGN").Substring(0,3).Equals(("DEST->CALL").Substring(0,3)));NONE</nowiki></tt> 
<tt><nowiki>MULT1_EXCEPTION=DEST->RCVD:^[KNS]DE;FX(("DEST->RCVD").Substring(1,2))</nowiki></tt> 

The first example does not count the QSO as a multiplier if the last letter is the same in the station's 
callsign and own callsign. The second example does not count the QSO as a multiplier if the first three characters 
is the same in the station's callsign and own callsign. The third example counts the first two characters of the 
exchange as multiplier if it starts with KDE, NDE or SDE.

The only available boolean helper function is:

<tt><nowiki>Helpers.Between(number, min, max)</nowiki></tt> - Returns true if number is between min and max.

===Available syntax for arithmetic expressions===

[[image:fleesyntax.png|500px]]

==Custom multiplier lists==

A custom multiplier list can only be used for multiplier type CUSTOM. FX type multipliers can not use a 
a listed set of multipliers but rely on a helper function to create its multiplier list, such as <tt>GetList_CustomRange()</tt>.

===Plain list of custom multipliers===

A list of custom multipliers is started by <tt>[MULTIPLIERS START]</tt> and ends with <tt>[MULTIPLIERS END]</tt>. 
The syntax for a multiplier having more than one name is shown below. In this example both NK and NR 
will count as the same multiplier; Norwich.

Example:
<tt>
: [MULTIPLIERS START]
: ...
: NL=London N1-22
: NN=Northampton
: NP=Newport
: NK{NK;NR}=Norwich
: NW=London NW1-11
: OL=Oldham
: OX=Oxford
: ...
: [MULTIPLIERS END]
</tt>

===Conditional lists of custom multipliers===

For contests such as US state QSO parties there are two types of participants with different sets of custom multipliers. 
To support this, a multiplier list can be conditional just like default messages. The regular expression can be of any type 
and check EXCHANGE, DXCC, CONT or whatever is suitable.

Syntax:
<tt>
: [MULTIPLIERS START]
: [VALID FOR=Regex1]
: M1=First multiplier 1
: M2=First multiplier 2
: ...
: [END VALID FOR]
: [VALID FOR=Regex2]
: L1=Second multiplier 1
: L2=Second multiplier 2
: ...
: [END VALID FOR]
: [MULTIPLIERS END]
</tt>

Example:
<tt>
: [MULTIPLIERS START]
: [VALID FOR=CONFIG->EXCHANGE:^(ADA|ALL|ARM|BEA|BED|BER|BLA|BRA|BUX)$]
: AK=Alaska
: AL=Alabama
: AR=Arkansas
: AZ=Arizona
: CO=Colorado
: ...
: [END VALID FOR]
: ...
: [MULTIPLIERS END]
</tt>

===Grouped list of custom multipliers===

Multipliers can be grouped for better display in the custom worked multipliers window enabled 
with the <tt>WINDOWS_CML_ENABLED</tt> key. The string following <tt>Group-></tt> is the displayed 
name of the group. The name has no impact on scoring. The syntax for alternative names for the same 
multiplier is different from the straight list. Alternative names for the same multiplier are 
instead separated with a slash. In the example below, QU, QC, and QUE will all count as the same 
multiplier; Quebec.

Example:
<tt>
: [MULTIPLIERS START]
: Group->K1_: CT,MA,ME,NH,RI,VT
: Group->K2_: NJ,NY
: Group->K3_: DE,PA,MD/DC
:...
: Group->VE1: NS
: Group->VE2: QC/QU/QUE
: Group->VE3: ON/ONT
: Group->VE4: MB/MAN
: ...
: [MULTIPLIERS END]
</tt>

Tip: In group names, the underscore character will be displayed as space. This is a simple way to 
create an even column width when groups have different length.

==General contest description keys==
{|class="wikitable"
|+style="text-align:Left;"|These keys are used for general contest description in the contest config file, such as the contest name, link to the rules etc.
|'''CONTESTGROUP'''
| Used for group contest when displaying the config screen for contest selection.
| e.g., DIGITAL MODES, 9A LOCAL CONTEST, etc.
|-
|'''CONTESTNAME'''
| The contest name as it will be shown and recognized in the contest selection box. Note: this can be same as the Cabrillo contest name, but usually it is the full contest name.
| This field is mandatory and must be unique for all files in contest definition directory.
|-
|'''CONTESTEXCH'''
| Web link to definition of contest exchange. Shown when entering invalid data in configuration panel's exchange field.
| e.g., https://www.iota-world.org/
|-
|'''CONTESTRULES'''
| External HTTP Link to contest rules. Adds "Contest rules" item to Help menu.
| e.g., https://www.cqww.com/rules.htm
|-
|'''CONTESTWEB'''
| External HTTP Link to contest rules. Adds "Contest web" item to Help menu.
| e.g., https://www.cqww.com
|-
|'''CONTEST_INFORMATION'''
| String with helpful information about operating the current contest. Adds "Contest information" item to Help menu and "Info" button in the Contest configuration window.
| e.g., Bonus stations are not recognized.\nLog non-members as 0000.
|}

==Contest configuration panel control keys==

{|class="wikitable"
|+style="text-align:Left;"|These keys are used for setting the contest configuration variables in the user configuration window.
|'''CATEGORIES'''
| Semicolon-separated list of contest categories shown in the category selection dropdown menu in the contest configuration panel. '''Important''': When defining own categories, the values of CABRILLO_OPERATOR, CABRILLO_TRANSMITTER, and CABRILLO_ASSISTED may have to be changed from their defaults. Also contests with only EDI export needs correct Cabrillo export keys. C.f the Cabrillo section below.
| Default value: Single operator, assisted;Single operator;Multi-operator, single transmitter; Multi-operator, two transmitters;Multi-operator, multi-transmitter;Checklog
|-
|'''CATEGORY_MODES'''
| Semicolon-separated list of contest modes shown in the mode selection dropdown menu in the contest configuration panel. '''Important:''' There is no contest mode key for CATEGORY-MODE. Phone, SSB, and AM are SSB. CW is CW. RTTY is RTTY. Mixed is MIXED. Digital, PSK31, JT65, FT8, and other digital modes are DIGI.
| Default value: CW;SSB;Mixed
|-
|'''CLASS'''
| Semicolon-separated list of contest power classes shown in the class selection dropdown menu in the contest configuration panel.
| Default value: High;Low;QRP
|-
|'''CFG_EMAIL_MANDATORY'''
| Controls if the Email field in the contest configuration panel requires an entry or can be empty. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_MULT'''
| Controls the use of the exchange field in contest configuration panel. Valid values are: ON and OFF. If OFF, the exchange field is greyed out.
| Default value: OFF
|-
|'''CFG_MULT_DX_ALLOWED'''
| Controls if "DX" is an acceptable entry in exchange field. For example in ARRL DX Contest, all USA/VE stations needs to enter their state/province, while all other stations enters DX here. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_MULT_SLASH_ALLOWED'''
| Allows the use of "/" in the Exchange field as separator for contests where the exchange can be one or more elements of the same type, such as county-line stations in some US QSO parties where a station can belong to more than one counties and thereby represent more than one multiplier in one QSO. '''Important:''' CFG_MULT_SLASH_IGNORED and CFG_MULT_SLASH_ALLOWED must never both be YES. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_MULT_SLASH_IGNORED'''
| Allows the use of "/" in the Exchange field as part of the exchange itself rather than as a separator '''Important:''' CFG_MULT_SLASH_IGNORED and CFG_MULT_SLASH_ALLOWED must never both be YES. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_MULT_MANDATORY'''
| Controls if the exchange field requires an entry or can be empty. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_MULT_ERRORTEXT'''
| Defines error text which is shown if the validity test for the exchange field fails. For example, in ARRL DX Contest, if the user enters a state abbreviation which is not in the approved list.
| Default value: "Invalid value in exchange field!"
|-
|'''CFG_MULT_FROM'''
| Alternative to using a regular expression to check validity of entry in Exhange field. Valid values are CUSTOM_MULT_LIST, CQZONE, and ITUZONE. '''Important''': CUSTOM_MULT_LIST obviously cannot be used if own exchange is not a valid multiplier
| Default value: Unused
|-
|'''CFG_MULT_RGX_CHECK'''
| Regular expression used to test validity of entry in Exchange field. Note that the regular expression can include the key CUSTOM_MULT_LIST meaning that any entry listed in the custom multiplier list is considered valid. Example: <tt><nowiki>CFG_MULT_RGX_CHECK=^AF$|^AS$|^EU$|^NA$|^OC$|^SA$|CUSTOM_MULT_LIST</nowiki></tt>
| Default value: ALL
|-
|'''CFG_CQZONE_ERRORTEXT'''
| Defines the error text shown if the entry in the CQ zone field fails the validity test.
| Default value: "Invalid CQ zone!"
|-
|'''CFG_CQZONE_MANDATORY'''
| Controls if the CQ zone field requires an entry or can be empty. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_GRID_ERRORTEXT'''
| Defines the error text shown if the entry in the GRIDSQUARE field fails the validity test.
| Default value: "Invalid entry in gridsquare field!"
|-
|'''CFG_GRID_MANDATORY'''
| Controls if the GRIDSQUARE field requires an entry or can be blank. Valid values are: YES and NO. Is automatically set to YES if contest has QRB-based scoring.
| Default value: NO
|-
|'''CFG_GRID_RGX_CHECK'''
| Regular expression used to test validity of data entered in the GRIDSQUARE field.
| Default value: <tt><nowiki>^[A-R][A-R][0-9][0-9][A-X][A-X]$</nowiki></tt>
|-
|'''CFG_ITUZONE_ERRORTEXT'''
| Defines error text shown if the entry in the ITU zone field fails the validity test.
| Default value: "Invalid ITU zone!"
|-
|'''CFG_ITUZONE_MANDATORY'''
| Controls if the ITU zone field requires an entry or can be empty. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_MYDXCC_ERRORTEXT'''
| Defines the error text shown if the entry in the DXCC field fails the validity test.
| Default value: "Unrecognized DXCC from DXCC field. Please enter valid country prefix in DXCC field"
|-
|'''CFG_MYDXCC_MANDATORY'''
| Controls if the DXCC field requires an entry or can be empty. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_OPNAME_ERRORTEXT'''
| Defines the error text shown if the entry in the operator name field fails the validity test.
| Default value: "Operator name field is mandatory!"
|-
|'''CFG_OPNAME_MANDATORY'''
| Controls if the operator name field requires an entry or can be empty. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_POWER_ERRORTEXT'''
| Defines the error text shown if the entry in the power field fails the validity test.
| Default value: "Invalid value in power field!"
|-
|'''CFG_POWER_MANDATORY'''
| Controls if the power field requires an entry or can be empty. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_POWER_RGX_CHECK'''
| Regular expression used to determine the validity of the power field entry.
| Default value: ALL
|-
|'''CFG_STATE_ERRORTEXT'''
| Defines the error text shown if the entry in the state/province/other field fails the validity test.
| Default value: "Invalid value in state/other field!"
|-
|'''CFG_STATE_FROM=CUSTOM_MULT_LIST'''
| Defines a list-based validity test for the state/province/other field. Alternative to to using a regular expression.
| Default value: absent
|-
|'''CFG_STATE_MANDATORY'''
| Controls if the state/province/other field requires an entry or can be empty. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_STATE_RGX_CHECK'''
| Regular expression used to test validity of entry in state/province/other field. Note that the regular expression can include the key CUSTOM_MULT_LIST meaning that any entry listed in the custom multiplier list is considered valid. Example: <tt><nowiki>CFG_STATE_RGX_CHECK=^YL$|^OM$|CUSTOM_MULT_LIST</nowiki></tt>
| Default value: ALL
|-
|'''OVERLAY'''
| Semicolon-separated list of contest overlays shown in the Overlay dropdown menu in the contest configuration panel. Disable CATEGORY-OVERLAY in the Cabrillo export by assigning OVERLAY one single value.
| Default value: ---;Classic;Rookie;Tribander/Single element;Youth;Novice/Tech;Over 50
|-
|'''OVERLAY_ASSISTED'''
| Single keyword or semicolon-separated list of YES/NO controlling if an overlay represents an unassisted category. With a single keyword, this applies to all overlays. Must have one or the same number of entries as OVERLAY. If the selected overlay corresponds to a NO, incoming cluster spots are blocked. In other cases, CABRILLO_ASSISTED decides.
| Default value: YES
|-
|'''STATION'''
| Semicolon-separated list of contest station categories shown in the Station dropdown menu in the contest configuration panel.
| Default value: Fixed;Distributed;Headquarter;Mobile;Portable; Rover;Rover-Limited;Rover-Unlimited;Expedition;School
|}

==Cabrillo export keys==

===Contest configuration keys===

{|class="wikitable"
|+style="text-align:Left;"|
| '''CABRILLO_ASSISTED'''
| Semicolon-separated list of mapping of categories to Cabrillo assistance types. MUST have the same number of entries as the defined contest categories. Valid list items are ASSISTED and NON-ASSISTED. '''Important: When a NON-ASSISTED category is selected, incoming cluster spots are blocked.'''
| Default value: ASSISTED;NON-ASSISTED;ASSISTED;ASSISTED;ASSISTED;ASSISTED
|-
| '''CABRILLO_ASSISTED_DISABLED'''
| No CATEGORY-ASSISTED line will be included in exported file. Tip: With this set to YES, cluster spots are never blocked.
| Default value: NO.
|-
| '''CABRILLO_BAND''' '''CABRILLO_BAND_SPECIAL'''
| Semicolon-separated list of band definition names for contests with band-limited categories. For value AUTO the band category will be ALL unless the log only contains QSO from a single band. In this case the band category will be this single band. For all other values of the key, log content is ignored. If only assigned a single value, such as 10M, ALL, or AUTO, this will be valid for all categories. Must be accompanied by a LIVESCORE_BANDS key when non standard values are used. Band names are Cabrillo convention 160M, ...6M, 2M, 222, 432, .... CABRILLO_BAND_SPECIAL allows the use of non-WWROF-standard values.
| Default value: AUTO;AUTO;ALL;ALL;ALL;ALL
|-
| '''CABRILLO_CLUB_FIELD'''
| Club name for Cabrillo export. Overrides the club field in the contest configuration window. Valid values are STATE or EXCHANGE.
| No default value
|-
| '''CABRILLO_CONTEST_NAME'''
| Formal contest name for Cabrillo export. If name contains <tt>{MODE}</tt> this will be replaced by the selected contest mode capitalized.
| No default value
|-
| '''CABRILLO_DEF_RECINFO''' '''CABRILLO_DEF_RECINFO2''' '''CABRILLO_DEF_RECINFO3'''
| Value to use in Cabrillo export if field is empty.
| Default value: Empty
|-
| '''CABRILLO_EXPORT_TYPE'''
| Controls structure of Cabrillo export. Valid values: PER_MODE and ALL.
| Default value: ALL
|-
| '''CABRILLO_LINE'''
| Use: <tt>CABRILLO_LINE=FREQ;MODE;DATE;TIME;MYCALL;SENT;NR{F=R,3,0,4}</tt> Data is taken from the field names and added to the Cabrillo line in the order entered. FREQ represents frequency of QSO, MODE represents mode etc. For more details on valid keywords and the use of conditional entries, see below.
| No default value
|-
| '''CABRILLO_LOCATION'''
| Semicolon-separated list of mapping of contest categories to Cabrillo LOCATION key. If defined, MUST have the same number of entries as the defined contest categories. Any string is a valid value. If left undefined, contest category has no effect on LOCATION in Cabrillo export. Alternative to CABRILLO_LOCATION_FIELD.
| Default value: Disabled
|-
| '''CABRILLO_LOCATION_FIELD'''
| Defines the source of the LOCATION: key in the Cabrillo export. Valid values are EXCHANGE, STATE, GRID, GRID4, GRID2, ITUZONE, and CQZONE. Alternative to CABRILLO_LOCATION.
| Default value: Disabled
|-
| '''CABRILLO_MODES'''
| Semicolon-separated list of mapping of the contest's modes (as defined by the MODES key) to Cabrillo modes in QSO lines. MUST have the same number of entries as the defined number of modes for the contest. WWROF defined values are CW, PH, DG, RY, and FM. See below for the full list of de-facto standard mode acronyms. Must be accompanied by a LIVESCORE_MODES key when non standard values are used.
| Default value: CW;PH
|-
| '''CABRILLO_OPERATOR''' '''CABRILLO_OPERATOR_SPECIAL'''
| Semicolon-separated list of mapping of categories to to Cabrillo operator count. MUST have the same number of entries as the defined contest categories. Valid list items are SINGLE-OP, MULTI-OP, and CHECKLOG. Must be accompanied by a LIVESCORE_OPERATOR key when non standard values are used. CABRILLO_OPERATOR_SPECIAL allows the use of non-WWROF-standard values.
| Default value: SINGLE-OP;SINGLE-OP; MULTI-OP;MULTI-OP;MULTI-OP;CHECKLOG
|-
| '''CABRILLO_OVERLAY''' '''CABRILLO_OVERLAY_SPECIAL'''
| Semicolon-separated list of mapping of category overlays to Cabrillo overlays. MUST have the same number of entries as the defined overlays. Any string is a valid entry. It is possible to block incoming cluster spots for one or several overlays. C.f. OVERLAY_ASSISTED. CABRILLO_OVERLAY_SPECIAL allows the use of non-WWROF-standard values.
| Default value: ;CLASSIC;ROOKIE;TB-WIRES;YOUTH;NOVICE-TECH;OVER-50
|-
| '''CABRILLO_OVERLAY_DISABLED'''
| Suppresses CATEGORY-OVERLAY in export.
| Default value: NO
|-
| '''CABRILLO_POWER''' '''CABRILLO_POWER_SPECIAL'''
| Semicolon-separated list of mapping of category power classes to Cabrillo power classes. MUST have the same number of entries as the contest's power classes. List items can be any string but WWROF defined keywords are HIGH, LOW, and QRP. Must be accompanied by a LIVESCORE_POWER key when non standard values are used. CABRILLO_POWER_SPECIAL allows the use of non-WWROF-standard values.
| Default value: HIGH;LOW;QRP
|-
| '''CABRILLO_QTC_LINE'''
| Definition of Cabrillo output for QTC. C.f. '''CABRILLO_LINE'''. Valid keywords are: FREQ, MODE, DATE, TIME, RCVDBY, GRNUM, SENTBY, QTCTIME, QTCCALL, and QTCSERIAL.
| Default value: Disabled
|-
| '''CABRILLO_STATION''' '''CABRILLO_STATION_SPECIAL'''
| Semicolon-separated list of mapping of station categories to Cabrillo station categories. MUST have the same number of entries as the defined station categories. CABRILLO_STATION_SPECIAL allows the use of non-WWROF-standard values.
| Default value: FIXED;DISTRIBUTED;HQ;EXPLORER;MOBILE;PORTABLE;ROVER; ROVER-LIMITED;ROVER-UNLIMITED;EXPEDITION;SCHOOL
|-
| '''CABRILLO_TIME''' '''CABRILLO_TIME_SPECIAL'''
| Semicolon-separated list of duration for each contest category. '''Important:''' Must have the same number of entries as there are contest categories. WWROF defined values are 6-HOURS, 8-HOURS, 12-HOURS, and 24-HOURS. CABRILLO_TIME_SPECIAL allows the use of non-WWROF-standard values.
| Default value: Disabled
|-
| '''CABRILLO_TRANSMITTER''' '''CABRILLO_TRANSMITTER_SPECIAL'''
| Semicolon-separated list of mapping of categories to Cabrillo operator counts. '''Important:''' Must have the same number of entries as the defined contest categories. WWROF defined values are ONE, TWO, LIMITED, UNLIMITED, and SWL. Must be accompanied by a LIVESCORE_TRANSMITTER key when non standard values are used. CABRILLO_TRANSMITTER_SPECIAL allows the use of non-WWROF-standard values.
| Default value: ONE;ONE;ONE;TWO;UNLIMITED;UNLIMITED
|}

===CABRILLO_LINE keywords===

Important note: If you want to take full control of the columns to e.g. concatenate fields in the export, 
this is done by adding a trailing asterisk ("*") to the keys below. This will remove the extra space 
following a field to guarantee separation. Extra spaces required to align to certain character positions 
can be added using the <tt>DUMMY</tt> keyword.

Surrounding the keyword with parentheses (e.g., <tt>(EXCHANGE)</tt>) means the key is optional at import. 
This typically only works for keywords at the end of the line, such as STN.

{|class="wikitable"
|+style="text-align:Left;"|
| '''Key'''
| '''Content'''
| '''Default format'''
|-
| <tt>CALL</tt>
| Logged station's call.
| <tt>{F=L,13, }</tt>
|-
| <tt>DATE</tt>
| Date of QSO. Format YYYY-MM-DD.
| <tt>{F=L,10, }</tt>
|-
| <tt>DUMMY</tt>
| Only spaces.
| <tt>{F=L,5, }</tt>
|-
| <tt>DXCC</tt>
| DXCC of logged station. Derived from CTY database.
| <tt>{F=L,6, }</tt>
|-
| <tt>EXCHANGE</tt>
| Exchange as entered in the contest configuration panel. Can optionally take a string function instead of formatting arguments within curly brackets. E.g. <tt><nowiki>EXCHANGE{FX=$FIELDVALUE.Substring(0,4)}</nowiki></tt> Breaks up slashed entries.
| <tt>{F=L,6, }</tt>
|-
| <tt>FREQ</tt>
| Frequency in kilohertz.
| <tt>{F=R,6, }</tt>
|-
| <tt>FREQMHZ</tt>
| Frequency in Megahertz.
| <tt>{F=R,6, }</tt>
|-
| <tt>GRID</tt>
| Grid locator as entered in the contest configuration panel.
| <tt>{F=L,6, }</tt>
|-
| <tt>GRID4</tt>
| First four positions of the grid locator entered in the contest configuration panel.
| <tt>{F=L,6, }</tt>
|-
| <tt>MODE</tt>
| QSO mode with Cabrillo coding.
| <tt>{F=L,2, }</tt>
|-
| <tt>MYCALL</tt>
| Own call as entered in the contest configuration panel.
| <tt>{F=L,13, }</tt>
|-
| <tt>MYCQZONE</tt>
| Own CQ zone as entered in the contest configuration panel.
| <tt>{F=L,2,0,6}</tt>
|-
| <tt>MYDXCC</tt>
| Own DXCC prefix as entered in the contest configuration panel.
| <tt>{F=L,6, }</tt>
|-
| <tt>MYITUZONE</tt>
| Own ITU zone as entered in the contest configuration panel.
| <tt>{F=L,2,0,6}</tt>
|-
| <tt>NOTHING</tt>
| An empty string. Add a trailing asterisk for literally nothing.
| <tt>{F=L,0, }</tt>
|-
| <tt>NR</tt>
| Own serial number for the QSO.
| <tt>{F=R,3,0,6}</tt>
|-
| <tt>OPNAME</tt>
| Operator name as entered in the contest configuration panel.
| <tt>{F=L,10, }</tt>
|-
| <tt>PERIOD</tt>
| Contest period.
| <tt>{F=L,2, }</tt>
|-
| <tt>POWER</tt>
| Station power string as entered in the contest configuration panel.
| <tt>{F=L,6, }</tt>
|-
| <tt>PREV_RCVD</tt>
| First element in previously received exchange.
| <tt>{F=L,3,0}</tt>
|-
| <tt>PREV_RECINFO</tt>
| Second element in previously received exchange.
| <tt>{F=L,3,0}</tt>
|-
| <tt>PREV_RECINFO2</tt>
| Third element in previously received exchange.
| <tt>{F=L,3,0}</tt>
|-
| <tt>PREV_RECINFO3</tt>
| Fourth element in previously received exchange.
| <tt>{F=L,3,0}</tt>
|-
| <tt>PTS</tt>
| Points of QSO.
| <tt>{F=R,3,0}</tt>
|-
| <tt>RCVD1</tt>
| Received RST.
| <tt>{F=L,3, }</tt>
|-
| <tt>RCVD2</tt>
| First element in received exchange without RST. Can optionally take a string function instead of formatting arguments within curly brackets. E.g., <tt><nowiki>RCVD2{FX=$FIELDVALUE.Substring(0,4)}</nowiki></tt>
| <tt>{F=L,6, }</tt>
|-
| <tt>RECINFO</tt>
| Second element of received exchange. Can optionally take a string function instead of formatting arguments within curly brackets. E.g., <tt><nowiki>RECINFO{FX=$FIELDVALUE.Substring(0,4)}</nowiki></tt>
| <tt>{F=L,5, }</tt>
|-
| <tt>RECINFO2</tt>
| Third element of received exchange. Can take optionally a string function instead of formatting arguments within curly brackets. E.g., <tt><nowiki>RECINFO2{FX=$FIELDVALUE.Substring(0,4)}</nowiki></tt>
| <tt>{F=L,5, }</tt>
|-
| <tt>RECINFO3</tt>
| Fourth element of received exchange. Can optionally take a string function instead of formatting arguments within curly brackets. E.g., <tt><nowiki>RECINFO3{FX=$FIELDVALUE.Substring(0,4)}</nowiki></tt>
| <tt>{F=L,5, }</tt>
|-
| <tt>SENT</tt>
| Sent RST.
| <tt>{F=L,3, }</tt>
|-
| <tt>SLASH</tt>
| The character '/'. Add trailing asterisk to remove separating space.
| <tt>{F=L,1, }</tt>
|-
| <tt>STATE</tt>
| State or province as entered in the contest configuration panel.
| <tt>{F=L,5, }</tt>
|-
| <tt>STN</tt>
| Station. "0" for all stations except radio 2 in SO2R, the multiplier station in Multi/Single, and Run2 in Multi/Two which all are "1". '''Important:''' It is a good idea to wrap STN in parentheses to make it optional at import. Some loggers only include it for certain categories.
| <tt>{F=L,2, }</tt>
|-
| <tt>TIME</tt>
| Time of QSO. Format HHMM.
| <tt>{F=L,4, }</tt>
|-
| <tt>'</tt>
| A literal. E.g., <tt>'ABC{F=L,6,}</tt> means "ABC ". Add * after the literal (<tt>'ABC*</tt>) avoid a trailing space.
| <tt>{F=L,6, }</tt>
|-
|}

===CABRILLO_LINE formatting and conditionals===

<tt>CABRILLO_LINE</tt> formatting information is contained within curly brackets with the following syntax: 

<tt>{''F=AL'',''PS'',''PC''(,''TS'')}</tt>

: ''F='': Formatting flag
: ''AL'': Alignment, can be ''L'' (for left) or ''R'' (for right)
: ''PS'': Padded size. Total size of text including character padding.
: ''PC'': Character used for padding. E.g., 0 for serial numbers.
: ''TS'': Total size of field. Space padding to the right is used to reach this size. Optional.

Example: <tt>RCVD2{F=R,3,0,4}</tt> 

Means <tt>RCVD2</tt> field value will be aligned right, to a length of 3 characters. The "0" character is 
used to pad to the specified length. Total size will be 4 characters (padding with spaces to reach 4). 
This means that if <tt>RCVD2</tt> field value is "1", it will be formatted as " 001" in the Cabrillo QSO line.

Regardless if total size is specified or not, each field will always be surrounded by spaces.

For some keys it is possible to replace the formatting information with a string operation, using an <tt>FX=</tt> 
syntax and the <tt>$FIELDVALUE</tt> keyword to represent a string containing the field's characters.

<tt>CABRILLO_LINE</tt> also supports conditional formatting using a <tt>*RGX:</tt> syntax.

Example: <tt><nowiki>*RGX:SOURCE->DXCC:^(DL|OE)$>>EXCHANGE{F=L,6, }/NR{F=R,3,0,6};</nowiki></tt> 

means the content of the Exchange box in the contest configuration panel station for German and Austrian 
stations, otherwise a three position serial number. Both of total length 6.

per-own-DXCC conditional formatting is also supporting using a <tt>*NN></tt> syntax

Example: <tt><nowiki>*DL>EXCHANGE{F=L,6, }/NR{F=R,3,0,6};</nowiki></tt> 

means the same as the above example, but only for German stations. This conditional can 
also be repeated, to cover several DXCC entities.

===CABRILLO_QTC_LINE keywords===

{|class="wikitable"
|+style="text-align:Left;"|
| '''Key'''
| '''Content'''
| '''Format'''
|-
| <tt>FREQ</tt>
| Frequency in kilohertz
| 6 positions, right adjusted
|-
| <tt>MODE</tt>
| Mode when receiving QTC
| 3 positions, left adjusted
|-
| <tt>DATE</tt>
| Date QTC exchanged
| 12 positions
|-
| <tt>TIME</tt>
| Time QTC exchanged
| 4 positions
|-
| <tt>RCVDBY</tt>
| Call of receiving station
| 13 positions, left adjusted
|-
| <tt>GRNUM</tt>
| Group number of QTC
| 10 positions, left adjusted
|-
| <tt>SENTBY</tt>
| Call of sending station
| 13 positions, left adjusted
|-
| <tt>QTCTIME</tt>
| Time in QTC line
| 4 positions
|-
| <tt>QTCCALL</tt>
| Call in QTC line
| 13 positions, left adjusted
|-
| <tt>QTCSERIAL</tt>
| Serial in QTC line
| 3 positions, right adjusted
|-
|}

===Configuration keys' relation to Cabrillo export===

{|class="wikitable"
|+style="text-align:Left;"|Default relation between contest category configuration and Cabrillo export 
!'''Key type'''
!'''DXLog Key'''
!'''Cabrillo key'''
!colspan="6"|'''Default values'''
|-
| Configuration
| CATEGORIES
|
| Single operator, assisted
| Single operator
| Multi-operator, single transmitter
| Multi-operator, two transmitter
| Multi-operator, multi-transmitter
| Checklog
|-
| Cabrillo
| CABRILLO_OPERATOR
| CATEGORY-OPERATOR
| style="white-space: nowrap;" | SINGLE-OP
| style="white-space: nowrap;" | SINGLE-OP
| MULTI-OP
| MULTI-OP
| MULTI-OP
| CHECKLOG
|-
| Cabrillo
| CABRILLO_TRANSMITTER
| CATEGORY-TRANSMITTER
| ONE
| ONE
| ONE
| TWO
| UNLIMITED
| UNLIMITED
|-
| Cabrillo
| CABRILLO_ASSISTED
| CATEGORY-ASSISTED
| ASSISTED
| style="white-space: nowrap;" | NON-ASSISTED
| ASSISTED
| ASSISTED
| ASSISTED
| ASSISTED
|-
| Cabrillo
| CABRILLO_BAND
| CATEGORY-BAND
| AUTO
| AUTO
| ALL
| ALL
| ALL
| ALL
|}

{|class="wikitable"
|+style="text-align:Left;"|Default relation between contest overlay configuration and Cabrillo export 
!'''Key type'''
!'''DXLog Key'''
!'''Cabrillo key'''
!colspan="5"|'''Default values'''
|-
| Configuration
| OVERLAY
|
| style="width:150px;"|<nowiki>---</nowiki>
| style="width:150px;"|School
| style="width:150px;"|Dxpedition
| style="width:150px;"|Headquarter
| style="width:150px;"|...
|-
| Cabrillo
| style="white-space: nowrap;" | CABRILLO_OVERLAY
| style="white-space: nowrap;" | CATEGORY-OVERLAY
| style="white-space: nowrap;" | Key omitted
| CLASSIC
| ROOKIE
| TB-WIRES
| ...
|}

{|class="wikitable"
|+style="text-align:Left;"|Default relation between contest power class configuration and Cabrillo export 
!'''Key type'''
!'''DXLog Key'''
!'''Cabrillo key'''
!colspan="5"|'''Default values'''
|-
| Configuration
| CLASS
|
| style="width:150px;"|High
| style="width:150px;"|Low
| style="width:150px;"|QRP
|-
| Cabrillo
| CABRILLO_POWER
| CATEGORY-POWER
| HIGH
| LOW
| QRP
|}

{|class="wikitable"
|+style="text-align:Left;"|Default relation between contest mode category and Cabrillo export 
!'''Key type'''
!'''DXLog Key'''
!'''Cabrillo key'''
!colspan="5" | '''Default values'''
|-
| Configuration
| CATEGORY_MODES
|
| style="width:170px;" | CW
| style="width:170px;" | SSB
| style="width:170px;" | Mixed
|-
| Cabrillo
| N/A
| CATEGORY-MODE
| CW
| SSB
| MIXED
|}

{|class="wikitable"
|+style="text-align:Left;"|CATEGORY_MODE to CATEGORY-MODE mapping
!'''Value of CATEGORY_MODE'''
!'''Resulting CATEGORY-MODE'''
|-
| Phon*
| SSB
|-
| SSB
| SSB
|-
| FM
| FM
|-
| AM
| AM
|-
| CW
| CW
|-
| RTTY*
| RTTY
|-
| FT*
| DIGI
|-
| Digi*
| DIGI
|-
| *PSK*
| BPSK
|-
| All others
| MIXED
|-

{|class="wikitable"
|+style="text-align:Left;"|Default relation between available contest QSO modes and Cabrillo export 
!'''Key type'''
!'''DXLog Key'''
!'''Cabrillo key'''
!colspan="5" | '''Default values'''
|-
| Configuration
| MODES
|
| style="width:150px;" | CW
| style="width:150px;" | SSB
|-
| Cabrillo
| CABRILLO_MODES
| style="width:150px;" | QSO
| CW
| PH
|}

{|class="wikitable"
|+style="text-align:Left;"|Default relation between contest band category and Cabrillo export 
!'''Key type'''
!'''DXLog Key'''
!'''Cabrillo key'''
!colspan="6" | '''Default values'''
|-
| Configuration
| BANDS
| style="width:130px;" |
| style="width:130px;" | 160
| style="width:130px;" | 80
| style="width:130px;" | 40
| style="width:130px;" | 20
| style="width:130px;" | 15
| style="width:130px;" | 10
|-
| Cabrillo
| style="width:130px;" | N/A
| style="white-space: nowrap;" | CATEGORY-BAND
|colspan="7" | Value is determined automatically for single operator entries. For multi-operator entries it is always ALL.
|}

=== De-facto standard Cabrillo QSO line ===

[[image:cabrilloqsocolumns.png]]

{|class="wikitable"
|+style="text-align:Left;"| De-facto standard Cabrillo mode codes
| '''Cabrillo'''
| '''Mode'''
|-
| AM
| AMTOR
|-
| AX
| Packet AX.25
|-
| CO
| Contestia
|-
| CW
| CW
|-
| DO
| Domino
|-
| FM
| FM
|-
| HE
| Hellschreiber
|-
| MF
| MFSK16
|-
| OL
| Olivia
|-
| PH
| SSB, AM
|-
| PM
| PSK63
|-
| PO
| PSK125
|-
| PS
| PSK31
|-
| PT
| PACTOR
|-
| RM
| RTTYM
|-
| RY
| RTTY
|-
| TH
| THROB
|-
| TV
| SSTV
|-
|}

==Band and mode keys==

{|class="wikitable"
|+style="text-align:Left;"|
| '''BANDS'''
| A semicolon-separated list of allowed bands for the contest. Valid band names are: 2190, 630, 560, 160, 80, 60, 40, 30, 20, 17, 15, 12, 10, 50, 70, 144, 222, 432, 902, 1296, 2300, 3400, 5650, 10G, and 24G.
| Default value: 160;80;40;20;15;10
|-
| '''MODES'''
| A semicolon-separated list of modes allowed in the contest. Not to be confused with CATEGORY_MODES.
| Default value: CW;SSB
|-
| '''EDI_BANDS'''
| A semicolon-separated list of EDI values for bands specified in BANDS key. Must contain same number of entries as BANDS key. Used for generating EDI log files for VHF/UHF/SHF contests in IARU Region I. Valid values are: 28 MHz, 50 MHz, 70 MHz, 144 MHz, 432 MHz, 1,3 GHz, 2,3 GHz, 3,4 GHz, 5,7 GHz, 10 GHz, 24 GHz, 47 GHz, 76 GHz, 120 GHz, 144 GHz, and 248 GHz. Note the space between the number and the frequency multiplier and that commma is used as decimal separator. '''Very important: To support EDI export the <tt>SCORE</tt> key must contain BAND.'''
| No default value and if not set, EDI export is disabled.
|-
| '''DISPLAY_MODE_GROUPING'''
| Formatting of display of modes in check multiplier window. Should always be used if <tt>DOUBLE_QSO_MODE_CHECK=PER_MODE_GROUP</tt> is used. Syntax: <tt>DISPLAY_MODE_GROUPING=modename1:mode1+mode2;modename2:mode3+mode4</tt> Tip: An emtpy mode name can be used to avoid showing modes with per band multipliers.
| No default value
|}

==QSO entry field definition keys==

{|class="wikitable"
|+style="text-align:Left;"|These keys are used to control the layout and behavior of QSO entry fields. The keys set the visibility, length, labels, checking procedures etc. for each of the fields which the user can enter data or display for any QSO.
| '''FIELD_AZ_VISIBLE'''
| Controls the visibility of the Azimuth field. Mostly used on VHF/UHF/SHF to get the azimuth angle from a gridsquare. Valid values are YES and NO.
| Default value: NO
|-
| '''FIELD_CALLSIGN_GRID_CHECK'''
| If YES, an entry in the log callsign field be checked for a gridsquare entry. If a gridsquare closer than 4000km away is found, the callsign field value be copied to the gridsquare entry field and the azimuth angle be calculated and shown. Recommended for VHF/UHF contests where you turn your antenna a lot. Valid values are YES and NO.
| Default value: NO
|-
| '''FIELD_DISPLAYED_EXCHANGE'''
| Controls which of several exchange elements is displayed in the bandmap. With -1, the first static exchange element is displayed. With 0, 1, 2, or 3, Rcvd, Recinfo, Recinfo2, or Recinfo3 is displayed, respectively. Valid values are -1, 0, 1, 2, or 3.
| Default value: -1
|-
| '''FIELD_MODE_VISIBLE'''
| If YES, or MIXED and contest mode category name contains "mixed" or "digi", overrides menu option <code><nowiki>Options|Log|Always show mode in QSO lines</nowiki></code> and makes the mode column always visible in the log. If NO, has no effect. Valid values are YES, NO, and MIXED.
| Default value: NO
|-
| '''FIELD_MODE_NAME'''
| Heading for mode column.
| Default value: "Mode"
|-
| '''FIELD_MULT_NAME'''
| Heading for multiplier column.
| Default value: "Mult"
|-
| '''FIELD_MULT_VISIBLE'''
| If MULT field is visible on the screen. Valid values are YES and NO.
| Default value: YES
|-
| '''FIELD_MULT_MAX_LENGTH'''
| Width of MULT column.
| Default value: 5
|-
| '''FIELD_NR_VISIBLE'''
| If sent QSO SERIAL NUMBER is visible on the QSO entry line. Valid values are YES and NO.
| Default value: NO
|-
| '''FIELD_NR_HIDDEN_DXCC'''
| Semicolon separated list of DXCC. If our own DXCC is on this list, sent serial number field be hidden. Useful for contests where some stations are sending a serial number exchange and other stations are sending other data (for example a local province).
| Default is to hide none
|-
| '''FIELD_NR_HIDDEN_RGX'''
| Semicolon separated list of regular expressions. If one of the expressions are valid, sent serial number field be hidden. Useful for contests where some stations are sending a serial number exchange and other stations are sending other data (for example a local province).
| No default value
|-
| '''FIELD_PERIOD_VISIBLE'''
| If PERIOD number column is visible. Valid values: YES and NO.
| Default value: NO
|-
| '''FIELD_PERIOD_NAME'''
| Heading for PERIOD number column.
| Default value: "P"
|-
| '''FIELD_PTS_VISIBLE'''
| If POINTS column is visible. Valid values: YES and NO.
| Default value: YES
|-
| '''FIELD_PTS_NAME'''
| Heading for POINTS column. Width of column scales with string.
| Default value: "Pts"
|-
| '''FIELD_RCVD_CHECK_FORMAT_FX'''
| C# expression to reformat entered value in the field before further validity checking. The value in the field is represented as $FIELDVALUE. Example: <tt>FIELD_RCVD_CHECK_FORMAT_FX=$FIELDVALUE.Substring(0,2)+$FIELDVALUE.Substring(2).TrimStart('0')</tt> reshape RCVD by taking the first two characters and then remove any leading zeroes in the remainder before further validity or multiplier checking.
| Default value: $FIELDVALUE
|-
| '''FIELD_RECINFO_CHECK_FORMAT_FX''' '''FIELD_RECINFO2_CHECK_FORMAT_FX''' '''FIELD_RECINFO3_CHECK_FORMAT_FX'''
| One or several, semicolon separated, regular expressions to conditionally reformat the entered value in the field before further validity checking. The regular expression and the formatting expression are separated by ">>" as in CABRILLO_LINE. The entered value is represented as $FIELDVALUE. Example: <tt><nowiki>FIELD_RECINFO_CHECK_FORMAT_FX=!DEST->DXCC:^YO$>>'.'+$FIELDVALUE</nowiki></tt> add a period before the second part of the exchange for all stations that are not from Romania. <tt><nowiki>FIELD_RECINFO_CHECK_FORMAT_FX=!DEST->DXCC:^K$|^KL$|^KH6$|^VE$>>""</nowiki></tt> ignore any value in the second exchange field for all stations not from US, Hawaii, Alaska, or Canada.
| Default value: ALL>>$FIELDVALUE
|-
| '''FIELD_RCVD_COPY''' '''FIELD_RECINFO_COPY''' '''FIELD_RECINFO2_COPY''' '''FIELD_RECINFO3_COPY'''
| If the field's value is automatically copied from previous QSO with same station. Also controls if the exchange is shown with callsign in bandmap when <code><nowiki>Display options|Exchange</nowiki></code> is selected. Valid values: YES and NO.
| Default value: NO
|-
| '''FIELD_RCVD_COPY_EXC_DXCC''' '''FIELD_RECINFO_COPY_EXC_DXCC'''
| Semicolon separated list DXCC entities for which RCVD/RECINFO is copied from earlier QSO in spite of FIELD_RCVD_COPY/FIELD_RECINFO_COPY=NO. Useful in case only some DXCC have a fixed exchange in the contest.
| Default value: NONE
|-
| '''FIELD_RCVD_COPY_EXC_RGX''' '''FIELD_RECINFO_COPY_EXC_RGX'''
| Semicolon separated list of regular expressions. For QSO where any of the conditions are true, the content of the field be copied from earlier QSO in spite of FIELD_RCVD_COPY/FIELD_RECINFO_COPY=NO. Useful if only certain types of exchanges are fixed for stations in contest.
| No default value
|-
| '''FIELD_RCVD_COPY_FX'''
| C# expression used to determine value to be copied from earlier QSO. The value of the field is $FIELDVALUE. For example: <tt>FIELD_RCVD_COPY_FX=$FIELDVALUE.Substring(0,6)</tt> copy the first six characters from the RCVD field from the previous QSO with the same station.
| Default value: $FIELDVALUE
|-
| '''FIELD_RCVD_DEFAULT_VALUE'''
| Value to be used in as prefill if RCVD field is empty. Valid values are: CQZONE, ITUZONE, CONT, or any string, which be used verbatim.
| No default value
|-
| '''FIELD_RCVD_EXC_CHECK_DXCC'''
| List of destination DXCC countries separated by ":" (or keyword ALL for all) for which multiplier list validity checking is enforced. E.g. <tt>FIELD_RCVD_EXC_CHECK_DXCC=K:KL:KH6:VE:XE;CUSTOM_MULT_LIST</tt> Note that this key only applies to <tt>FIELD_RCVD_TYPE=MULT</tt>. Also note that this key does not override <tt>FIELD_RCVD_RGX_CHECK</tt>, so if used, this key needs to accept all possible values of RCVD. E.g. <tt><nowiki>FIELD_RCVD_RGX_CHECK=DEST->RCVD:^[0-8][0-9]?$|^90$;DEST->RCVD:CUSTOM_MULT_LIST</nowiki></tt> '''Important:''' There is no such key for <tt>RECINFO</tt> etc. since validity checking is automatic for those of MULT type.
| No default value
|-
| '''FIELD_RCVD_FORMAT_FX''' '''FIELD_RECINFO_FORMAT_FX''' '''FIELD_RECINFO2_FORMAT_FX''' '''FIELD_RECINFO3_FORMAT_FX'''
| C# expression used to format entered value before saving.
| No default value
|-
| '''FIELD_RCVD_FX_CHECK''' '''FIELD_RECINFO_FX_CHECK''' '''FIELD_RECINFO2_FX_CHECK''' '''FIELD_RECINFO3_FX_CHECK'''
| Boolean C# expression used to check if value entered in the field is valid. For example: <tt>FIELD_RCVD_FX_CHECK=Helpers.Between($FIELDVALUE,1,40)</tt> checks if RCVD is between 1 and 40.
| No default value
|-
| '''FIELD_RCVD_MANDATORY''' '''FIELD_RECINFO_MANDATORY''' '''FIELD_RECINFO2_MANDATORY''' '''FIELD_RECINFO3_MANDATORY'''
| If RCVD field entry is mandatory. Valid values are YES and NO.
| Default value: NO
|-
| '''FIELD_RCVD_MANDATORY_RGX_EXC''' '''FIELD_RECINFO_MANDATORY_RGX_EXC''' '''FIELD_RECINFO2_MANDATORY_RGX_EXC''' '''FIELD_RECINFO3_MANDATORY_RGX_EXC'''
| Defines exceptions from mandating rule via a regular expression. For example: <tt><nowiki>FIELD_RCVD_MANDATORY_RGX_EXC=!DEST->DXCC:^(G|GD|GI|GJ|GM|GU|GW)$</nowiki></tt> means RCVD is not mandatory for non-UK stations. You can only have one exception per entry field.
| No default value
|-
| '''FIELD_RCVD_MAX_LENGTH'''
| Maximum number of characters accepted in the field.
| Default value: 10
|-
| '''FIELD_RECINFO_MAX_LENGTH''' '''FIELD_RECINFO2_MAX_LENGTH''' '''FIELD_RECINFO3_MAX_LENGTH'''
| Maximum number of characters accepted in the field.
| Default value: 6
|-
| '''FIELD_RCVD_MIN_LENGTH''' '''FIELD_RECINFO_MIN_LENGTH''' '''FIELD_RECINFO2_MIN_LENGTH''' '''FIELD_RECINFO3_MIN_LENGTH'''
| Minimum number of characters accepted in the field.
| Default value: 0
|-
| '''FIELD_RCVD_NUMERIC''' '''FIELD_RECINFO_NUMERIC''' '''FIELD_RECINFO2_NUMERIC''' '''FIELD_RECINFO3_NUMERIC'''
| Controls if the field accepts only numeric characters. Valid values are YES and NO.
| Default value: NO
|-
| '''FIELD_RCVD_NAME'''
| Column heading for RCVD field.
| Default value: Rcvd
|-
| '''FIELD_RCVD_SLASH_ALLOWED''' '''FIELD_RECINFO_SLASH_ALLOWED''' '''FIELD_RECINFO2_SLASH_ALLOWED''' '''FIELD_RECINFO3_SLASH_ALLOWED'''
| Controls if the field accepts a slash "/" character. Valid values are YES and NO.
| Default value: NO
|-
| '''FIELD_RCVD_RGX_CHECK'''
| Semicolon separated list of logical expressions for entry validity checking. For contests with more than one type of exchange (e.g. grid and serial number or oblast and grid), more than one rule can be listed, separated by semicolon. The check is then done against the rules combined with logical OR, i.e. if any of the rules checks OK, the entry is approved.
| No default value
|-
| '''FIELD_RECINFO_RGX_CHECK''' '''FIELD_RECINFO2_RGX_CHECK''' '''FIELD_RECINFO3_RGX_CHECK'''
| A single regular expression for entry validity checking.
| No default value
|-
| '''FIELD_RCVD_TYPE'''
| Defines data type of the field. Valid values are: GRID, GRID4, GRID6, CONT, NR, CUSTOM (any text), MULT (a listed keyword, associated with <tt>MULT#_TYPE=CUSTOM</tt>), CQZONE, ITUZONE, and NAME. Note that there is no automatic validity checking for CUSTOM, CQZONE, NAME, and ITUZONE. Validity checking of MULT is enabled using the key <tt>FIELD_RCVD_EXC_CHECK_DXCC</tt>. This means a <tt>FIELD_RCVD_RGX_CHECK</tt> or key may be required. The type can also be per-DXCC using the syntax <tt>DXCC:regex=type1;!DXCC:regex=type2</tt> where regex is matched against the station's main DXCC prefix and can be e.g. <tt><nowiki>^(JA|JD/o|JD/m)$</nowiki></tt> '''Important:''' Since the types are used to determine e.g. ADIF export, only use NAME for a real name and only use NR for the exchange serial number.
| Default value: Empty
|-
| '''FIELD_RECINFO_TYPE''' '''FIELD_RECINFO2_TYPE''' '''FIELD_RECINFO3_TYPE'''
| Defines data type of the field. Valid values are: GRID, GRID4, GRID6, NR, CONT, CUSTOM, MULT, CQZONE, ITUZONE, and NAME. There is an automatic validity check on all types except CUSTOM and NAME. '''Important:''' Since the types are used to determine e.g. ADIF export, only use NAME for a real name and only use NR for the exchange serial number.
| Default value: Empty
|-
| '''FIELD_RCVD_GRID_CHECK'''
| If YES, entry in RCVD field be checked if it can be possible gridsquare entry. It it is gridsquare, then RCVD field value be moved to the RECINFO entry field and Azimuth be calculated and shown. Valid values are YES and NO.
| Default value: NO
|-
| '''FIELD_RECINFO_NAME''' '''FIELD_RECINFO2_NAME''' '''FIELD_RECINFO3_NAME'''
| Heading for field's column.
| Default value: Empty
|-
| '''FIELD_RECINFO_RGX_SEL_POS''' '''FIELD_RECINFO2_RGX_SEL_POS''' '''FIELD_RECINFO3_RGX_SEL_POS'''
| Filtering function for composite multipliers. Exact function is unclear.
| No default value
|-
| '''FIELD_RECINFO_VISIBLE''' '''FIELD_RECINFO2_VISIBLE''' '''FIELD_RECINFO3_VISIBLE'''
| Controls if the the field is visible. Valid values: YES, NO, HIDDEN, and READONLY.
| Default value: NO
|-
| '''FIELD_RST_3RD_LETTER'''
| Semicolon-separated list of allowed third characters apart from numbers. For example: <tt>FIELD_RST_3RD_LETTER=A;S</tt> allows 59A and 59S as reports.
| Default value: None
|-
| '''FIELD_RST_VISIBLE'''
| Controls visibility of RST field. Valid values are: YES and NO.
| Default value: YES
|-
| '''FIELD_SENT_VISIBLE'''
| Controls visibility of Sent field in log. Valid values are: YES and NO.
| Default value: YES
|-
|}

==Default message keys==

{|class="wikitable"
|+style="text-align:Left;"|Default messages for F-keys, Plus and Ins.
| '''Message'''
| '''Usage'''
| '''Default value'''
|-
| '''CW_MESSAGE_1'''
| Default F1 message for Run
| <nowiki>"CQ $MYCALL $MYCALL TEST"</nowiki>
|-
| '''CW_MESSAGE_2'''
| Default F2 message for Run
| "$RST $EXCHANGE"
|-
| '''CW_MESSAGE_3'''
| Default F3 message for Run
| "$EXCHANGE"
|-
| '''CW_MESSAGE_4'''
| Default F4 message for Run
| "$MYCALL"
|-
| '''CW_MESSAGE_5'''
| Default F5 message for Run
| "$LOGGEDCALL"
|-
| '''CW_MESSAGE_6'''
| Default F6 message for Run
| "AGN?"
|-
| '''CW_MESSAGE_7'''
| Default F7 message for Run
| "?"
|-
| '''CW_MESSAGE_INS'''
| Default Insert message for Run
| "$F2"
|-
| '''CW_MESSAGE_PLUS'''
| Default Plus message for Run
| "$CORRECT TU $CR $MYCALL"
|-
| '''SP_CW_MESSAGE_1'''
| Default F1 message for S&P
| "$MYCALL"
|-
| '''SP_CW_MESSAGE_2'''
| Default F2 message for S&P
| "$RST $EXCHANGE"
|-
| '''SP_CW_MESSAGE_3'''
| Default F3 message for S&P
| "$EXCHANGE"
|-
| '''SP_CW_MESSAGE_4'''
| Default F4 message for S&P
| "$MYCALL"
|-
| '''SP_CW_MESSAGE_5'''
| Default F5 message for S&P
| "$LOGGEDCALL"
|-
| '''SP_CW_MESSAGE_6'''
| Default F6 message for S&P
| "AGN?"
|-
| '''SP_CW_MESSAGE_7'''
| Default F7 message for S&P
| "?"
|-
| '''SP_CW_MESSAGE_INS'''
| Default Insert message for S&P
| "$F2$CR"
|-
| '''SP_CW_MESSAGE_PLUS'''
| Default Plus message for S&P
| "TU$CR"
|-
| '''CW_MESSAGE_EXCHANGE_FILTER'''
| Controls selection of alternative standard messages
|
|-
|}

Message definitions following the <tt>CW_MESSAGE_EXCHANGE_FILTER</tt> key will only be effective if regular expression after equal sign evaluates true for content in exchange entry box. Example: <tt>CW_MESSAGE_EXCHANGE_FILTER=^DX$</tt> means that messages below this line will be used for stations entering DX in the exchange entry box. '''Important:''' Only has effect for the first log created or when the Defaults button is clicked in the Standard messages panel. All subsequent logs for the same contest will inherit the messages from the previous log.

==Additional configuration keys==

=== DXCC related keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''DXCC_DB_TYPE'''
| This entry allows the use of a custom country file (for example, R150S.dat). If a custom country file is defined, the selection in <tt><nowiki>Option|Data files|Country files</nowiki></tt> will be ignored and the country file defined in the contest config file will be used. Valid values are: <tt>CUSTOM_CTY</tt> and <tt>CTY</tt>
|Default value is CTY which will use the data base set in the <tt><nowiki>Options|Data files|Country files</nowiki></tt> panel.
|-
| '''DXCC_DB_FILENAME'''
| Used to enable the use of an alternative country data base. Used in conjunction with the <tt>DXCC_DB_TYPE</tt> key to define the data file name. The file format is the same as the normal <tt>CTY.DAT</tt> file.
| Default value: <tt>CTY.DAT</tt>
|-
| '''DXCC_DB_USE_ARRL_LIST'''
| Controls the use of the ARRL country list instead of CQ/WAE country list. Valid values: YES and NO.
| Default value: NO
|}

=== Contest timing and period keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''MIN_OFF_TIME'''
| Minimum time in minutes without QSO to count as off time. C.f. OFF_TIME_ROUND_UP.
| style="white-space: nowrap;" | Default value: 30
|-
| '''OFF_TIME_ROUND_UP'''
| Off time is calculated based on time difference between QSO instead of minutes without QSO. YES means that QSO at e.g. 4:12 and 5:12 represents 60 minutes of off time. NO means that QSO at e.g. 4:12 and 5:13 represents 60 minutes of off time. Valid values: YES and NO.
| Default value: NO
|-
| '''CONTEST_LENGTH'''
| Duration of contest in minutes. Ignored for contests without periods.
| No default value
|-
| '''CONTEST_FIRST_HOUR'''
| Time of day for start of contest in UTC. Ignored for contests without periods. If the value is negative, DXLog will assume the contests starts a the beginning of the current hour. Valid formats: -1, H, HH, HMM, and HHMM.
| No default value
|-
| '''PERIOD'''
| Whether the contest has periods. Valid values: ON and OFF.
| style="white-space: nowrap;" | Default value: OFF
|-
| '''PERIOD_LENGTH'''
| The length of each contest period in minutes. Valid values: Any integer.
| Default value: 0
|-
| '''PERIOD_AUTOSWITCH'''
| If the next period should start automatically. '''Important: Does not work if contests stretches past midnight UTC.''' Valid values: YES and NO.
| Default value: NO
|-
| '''PERIOD_NUMBER'''
| Number of periods in contest. CALC_FROM_TIME means duration divided by period length. Valid values: CALC_FROM_TIME or any integer. '''Important:''' When CALC_FROM_TIME is used, it must be preceded by CONTEST_LENGTH and PERIOD_LENGTH.
| Default value: 0
|-
| '''PERIOD_MODES'''
| Optional, semicolon-separated list of modes for each period in the contest. Must have the same number of items as number of periods. Valid values: Mode acronyms supported by DXLog.
| No default value
|-
|}

=== Database, prefill, and check keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''DB_FILE''' or '''DB_FILE1''' '''DB_FILE2''' '''DB_FILE3''' '''DB_FILE4''' '''DB_FILE5'''
| File name of prefill data base. '''Important: File name casing must be correct for online update to work.''' For file format etc., see the [[Menu_Options#Prefill_database_settings|Prefill database settings]] section.
|
|-
| '''DB_FILE_TYPE''' or '''DB_FILE1_TYPE''' '''DB_FILE2_TYPE''' '''DB_FILE3_TYPE''' '''DB_FILE4_TYPE''' '''DB_FILE5_TYPE'''
| Extension of data base file.
| style="white-space: nowrap;" | Default value: TXT
|-
| '''DB_FILE_COL_RCVD''' or '''DB_FILE1_COL_RCVD''' '''DB_FILE2_COL_RCVD''' '''DB_FILE3_COL_RCVD''' '''DB_FILE4_COL_RCVD''' '''DB_FILE5_COL_RCVD'''
| Column number of RCVD field in data base file. '''Important: At least one DB_FILE_COL* statement must be included for each data base file.''' '''Important: Since look-up for RCVD is enabled by default, it needs to be actively disabled if not wanted. Set it to -1 to disable undesired look-up. '''
|
|-
| '''DB_FILE_COL_RECINFO''' or '''DB_FILE1_COL_RECINFO''' '''DB_FILE2_COL_RECINFO''' '''DB_FILE3_COL_RECINFO''' '''DB_FILE4_COL_RECINFO''' '''DB_FILE5_COL_RECINFO'''
| Column number of RECINFO field in data base file.
|
|-
| '''DB_FILE_COL_RECINFO2''' or '''DB_FILE1_COL_RECINFO2''' '''DB_FILE2_COL_RECINFO2''' '''DB_FILE3_COL_RECINFO2''' '''DB_FILE4_COL_RECINFO2''' '''DB_FILE5_COL_RECINFO2'''
| Column number of RECINFO2 field in data base file.
|
|-
| '''DB_FILE_COL_RECINFO3''' or '''DB_FILE1_COL_RECINFO3''' '''DB_FILE2_COL_RECINFO3''' '''DB_FILE3_COL_RECINFO3''' '''DB_FILE4_COL_RECINFO3''' '''DB_FILE5_COL_RECINFO3'''
| Column number of RECINFO3 field in data base file.
|
|-
| '''DB_FILE_FILL_FORMAT''' or '''DB_FILE1_FILL_FORMAT''' '''DB_FILE2_FILL_FORMAT''' '''DB_FILE3_FILL_FORMAT''' '''DB_FILE4_FILL_FORMAT''' '''DB_FILE5_FILL_FORMAT'''
| C# <code>string.Format</code> expression defining how prefill from data base file will be used. Example: <tt>/{0}</tt> will precede prefill with a slash. This function is often combined with the menu option to use INSERT mode in the RCVD field.
|
|-
| '''RGX_GUESS_DB'''
| Regular expression "rule base" for guessing exchange of unworked stations. Syntax is <tt>RGX_GUESS_DB=Field;DXCC Regex;Callsign Regex2;Filename[;Result regex]</tt>. A look-up is done for stations fulfilling at least one of the regular expressions. An empty regular expression or "ALL" matches everything and "NONE" never matches. If the Result regex is used, the look-up only returns values that matches it. The syntax of the file is callsign regex=prefill, DXCC:regex=prefill, !DXCC:regex=prefill, CONT:regex=prefill, or !CONT:regex=prefill where "prefill" is either a literal string or <tt>$DXCC</tt>, <tt>$CONT</tt>, <tt>$ITUZONE</tt>, or <tt>$CQZONE</tt>. The file is parsed from top to bottom and the first match is used.
|
|-
| '''DXC_COMMENT_EXTRACT'''
| This entry is used to extract exchange or multiplier information from DX cluster comments. For example, the line: <tt><nowiki>DXC_COMMENT_EXTRACT=RECINFO;(AF|AN|AS|EU|NA|OC|SA)[ /\-\.]?\d{1,3};[ /\-\.]</nowiki></tt> will extract a typical IOTA designation such as AF-025 and insert it into the <tt>RECINFO</tt> prefill field for the spot. The first part of the configuration (before the ;) defines into which entry field the data should be placed. The second part of the configuration is a regular expression that defines the data that is to be matched. The third part defines which characters should be removed from the matched result. It is mandatory but can be empty. A fourth part is optional. It is a regular expression and all comments matching it are ignored. This can, for instance, be used to ignore skimmer spots. '''Important''': All comments are converted to upper case before comparison.
|
|-
| '''CALLSIGN_EXTRACT'''
| This entry is used to extract exchange information from an entered or spotted callsign. For example, the line: <tt><nowiki>CALLSIGN_EXTRACT=RCVD;/(ABC|DEF|KIJ)$;[/]</nowiki></tt> will extract the string after the slash into the RCVD field into the entry line or in the spot. The first part of the configuration (before the ;) defines into which entry field the data should be placed. The second part of the configuration is a regular expression that defines the data that is to be matched. The third part defines which characters should be removed from the matched result. It is mandatory but can be empty.
|
|-
| '''SCP_DATABASE_DISABLE'''
| Disable file-based prefill and check partials database. (for e.g., WRTC). Valid values are: YES and NO or a semicolon separated list of YES or NO with the same number of elements as defined contest categories.
| Default value: NO
|-
| '''DB_SCP_FROM_EXCHANGE'''
| Enables reverse look-up. Searches for all instances of either RCVD or RECINFO in first and second column of all data base files. Search is triggered when pressing space and all entry fields are empty except either RCVD or RECINFO. Search hits are displayed in Check Partials window.
| Default value: NO
|-
|}

=== QSO exchange and numbering keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''INITIAL_SERIAL_NUMBER'''
| Starting value of sent serial number.
| Default value: 1
|-
| '''QSO_NUMBER'''
| QSO numbering principle. Valid values: ALL, PER_MODE, PER_BAND, PER_PERIOD, PER_BAND_MODE, PER_PERIOD_MODE. ALL means chronological numbering.
| Default value: ALL
|-
| '''QSO_NUMBER_CATEGORY'''
| Semicolon-separated list of numbering principles for each contest category. Must contain the same number of elements as contest categories. Valid values: ALL, PER_MODE, PER_BAND, PER_PERIOD, PER_BAND_MODE, PER_PERIOD_MODE.
| If absent, the value of QSO_NUMBER is used.
|-
| '''FIRST_PREV_RCVD'''
| Initial return value of macro $PREV_RCVD. Any string is allowed but also the keyword <tt>EXCHANGE</tt>
| style="white-space: nowrap;" | Default value: "000"
|-
| '''FIRST_PREV_RECINFO'''
| Initial return value of macro $PREV_RECINFO. Any string is allowed but also the keyword <tt>EXCHANGE</tt>
| Default value: "000"
|-
| '''FIRST_PREV_RECINFO2'''
| Initial return value of macro $PREV_RECINFO2. Any string is allowed but also the keyword <tt>EXCHANGE</tt>
| Default value: "000"
|-
| '''FIRST_PREV_RECINFO3'''
| Initial return value of macro $PREV_RECINFO3. Any string is allowed but also the keyword <tt>EXCHANGE</tt>
| Default value: "000"
|-
| '''SLASH_MULTIPLE_QSOS'''
| Controls whether slashed ("/") multipliers in sent and received exchanges are scored as separate QSO.
| Default value: NO
|-
|}

=== Duplicate QSO keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''DOUBLE_QSO'''
| The definition of a dupe. Valid values: PER_PERIOD, PER_BAND, PER_MODE, PER_PERIOD_BAND, PER_PERIOD_MODE, PER_BAND_MODE, PER_BAND_MODE_RECINFO, PER_BAND_MODE_RCVD, PER_BAND_MODE_RCVD_DAY, PER_PERIOD_BAND_MODE, PER_MINUTE_DIFFERENCE, PER_BAND_DAY '''Important: ALL is not a valid value.'''
| PER_BAND
|-
| '''DOUBLE_QSO_MINUTE_DIFFERENCE'''
| Minimum time difference in QSO time to not be counted as a dupe. Used in conjunction with DOUBLE_QSO=PER_MINUTE_DIFFERENCE.
| Default value: 0
|-
| '''DOUBLE_QSO_MODE_CHECK'''
| Definition of dupe principle when it comes to mode. Valid values: PER_MODE, PER_CABRILLO_MODE, and PER_MODE_GROUP. '''Important''': When not using PER_MODE, only use CW, Phone, Digital, and Mixed for CATEGORY_MODES values.
| style="white-space: nowrap;" | Default value: PER_MODE
|-
| '''DOUBLE_QSO_RULE_DURATION'''
| Expiration time of dupe QSO rule. Cannot be used together with DOUBLE_QSO=PER_MINUTE_DIFFERENCE or MIN_VALID_QSO_DIFFERENCE.
| Default value: 0
|-
| '''MIN_VALID_QSO_DIFFERENCE'''
| Minimum allowed time between QSO with the same station (on e.g., another mode). Once this time has passed, the regular dupe rules apply. Cannot be used together with DOUBLE_QSO=PER_MINUTE_DIFFERENCE or DOUBLE_QSO_RULE_DURATION.
| Default value: 0
|-
| '''MODE_GROUP'''
| Semicolon-separated list of mode group names. Used as an alternative to CABRILLO_MODES to group modes together for special dupe rules. One list entry per MODES mode entry. Valid group names are CW, SSB, FM, PH, and DG.
| No default value
|-
|}

=== Multiplier keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''MULT_SUM'''
| Summing method for multipliers. Valid values: NO, ALL, PER_BAND, and PER_PERIOD.
| Default value: ALL
|-
| '''OWN_MULT_VALID'''
| Controls if own multiplier is valid. '''Important:''' Controls the validity of ALL own multipliers but does not consider calculated or derived multipliers, e.g. DXCC or WPX. This means that for the NO option to work, the own multiplier must be specified in the Exchange field in the contest configuration window and only this multiplier will not count.
| Default value: NO
|-
| '''CUSTOM_MULT_LENGTH'''
| Length of an enumerated numeric multiplier. If number is shorter, it is left padded with zeroes. Used with enumerated multipliers, e.g. "=1-1999".
| Default value: 0
|-
| '''CONTINENT_LIST'''
| Custom, semicolon-separated continent list. Syntax is: <tt>CONTINENT_LIST=</tt>''continent1;continent2;continent3''
| Default value: EU;NA;SA;AS;AF;OC
|-
| '''MULT1_CONT_LIST''' '''MULT2_CONT_LIST''' '''MULT3_CONT_LIST'''
| Custom, semicolon-separated continent list. Syntax is: <tt>MULT1_CONT_LIST=</tt>''continent1;continent2;continent3''
| Default value: EU;NA;SA;AS;AF;OC
|-
| '''MULT1_TYPE''' '''MULT2_TYPE''' '''MULT3_TYPE'''
| Multiplier type. Can be <tt>CALLSIGN, DXCC, CQZONE, WPX, CUSTOM, HQ, NUM, FIELD, LASTLETTER, LETTER1</tt>, or <tt>FX</tt>. <tt>FX</tt> is a calculated multiplier and requires an <tt>MULT#_FX</tt> key. <tt>CUSTOM</tt> requires an explicit multiplier list. For contests with more than one multiplier, the use of LIVESCORE_MULT may be necessary for correct reporting. Check [https://contestonlinescore.com/settings/ here] for valid live score multiplier attributes and below for more details about how to use the types.
| Default value: None
|-
| '''MULT1_FX''' '''MULT2_FX''' '''MULT3_FX'''
| A C# expression used to create the effective value of an <tt>FX</tt> type multiplier. The entered string is available in the object <tt>$FIELDVALUE</tt>. For example <tt>MULT1_FX=$FIELDVALUE.Substring(0,$FIELDVALUE.IndexOf('/'))</tt> will make the characters before the slash the actual multiplier.
|
|-
| '''MULT1_COUNT''' '''MULT2_COUNT''' '''MULT3_COUNT'''
| Counting method for <tt>MULT1, MULT2</tt>, and <tt>MULT3</tt>. Can be <tt>PER_BAND, PER_PERIOD, PER_MODE, PER_BAND_MODE, PER_PERIOD_MODE, PER_PERIOD_BAND, PER_PERIOD_BAND_MODE,</tt> or <tt>ALL</tt>. '''Important:''' Do not use e.g. <tt>PER_BAND</tt> for a single band contest or <tt>PER_MODE</tt> for a single mode contest.
| Default value: None
|-
| '''MULT1_ADD_DXCC''' '''MULT2_ADD_DXCC''' '''MULT3_ADD_DXCC'''
| Only used with multiplier type <tt>HQ</tt>. Adds an asterisk and the DXCC entities main prefix to the entered string. Can be reversed using the multiplier exception <tt>REMOVE_DXCC</tt>. Example: <tt>MULT2_EXCEPTION=DEST->RCVD:^R[1-3]$;REMOVE_DXCC</tt> means that HQ stations sending R1, R2, or R3 as exchange will not count for DXCC multipliers. Valid values: YES and NO.
| Default value: NO
|-
| '''MULT1_FIELD''' '''MULT2_FIELD''' '''MULT3_FIELD'''
| Source of the multiplier string. Valid values: <tt>RCVD, CALLSIGN, FROM_DXCC, FROM_WPX, RECINFO, RECINFO2, RECINFO3,<tt> and <tt>NONE</tt>.
| Default value: None
|-
| '''MULT1_DISPLAY''' '''MULT2_DISPLAY''' '''MULT3_DISPLAY'''
| Text to show in MULT column. Syntax: MULT1_DISPLAY=''regex;string''. The ''regex'' can be omitted. Example: <tt><nowiki>MULT1_DISPLAY=DEST->DXCC:^(K|KL|KH6)$;S</nowiki></tt> Example: <tt>MULT1_DISPLAY=FN</tt>
| Default value: None
|-
| '''MULT1_BAND_BONUS''' '''MULT2_BAND_BONUS''' '''MULT3_BAND_BONUS'''
| Per band multiplier scaling factor. Syntax <tt>MULT1_BAND_BONUS=<tt>''band;scaling''. Example: <tt>MULT1_BAND_BONUS=80;2.0</tt> doubles the multiplier count for the 80m band.
| Default value: 1
|-
| '''MULT1_BONUS''' '''MULT2_BONUS''' '''MULT3_BONUS'''
| Bonus score for a defined achievement in V/U/SHF contests with EDI log submission. Example: With country defined as a "multiplier" number one, <tt>MULT1_BONUS=100</tt> will add 100 points to the total score for each new country worked. Affects the EDI keys <tt>CWWLs</tt>, <tt>CExcs</tt>, and <tt>CDXCs</tt>. '''Has no effect on on-screen scoring or Cabrillo export.'''
| Default value: 0
|-
| '''MULT1_EXCEPTION''' '''MULT2_EXCEPTION''' '''MULT3_EXCEPTION'''
| Exception from the general rule for the multiplier. Syntax: <tt>MULT1_EXCEPTION=boolean;multiplier definition</tt>. The boolean function can either be a regular expression (c.f. above) or <tt>FX()</tt> expression. Example: <tt><nowiki>MULT1_EXCEPTION=DEST->DXCC:^K$|^VE$;CUSTOM_MULT_LIST</nowiki></tt> will use the custom list (normally last in the contest definition file) to determine multipliers for US and Canadian stations. Example: <tt><nowiki>MULT1_EXCEPTION=FX("CONFIG->CALLSIGN"<>"K1DG");NONE</nowiki></tt> will not count this multiplier for anyone except Doug K1DG. However, a less roundabout way to achieve the same is <tt><nowiki>MULT1_EXCEPTION=!CONFIG->CALLSIGN:^K1DG$;NONE</nowiki></tt> For valid values, see table below.
|
|-
| '''MULT1_MULTIPLIER''' '''MULT2_MULTIPLIER''' '''MULT3_MULTIPLIER'''
| Multiplication factor for a selected value. Syntax ''value;factor''. For instance <tt>MULT1_MULTIPLIER=AZ;4</tt> means all "AZ" are worth four multipliers. One <tt>MULT1_MULTIPLIER</tt> line is required for each value of <tt>MULT1</tt> which has a multiplier but ALL matches all values.
|
|-
| '''MULT1_REPEAT''' '''MULT2_REPEAT''' '''MULT3_REPEAT'''
| Specifies a list of values of the multiplier and the number of times they count as multipliers. For instance <tt>MULT1_REPEAT=VD[3];PA[2]</tt> means the first three "VD" and the first two "PA" count as multipliers. If only a multiplier without a bracketed number is listed, the number is one. '''Important: This function is not correctly implemented in DXLog's bandmap.'''
| By default multipliers only count once
|-
| '''MULT1_CONT_LIST''' '''MULT2_CONT_LIST''' '''MULT3_CONT_LIST'''
| List used when MULT is of type CONT. '''Important: Antarctica is not included by default.'''
| Default value: EU;NA;SA;AS;AF;OC
|-
| '''MULT1_NO_ALERT''' '''MULT2_NO_ALERT''' '''MULT3_NO_ALERT'''
| Hides the multiplier and QSY alert at the bottom of the screen for the multiplier. Valid values: YES and NO.
| Default value: NO
|-
|}

'''Multiplier field considerations'''

<tt>CALLSIGN</tt> 
Ignores multiplier type for processing but a MULT#_FX key is always honored. 
Multiplier type can still be used for creating a list of valid multiplier values so 
CUSTOM can be useful for a derived multiplier (such as the last letter of a callsign). 
A dummy multiplier type CALLSIGN can be used for clarity.

<tt>FROM_DXCC</tt> 
Valid multiplier types are DXCC and FX. With DXCC, worked multipliers are displayed in the 
Worked DXCC window. With FX, the list of workable multipliers need to be defined, e.g., 
using <code>WINDOWS_CML_LIST_FX=GetList_...</code>.

<tt>FROM_WPX</tt> 
The multiplier type is ignored but a dummy type WPX can be used for clarity. Worked multipliers are 
displayed in a growing window.

'''Multiplier type considerations'''

<tt>HQ</tt> 
Like FIELD but with the exception that the multiplier will only be valid if the QSO does not 
represent a multiplier with lower number. For instance, if MULT3 is HQ, it will only be valid 
if neither MULT1 nor MULT2 are valid. A DXCC entity qualifier can be added using the 
<tt>MULT#_ADD_DXCC</tt> key, making sure the same multiplier is valid once per country. 
For example if you receive ARRL from W1AW, the multiplier's value will be "ARRL*K". 
Worked multipliers are displayed in a growing window.

<tt>CQZONE</tt> and <tt>ITUZONE</tt> 
Can be used with the RCVD, RECINFO, RECINFO2, and RECINFO3 fields. 
The set of workable multipliers is created automatically.

<tt>FX</tt> 
Can be used with the CALLSIGN, RCVD, RECINFO, RECINFO2, and RECINFO3 fields. 
The set of workable multipliers need to be defined, e.g., using <tt>WINDOWS_CML_LIST_FX=GetList_...</tt>.

<tt>FIELD</tt> 
Can be used with the RCVD, RECINFO, RECINFO2, and RECINFO3 fields. 
This is typically used for multipliers with too many possible values 
that visual tracking is infeasible. But it is still possible, 
The set of valid multiplier values is undefined by default and 
typically created using <tt>WINDOWS_CML_LIST_FX=GetList_...</tt>.

<tt>CUSTOM</tt> 
Can be used with the RCVD, RECINFO, RECINFO2, RECINFO3, and CALLSIGN fields. 
The list of valid multiplier values is created by a values listed between 
<code>[MULTIPLIERS START]</code> and <code>[MULTIPLIERS END]</code>.

<tt>NUM</tt> 
Can be used with the CALLSIGN, RCVD, RECINFO, RECINFO2, and RECINFO3 fields. 
Like FIELD but strips leading zeroes.

<tt>LASTLETTER</tt> and <tt>LETTER1</tt> 
Can be used with the CALLSIGN, RCVD, RECINFO, RECINFO2, and RECINFO3 fields. 
The list of workable multipliers is automatically created.

'''Multiplier exception considerations'''

{|class="wikitable"
|+style="text-align:Left;"|
| '''Exception'''
| '''Value when triggered'''
|-
| <tt>PFX_AREA</tt>
| The prefix area of the QSO's callsign.
|-
| <tt>WPX</tt>
| The WPX prefix of the QSO's callsign.
|-
| <tt>NONE</tt>
| An empty string, i.e., no multiplier.
|-
| <tt>CUSTOM_MULT_LIST</tt>
| The value of the multiplier, if it matches an item in the list of valid multipliers.
|-
| <tt>REMOVE_DXCC</tt>
| The value of the multiplier with a "*BBB" suffix stripped. Only meaningful for HQ multiplier.
|-
| <tt>LETTER1</tt>
| The first letter of the multiplier.
|-
| <tt>LASTLETTER</tt>
| The last letter of the multiplier.
|-
| <tt>VALUE</tt>
| The value of the multiplier.
|-
| <tt>VALUE:ABC</tt>
| The string following the colon.
|-
|}

=== Rate window keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''STATS_TYPE'''
| Type of statistics in Rate window. Valid values: STANDARD and WRTC.
| Default value: STANDARD
|-
| '''DISPLAY_TIME_ON_PER_MODE'''
| Display time on per mode in Rate window.
| Default value: NO
|-
| '''DISPLAY_LAST_MODE_CHANGE'''
| Display time of last mode change in Rate window.
| Default value: NO
|-
|}

=== Band change rule keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''BAND_MIN_LIMITS'''
| Bandwise minimum and maximum times. Only used by Bande Basse local Italian contest. Syntax: <tt>BAND_MIN_LIMITS=band;maxminutes;minfromlastqsominutes.</tt>
|
|-
| '''MULTISINGLE_RULE10_ENABLED'''
| 10-minute rule for Multi-Single operation.
| Default value: YES
|-
| '''MULTISINGLE_RULE10_FOR_MULT'''
| 10-minute rule applies to multiplier station.
| Default value: YES
|-
| '''MULTISINGLE_RULE10_MINUTES'''
| Actual number of minutes for 10-minute rule.
| Default value: 10
|-
| '''MULTISINGLE_RULE10_CHECKMODE'''
| Checking principle for 10-minute rule. Valid values: PER_BAND or PER_BAND_MODE
| style="white-space: nowrap;" | Default value: PER_BAND
|-
| '''MULTITWO_RULE10_ENABLED'''
| 10-minute rule for Multi-Two operation.
| Default value: NO
|-
| '''MULTIOP_BANDCHANGECOUNTER_ENABLED'''
| Band change counter for multi operator operation enabled.
| Default value: YES
|-
| '''MULTIOP_BANDCHANGES_ALLOWED'''
| Semicolon-separated list with number of band changes allowed in one hour in multi operator operation. Must have same number of entries as MULTIOP_BANDCHANGES_CBR_TRANSMITTERS.
| Default value: 8
|-
| '''MULTIOP_BANDCHANGES_CHECKMODE'''
| Type of counting method for band changes in multi operator operation. Valid values: PER_BAND or PER_BAND_MODE
| Default value: PER_BAND
|-
| '''MULTIOP_BANDCHANGES_TYPE'''
| Semicolon-separated list with type of band changes counted for band change rule in multi operator operation. Valid values are R, RM, or ALL. R is for M/2 and keeps two separate counters. RM is for M/1 where you have a separate counter for the Run and Multiplier stations. ALL means a single, common counter for all station types. The list must have the same number of entries as MULTIOP_BANDCHANGES_CBR_TRANSMITTERS.
| Default value: R
|-
| '''MULTIOP_BANDCHANGES_CBR_CATEGORIES'''
| Semicolon-separated list of Cabrillo operator categories subject to band change rule.
| Default value: MULTI-OP
|-
| '''MULTIOP_BANDCHANGES_CBR_TRANSMITTERS'''
| Semicolon-separated list of Cabrillo transmitter categories subject to band change rule.
| Default value: TWO
|-
|}

=== Contest score keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''SCORE'''
| Scoring principle. Valid values: BY_BAND, BY_BAND_MODE, BY_PERIOD, BY_PERIOD_BAND, and BY_PERIOD_BAND_MODE. Additional values are BY_MODE_GROUP and BY_BAND_GROUP. Their function is unknown. '''Important: BY_MODE does not exist.'''
| Default value: BY_BAND
|-
| '''SCORE_DISPLAY'''
| Displayed columns in Summary window. Available elements in their standard order: PERIOD, BAND, MODE, QSO, DUP, MULT1, MULT2, MULT3, QTC, POINTS, AVG, AVG0, and AVG1. A string within parenthesis following the element name will set the column header. Per mode display can be achieved by including the relevant mode(s) within curly brackets. Multiple modes are separated by '+'. Example: <tt>SCORE_DISPLAY=BAND;QSO(SSB){SSB};QSO(CW){CW};QSO(DIGI){RTTY+PSK31+PSK63};DUP</tt> will group all RTTY, PSK31, and PSK63 QSO under the same heading. Elements can be conditional using the <tt>*+NN:MM:LL></tt> syntax or <tt>*RGX:</tt> followed by a regular expressions (see above). Example: <tt>*-K:VE></tt> will display the column if your station is not a K or VE station. Example: <tt>*+SM:OZ:LA:OH></tt> will display the column only if you are a SM, OZ, LA, or OH station.
| Default value: BAND;QSO;DUP;MULT1(MULT);POINTS
|-

| '''SCORE_TOTAL_FX'''
| Formula for calculating total score for a QSO. Uses FLEE syntax which includes e.g. If(). Example: <tt>SCORE_TOTAL_FX=$FIELDVALUE.Points*$FIELDVALUE.Mult1+$FIELDVALUE.Mult3</tt>
| Default value: SCORE_TOTAL_FX= $FIELDVALUE.Points*($FIELDVALUE.Mult1+ $FIELDVALUE.Mult2+$FIELDVALUE.Mult3)
|-

|}

=== QSO points keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''POINTS_TYPE'''
| Type of points. Valid values: CALC, QRB, QRB_EXCHANGE+CALCF, QRB+CALCF, QRB+GRIDP2, RAEM, and FROM_TABLE() CALC expects the presence of POINTS_FIELD_BAND_MODE keys. QRB means one point per kilometer. QRB_EXCHANGE+CALCF requires at least one POINTS_CALC_F key and uses a grid in the configuration panel's Exchange field for QRB calculation. QRB only works with 6-position grids. QRB+CALCF requires at least one POINTS_CALC_F key and uses the configuration panel's Grid field for QRB calculation. RAEM uses the special RAEM contest point system. QRB+GRIDP2 is the number of large grids in distance plus two. FROM_TABLE(''filename;keytype;sourcekey;destkey'') requires a database text file that maps an exchange value to points. ''keytype'' is always INT, ''sourcekey'' is always "EXCHANGE", ''destkey'' can be RCVD, RECINFO, RECINFO2, or RECINFO3. The format of each line in the file is ''sourcekey value;destkey value=points''.
| style="white-space: nowrap;" | Default value: CALC
|-
| '''POINTS_BAND_BONUS'''
| Per band scaling factor. Syntax POINTS_BAND_BONUS=band;scaling. Example: <tt>POINTS_BAND_BONUS=160;2</tt> doubles the points number on the 160m band.
| Default value: 1 on all bands.
|-
| '''POINTS_FIELD_BAND_MODE'''
| Conditional point calculation. Syntax: <tt>POINTS_FIELD_BAND_MODE=</tt>''regex1;regex2;bandregex;moderegex;points;optionalregex'' The points item can be either a numeric (1, 10, etc.) or an aritmetic expression involving RCVD, RECINFO, RECINFO2, or RECINFO3. '''Important: When designing points rules, keep in mind the first valid rule encountered, reading from the top, overrides all subsequent rules. This can simplify rule-writing greatly.'''
| No default value
|-
| '''POINTS_CALC_F'''
| Formula for points calculation with <tt>POINTS_TYPE</tt> <tt>QRB_EXCHANGE+CALCF</tt> and <tt>QRB+CALCF</tt>. Syntax: <tt>POINTS_CALC_F=</tt>''sourceregex;pointsformula;bandregex;calculationregex'' Example: <tt>POINTS_CALC_F=ALL;VALUE*5.0;^15$;QRB>=100&&QRB<=800</tt> multiplies points with 5 on 15m if QRB is between 100 and 800km. All mathematical functions in C# syntax, plus the points number (<tt>VALUE</tt>) are available for expressions. In the ''calculationregex'', the keyword <tt>QRB</tt> can also be used for e.g. comparisons. Additionally, three additional syntax elements are available: <tt>VALUE{QRB:''grid''}</tt> which has the value of the distance (in km) from you to ''grid'', <tt>VALUE{*QRB:''grid''}</tt> which has the value of distance from ''grid'' to the party station, and <tt>VALUE{QRB:IARU}</tt> which has the value of the distance according to the IARU R1 rules for 6 and 4m MGM contests which is the distance between the centers of the origin and destination large square (four first characters) rounded up and if same, 50 points.
| No default value
|-
|}

=== Progress tracking keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''WINDOWS_CML_ENABLED'''
| Enable custom multiplier window #1.
| style="white-space: nowrap;" | Default value: NO
|-
| '''WINDOWS_CML2_ENABLED'''
| Enable custom multiplier window #2.
| Default value: NO
|-
| '''WINDOWS_CML3_ENABLED'''
| Enable custom multiplier window #3.
| Default value: NO
|-
| '''WINDOWS_CML_NAME'''
| Name of custom multiplier #1.
| No default value
|-
| '''WINDOWS_CML2_NAME'''
| Name of custom multiplier #2.
| style="white-space: nowrap;" | No default value
|-
| '''WINDOWS_CML3_NAME'''
| Name of custom multiplier #3.
| No default value
|-
| '''WINDOWS_CML_LIST_FX''' '''WINDOWS_CML2_LIST_FX''' '''WINDOWS_CML3_LIST_FX'''
| C# expression for the multipliers listed in custom multiplier window for MULT. Syntax: <tt>WINDOWS_CML_LIST_FX=function</tt>. Example: <tt><nowiki>WINDOWS_CML_LIST_FX=GetList_PrefixArea(dxccList,"^(VK|ZL)$")</nowiki></tt> Example:<tt> <nowiki>WINDOWS_CML_LIST_FX=GetList_CustomArray("A|C|CA|CC|CE|V|VI|Z","|")</nowiki></tt>
| No default value
|-
| '''WINDOWS_CML_DATA''' '''WINDOWS_CML2_DATA''' '''WINDOWS_CML3_DATA'''
| Source of data for custom multiplier window 1, 2, and 3. Valid values: MULT1, MULT2, MULT3, QSODIFF, QSODIFF_SP, and QSODIFF_CQ.
| No default value
|-
| '''WINDOWS_CML_SHOW_GROUP''' '''WINDOWS_CML2_SHOW_GROUP''' '''WINDOWS_CML3_SHOW_GROUP'''
| Controls if custom multiplier window 1, 3, and 3 show the multipliers grouped, if groups are defined. Valid values: YES and NO.
| Default value: NO
|-
| '''WINDOWS_CML_RESIZABLE''' '''WINDOWS_CML2_RESIZABLE''' '''WINDOWS_CML3_RESIZABLE'''
| Controls if custom multiplier windows are resizable.
| Default value: NO
|-
| '''WINDOWS_CML_LABELS_IN_ROW''' '''WINDOWS_CML2_LABELS_IN_ROW''' '''WINDOWS_CML3_LABELS_IN_ROW'''
| Controls number of MULT labels in each row of its custom multiplier window. Valid values: -1 and positive integers. -1 means DXLog default 10.
| Default value: -1
|-
| '''WINDOWS_CML_ALL_LABELS_IN_ROW''' '''WINDOWS_CML2_ALL_LABELS_IN_ROW''' '''WINDOWS_CML3_ALL_LABELS_IN_ROW'''
| Controls the number of MULT labels in each row of its custom multiplier window when all bands are displayed. Valid values: -1 and positive integers. -1 means DXLog default 20.
| Default value: -1
|-
| '''WINDOWS_CML_HIDDEN_CONT''' '''WINDOWS_CML2_HIDDEN_CONT''' '''WINDOWS_CML3_HIDDEN_CONT'''
| Hides a custom multiplier window for stations from selected continents. Currently not used in any contest.
| style="white-space: nowrap;" | Default value: None
|-
| '''WINDOWS_CML_HIDDEN_DXCC''' '''WINDOWS_CML2_HIDDEN_DXCC''' '''WINDOWS_CML3_HIDDEN_DXCC'''
| Hides a custom multiplier window for stations from selected DXCC. Syntax: <tt>WINDOWS_CML_HIDDEN_DXCC=list</tt> Example: <tt>WINDOWS_CML_HIDDEN_DXCC=*+G;GI;GW;GM;GJ;GU;GD</tt> hides the custom multiplier window for UK stations. Example: <tt>WINDOWS_CML_HIDDEN_DXCC=*-SM;LA;OZ;OH</tt> shows the custom multiplier window only for Scandinavian stations.
| No default value
|-
| '''WINDOWS_WKD_DXCC_ENABLED'''
| Enables worked DXCC window. '''Important:''' The worked DXCC window will only update on logging if DXCC is a valid multiplier for the contest. If you want to use this window for e.g., a VHF contests, you must define a zero-worth DXCC multiplier. E.g. <tt>MULT2_TYPE=DXCC</tt> <tt>MULT2_FIELD=FROM_DXCC</tt> <tt>MULT_SUM=NO</tt> Valid values: YES and NO.
| Default value: NO
|-
| '''WINDOWS_WKD_DXCC_HIDDEN_CONT'''
| Hides worked DXCC window for stations from selected continent. Example: <tt>WINDOWS_WKD_DXCC_HIDDEN_CONT=*-AS<tt> shows only the worked DXCC window for Asian stations.
| No default value
|-
| '''WINDOWS_WKD_DXCC_HIDDEN_DXCC'''
| Hides worked DXCC window for stations from selected DXCC. C.f. WINDOWS_CML_HIDDEN_DXCC above for syntax.
| No default value
|-
| '''WINDOWS_WKD_DXCC_SHOW_ONLY_CONT'''
| Show only entities from the listed continents in the worked DXCC window. Example: <tt>WINDOWS_WKD_DXCC_SHOW_ONLY_CONT=NA;SA</tt> shows only NA and SA entities in the worked DXCC window.
| No default value
|-
| '''WINDOWS_WKD_DXCC_CONT_FILTER'''
| Defines which DXCC entities from a selected continent to show in the worked DXCC window. Example: <tt>WINDOWS_WKD_DXCC_CONT_FILTER=SA:9Y;P4;PJ2;PJ4</tt> will only include 9Y, P4 and PJ2 from South America. You can have several of this key.
| No default value
|-
| '''WINDOWS_WKD_DXCC_HIDE_DXCC'''
| Hides a list of DXCC entities from the worked DXCC window. Example: <tt>WINDOWS_WKD_DXCC_HIDE_DXCC=K;VE</tt> hides US and Canada from the worked DXCC window.
| No default value
|-
| '''WINDOWS_WKD_GRID_ENABLED'''
| Enables worked grids window. Valid values: YES and NO.
| Default value: NO
|-
| '''WINDOWS_WKD_PFX_ENABLED'''
| Enables worked prefixes window. Valid values: YES and NO.
| Default value: NO
|-
| '''WINDOWS_WKD_PFX_HIDDEN_CONT'''
| Hides worked prefixes window for stations from selected continent. C.f. WINDOWS_WKD_DXCC_HIDDEN_CONT above for syntax.
| Default is to hide nothing
|-
| '''WINDOWS_WKD_PFX_HIDDEN_DXCC'''
| Hides worked prefixes window for stations from selected DXCC. C.f. WINDOWS_CML_HIDDEN_DXCC above for syntax.
| Default is to hide nothing
|-
| '''WINDOWS_WKD_PFX_DATA'''
| Source of worked prefixes data. Valid values: MULT1, MULT2, and MULT3.
| No default value
|-
|}

=== Livescore keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''LIVESCORE_ASSISTED'''
| List of assistance categories used for live score reporting. List must have the same number of items as mode CATEGORIES.
| Default value: Value of CABRILLO_ASSISTED
|-
| '''LIVESCORE_BAND''' '''LIVESCORE_BAND_SPECIAL'''
| List of band categories used for live score reporting. List must either have one single value of the same number of items as CABRILLO_BAND. If a single value, this is valid for all categories. Band names are Cabrillo convention. Non standard band categories recognized by score boards are: 2-BAND, 3-BAND, LOW-BAND, and HIGH-BAND. LIVESCORE_BAND_SPECIAL allows the use of non-standard values.
| Default value: Value of CABRILLO_BAND
|-
| '''LIVESCORE_CATEGORY_MODES'''
| List of contest mode categories used for live score reporting. List must have the same number of items as CATEGORY_MODES.
| Default value: Value of CATEGORY_MODES
|-
| '''LIVESCORE_CONTEST_NAME'''
| Contest name used for live score reporting. If the string contains <tt>{MODE}</tt> this will be replaced by the current contest mode capitalized.
| Default value: Value of CABRILLO_CONTEST_NAME
|-
| '''LIVESCORE_MODES'''
| List of modes used for live score reporting. List must have the same number of items as MODES.
| Default value: Value of CABRILLO_MODE
|-
| '''LIVESCORE_MULT'''
| List of multiplier "names" in numerical order used for live score reporting. Must have the same number of items as contest multipliers, but names may be repeated. Used when the multiplier type is not explicit, such as grid square. Valid multiplier types are <tt>ZONE, COUNTRY, STATE, GRIDSQUARE, WPXPREFIX, PREFIX, HQ</tt> and <tt>NONE</tt>.
| By default DXLog recognizes "country", "zone", "hq", "wpxprefix", and "state".
|-
| '''LIVESCORE_OPERATOR''' '''LIVESCORE_OPERATOR_SPECIAL'''
| List of types of operation used for live score reporting. List must have the same number of items as CATEGORIES. LIVESCORE_OPERATOR_SPECIAL allows the use of non-standard values.
| Default value: Value of CABRILLO_OPERATOR
|-
| '''LIVESCORE_POWER'''
| List of output power classes used for live score reporting. List must have the same number of items as CLASS.
| Default value: Value of CABRILLO_POWER
|-
| '''LIVESCORE_RTC_SENT_EXCHANGE'''
| List of the exchange elements sent by own station. Accepts *RGX conditionals like CABRILLO_LINE. Valid keywords are NR, OPNAME, EXCHANGE, POWER, MYCQZONE, MYITUZONE, MYDXCC, STATE, GRID4, GRID, and NOTHING. A literal string must be preceded by a single quote '. '''Important: This key is required in contest definition file to enable Real Time Contest QSO upload.'''
| Default value: None
|-
| '''LIVESCORE_TRANSMITTER'''
| List of number of transmitters categories used for live score reporting. List must have the same number of items as CATEGORIES.
| Default value: Value of CABRILLO_TRANSMITTER
|-
|}

=== QTC keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''QTC_ENABLED'''
| Enables QTC mechanics.
| Default value: NO
|-
| '''QTC_SEND_ENABLED'''
| Enables QTC sending.
| Default value: !SOURCE->CONT:^EU$
|-
| '''QTC_RECV_ENABLED'''
| Enables QTC receiving.
| Default value: SOURCE->CONT:^EU$
|-
| '''QTC_SEND_RGX'''
| Regular expression controlling the transmission of QTC.
|Default value: DEST->CONT:^EU$
|-
| '''QTC_RECV_RGX'''
| Regular expression controlling the reception of QTC.
|Default value: !DEST->CONT:^EU$
|-
|}

=== Other keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''ADIF_KEYS'''
| Allows for including custom keys in ADIF export. The syntax is <tt>ADIF_KEYS=</tt>''ADIFKEY;expression;regex1;regex2''. ''regex1'' and ''regex2'' are optional but must both evaluate as true for the key to be included in the export. The syntax for ''expression'' is C# and based on internal <tt>DXQSO</tt> object structure. Received exchanges are <tt>$VALUE.Rcvd</tt>, <tt>$VALUE.Rcvd4</tt>, <tt>$VALUE.RecInfo</tt>, <tt>$VALUE.RecInfo2</tt>, and <tt>$VALUE.RecInfo3</tt>. <tt>Rcvd4</tt> is the <tt>Rcvd</tt> object without the signal report. So to, for instance, export the received exchange as US/VE state use <tt><nowiki>ADIF_KEYS=STATE;$VALUE.Rcvd4;DEST->DXCC:^(K|KL|KH6|VE)$;DEST->RCVD:^[A-Z]{2}$</nowiki></tt>. To export the second exchange as operator name use <tt>ADIF_KEYS=NAME;$VALUE.RecInfo</tt> but note that DXLog will export a field of type NAME automatically. The following <tt>$VALUE.xxx</tt> keys are available: <tt>Sent, Rcvd, Rcvd4, RecInfo, RecInfo2, RecInfo3, Az, Mult, Mult1, Mult2, Mult3, Lp, Period, Band, Mode, Callsign, QRB (integer), Nr (integer), Stn, OriginStnID, Operator,</tt> and <tt>RadioVFO</tt>. Please note that you can also use C# style string manipulation such as <tt>Substring(start, length)</tt> etc. There is no limit on the number of <tt>ADIF_KEYS</tt> lines in a contest definition file, but with the exception of COMMENT, only one per key is allowed to be valid at one time. Multiple COMMENT keys are appended. The keywords $EXCHANGE, $POWER, $ITUZONE, $CQZONE, $DXCC, $TIME, $SERIAL, $GRID, $GRID4, $OPNAME, $STATE, or any C# string expression are also allowed, e.g., <tt>ADIF_KEYS=MY_SIG;WWFF</tt> and <tt>ADIF_KEYS=MY_SIG_INFO;$EXCHANGE</tt>. The following keys are reserved and cannot be customized QSO_DATE, TIME_ON, STATION_CALLSIGN, FREQ, BAND, CONTEST_ID, MODE, CALL, RST_SENT, RST_RCVD, OPERATOR, APP_DXLOG_RCVD, APP_DXLOG_RECINFO, APP_DXLOG_RECINFO2, APP_DXLOG_RECINFO3, APP_DXLOG_POINTS, APP_DXLOG_STNID, APP_DXLOG_STN, APP_DXLOG_MULT1, APP_DXLOG_MULT2, APP_DXLOG_MULT3, APP_DXLOG_NR, MY_GRIDSQUARE, MY_NAME, MY_CQ_ZONE, MY_ITU_ZONE, PFX, OWNER_CALLSIGN, and TX_PWR.
|Default value: None
|-
| '''ASTROPHYSICS'''
| Enables DXLog's propagation enhancing features. Valid values: YES and NO.
| Default value: NO
|-
| '''EDI_TOTAL_SCORE'''
| Defines how CToSc in EDI export is calculated. Valid values: ALL or PER_BAND.
| Default value: PER_BAND
|-
| '''OVERRIDE_INVALID_QSO_MESSAGE'''
| Suppress invalid QSO message for selected cases. Syntax is <tt>OVERRIDE_INVALID_QSO_MESSAGE=</tt>''IncaseRegex;AndRegex'' Example: <tt>OVERRIDE_INVALID_QSO_MESSAGE=DEST->DXCC:^K$;DEST->RCVD:^$</tt> will suppress complaints about invalid QSO when the RCVD field is empty US stations. '''This is however a legacy function with limited usefulness.''' To ensure stations without valid exchanges are correctly displayed in the bandmap you typically need to add zero-points dummy rules that will prevent error messages anyway.
| style="white-space: nowrap;" | Default value: None
|-
| '''SATELLITE_BAND'''
| Makes all QSO on a particular band or bands treated as satellite QSO. Example: <tt>SATELLITE_BAND=2300;QO-100;8089500</tt> will make all 13cm QSO in the log QO-100 satellite QSO with a receive frequency 8089500kHz higher than the logged frequency. Only affects UDP broadcast and ADIF export. More than one per contest definition is allowed.
| Default value: None
|-
| '''SELF_SPOT_ALLOWED'''
| Enables spotting of own station. Either a single YES/NO or a semicolon separated list of YES/NO with the same number of entries as CATEGORIES.
| Default value: NO
|-
| '''SELF_SPOT_MINPERIOD'''
| Controls the minimum time in minutes between spots of own station.
| Default value: 10
|-
| '''SELF_SPOT_MODES'''
| Controls the modes for which self spotting is allowed. Either ALL or a semicolon separated list of modes.
| Default value: ALL
|-
| '''SELF_SPOT_PER_RADIO'''
| Controls whether the self spotting period is per radio or per station.
| Default value: YES
|-
| '''SPRINT_LOGIC_ALLOWED'''
| Enable "sprint logic" check box in the Standard Messages panel's Options tab.
| Default value: NO
|-
| '''WARNING_FILE'''
| Name of a frequency range warning file located in <tt>%appdata%\DXLog\Database</tt>. The format of each line in the warning file is: <tt>Mode regular expression;frequency range;Message</tt> Example: <tt><nowiki>CW;3400-3520;Warning: Operation not allowed on this frequency</nowiki> <nowiki>CW;3550-3900;Warning: Operation not allowed on this frequency</nowiki> <nowiki>SSB;3400-3600;Warning: Operation not allowed on this frequency</nowiki> <nowiki>SB;3675-3700;Warning: Operation not allowed on this frequency</nowiki> <nowiki>SSB;3725-3900;Warning: Operation not allowed on this frequency</nowiki></tt> '''Important:''' File name casing must be correct for online update to work.
| No default value
|-
| '''WINDOWS_ON4KST_ENABLED'''
| Enables ON4KST messaging window
| Default value: NO
|-
|}

==Less obvious constructs==

Entry type based on DXCC of logged station.

<tt>FIELD_RCVD_TYPE=DXCC:^PA$=MULT;!DXCC:^PA$=NR</tt> 

The first match in the line is used, allowing "all others" type of constructs

<tt>FIELD_RCVD_TYPE=DXCC:^(K|KH6|KL|VE)$=MULT;DXCC:.=NR</tt>

Other multiplier than the defined.

<tt>MULT1_EXCEPTION=!SOURCE->DXCC:^(JW|JX|LA|OH|OH0|OJ0|OX|OY|OZ|SM|TF)$;PFX_AREA</tt>

Zero padding of an exchange. Normally not needed since DXLog zero pads several input types.

<tt>POINTS_FIELD_BAND_MODE=DEST->CONT:SOURCE->CONT;!SOURCE->ITUZONE:DEST->RCVD{F=R,2,0};ALL;ALL;3</tt>

Using a field value as the QSO score

<tt>POINTS_FIELD_BAND_MODE=!CONFIG->EXCHANGE:^ZZ$;ALL;ALL;ALL;RECINFO2</tt>

Adding alternative exchanges to multiplier list

<tt>CFG_MULT_RGX_CHECK=^0?[1-9]$|^[1-8][0-9]?$|^90$|CUSTOM_MULT_LIST 
FIELD_RCVD_RGX_CHECK=DEST->RCVD:^0?[1-9]$|^[1-8][0-9]?$|^90$;DEST->RCVD:CUSTOM_MULT_LIST</tt>

Disabling exchange checking for certain stations

<tt>FIELD_RECINFO_MANDATORY_RGX_EXC=!DEST->DXCC:^(K|KL|KH6|VE)$;DEST->CALL:/[AM]M$ 
FIELD_RECINFO_CHECK_FORMAT_FX=!DEST->DXCC:^(K|KL|KH6|VE)$>>""</tt>

Contest definition

2026-03-30T04:46:02Z

Sm7iun: /* Other keys */

==Introduction==

Contest rules vary greatly and are typically defined by the contest organizers. 
The differences can be in points per QSO, multiplier determination and calculations, etc. 
To support a wide variety of rules and to allow for easy adding/changing of contest rules in DXLog, 
contest rules are defined and controlled through a contest config file. 

Contest config files are "semi human readable", plain text files located in the '''Contest''' subdirectory in 
DXLog's installation directory. A wide range of contest definition files are included in the DXLog standard installation. 
The contest config files in the protected installation directory are however not intended for editing or modification 
For this, there is a copy of the directory in Windows' unprotected AppData directory structure. 
Since this is a hidden directory, a drop down menu item is provided for easy access. (File | Open configuration directory) 

Each time DXLog is started, the content of the installation subdirectory and the AppData subdirectory is compared. 
If a contest config file in the installation subdirectory is newer than its copy in the AppData subdirectory 
(e.g. due to it being updated as part of a new DXLog release), the AppData file is overwritten. 

In the opposite case (e.g. due to own modifications of a contest config file), the AppData file remains unchanged. 
This means that any modifications of existing contest config files should be done in the AppData directory, but that 
such modifications may be overwritten if a newer version is distributed in a later DXLog release. 
To secure that a contest config file is not overwritten by future DXLog releases, create a file with a new name. 
The same mechanic, with a master directory and an AppData copy, applies to data base (i.e. pre-fill or call history) files. 

If you have developed a contest config file that is proven to be correct and that could be useful others, Please contact 
the development team to discuss adding it to DXLog's standard contest repertoire.

[[image:Configurationpaneltagged3.png|800px]] 
Relation between configuration keys and macros and their related text boxes and drop down menus in the contest configuration panel.
 

==File structure==

Each line in a contest definition file usually contains '''KEY + VALUE''' pairs. 
The pair is always separated by the "=" sign. For example:

<code>CONTESTNAME=9A CW</code>

This means the ''field key'' is '''CONTESTNAME''' and the ''field value'' is '''9A CW'''.

==Regular expressions==

You will see that in many cases DXLog is using regular expressions to verify condition validation and process entries.

If you are not familiar with regular expressions (regex for short) there are many online resources available. 
One tutorial can be found [https://www.regular-expressions.info/tutorial.html here].

For example, regular expressions are used to check if the user keyboard entry is valid against a condition or 
set of conditions, for QSO points calculations etc.

Regular expressions in the contest configuration file can be defined as fixed values, but they can 
also compare QSO data against fixed values.

Example: We want to validate the user entered data in some of the fields. For example, we want 
to validate that the user is allowed to enter NY, FL, GA, or MA in the EXCHANGE field on the contest 
configuration screen.

The contest configuration key for this operation is: <code>CFG_MULT_RGX_CHECK</code>. 

So to create a validation, as per the previous example, we need the following definition 
in the contest config file:

: <code>CFG_MULT_RGX_CHECK=^NY$|^FL$|^GA$|^MA$</code>

: <code>^</code> denotes start of the string <code>$</code> denotes end of the string <code>|</code> separates alternative matching patterns, forming a logical or

Another example is to validate that the Exchange field is a two digit number or a six position grid:

: <code>CFG_MULT_RGX_CHECK=^([0-9]{2}|[A-R]{2}[0-9]{2}[A-X]{2})$</code>

: <code>()</code> surrounds alternative matching patterns <code>{}</code> forms a repetition of the preceding matching pattern

QSO data is addressed using a origin key (CONFIG, SOURCE, or DEST) and a content key (CALLSIGN, EXCHANGE, DXCC, etc.). 
They are combined using "->". Examples of QSO data keys are CONFIG->POWER, SOURCE->DXCC, and DEST->RCVD.

Not all possible combinations of origin keys and content keys are valid. Please see below for valid combinations.

{|class="wikitable"
|+style="text-align:Left;"|Available origin keys
|-
| '''CONFIG'''
| Information originating from contest configuration panel. If empty, derived from callsign.
|-
| '''SOURCE'''
| Information relating to own station. Always derived from station callsign.
|-
| '''DEST'''
| Information relating to other station.
|}

{|class="wikitable"
|+style="text-align:Left;"|Available content key combinations
|-
| '''CONFIG'''
| '''->'''
| '''ARRLRR'''
| A regular expression that matches the two last digits of the current and the three previous years. As an example it is <tt><nowiki>^(20|19|18|17)$</nowiki></tt> in 2020.
|-
| '''CONFIG''' or '''SOURCE''' or '''DEST'''
| '''->'''
| '''CALL'''
| Callsign.
|-
| '''CONFIG'''
| '''->'''
| '''CATEGORY'''
| The dropdown menu text of the entry category selected in the contest configuration panel in upper case.
|-
| '''CONFIG'''
| '''->'''
| '''CLASS'''
| The contest's active power class as selected in the contest configuration panel in upper case.
|-
| '''SOURCE''' or '''DEST'''
| '''->'''
| '''CONT'''
| Continent. Two letter acronym.
|-
| '''CONFIG'''
| '''->'''
| '''CQZONE'''
| CQ zone as entered in the contest configuration panel zero padded to two digits.
|-
| '''SOURCE''' or '''DEST'''
| '''->'''
| '''CQZONE'''
| CQ zone derived from the callsign zero padded to two digits.
|-
| '''CONFIG'''
| '''->'''
| '''DXCC'''
| DXCC prefix as entered in the contest configuration panel.
|-
| '''SOURCE''' or '''DEST'''
| '''->'''
| '''DXCC'''
| Official DXCC prefix derived from the callsign where international airspace/waters is "-".
|-
| '''CONFIG'''
| '''->'''
| '''EXCHANGE'''
| The content of the contest exchange field in the contest configuration panel.
|-
| '''CONFIG'''
| '''->'''
| '''GRID'''
| The content of the grid field in the contest configuration panel.
|-
| '''CONFIG'''
| '''->'''
| '''ITUZONE'''
| ITU zone as entered in the contest configuration panel zero padded to two digits.
|-
| '''SOURCE''' or '''DEST'''
| '''->'''
| '''ITUZONE'''
| ITU zone derived from the callsign zero padded to two digits.
|-
| '''CONFIG'''
| '''->'''
| '''MODE'''
| The chosen contest mode in upper case.
|-
| '''DEST'''
| '''->'''
| '''MODE'''
| The current QSO mode.
|-
| '''CONFIG'''
| '''->'''
| '''OPNAME'''
| The content of the operator name field in the contest configuration panel.
|-
| '''CONFIG'''
| '''->'''
| '''OVERLAY'''
| The overlay menu selection text in upper case. (Note that this is not the Cabrillo overlay)
|-
| '''SOURCE''' or '''DEST'''
| '''->'''
| '''WPX'''
| Callsign prefix per WPX rules.
|-
| '''SOURCE''' or '''DEST'''
| '''->'''
| '''PFX_AREA'''
| The callsign prefix formatted as main DXCC prefix plus "." and the prefix digit. E.g. "SM.0" or "EA.7". Note that DXCC prefixes containing a number keeps this, e.g., OH0DX is prefix area "OH0.0".
|-
| '''CONFIG'''
| '''->'''
| '''POWER'''
| The content of the power field in the contest configuration panel.
|-
| '''DEST'''
| '''->'''
| '''RCVD'''
| First element in the received contest exchange.
|-
| '''DEST'''
| '''->'''
| '''RECINFO'''
| Second element in the received contest exchange.
|-
| '''DEST'''
| '''->'''
| '''RECINFO2'''
| Third element in the received contest exchange.
|-
| '''DEST'''
| '''->'''
| '''RECINFO3'''
| Fourth element in the received contest exchange.
|-
| '''CONFIG'''
| '''->'''
| '''STATE'''
| The content of the State/Province/Other field in the contest configuration panel.
|-
| '''CONFIG'''
| '''->'''
| '''STATION'''
| The station category text in upper case. (Not the Cabrillo station category)
|-
| '''DEST'''
| '''->'''
| '''TIME_HOUR'''
| The hour of the QSO time as a string with values from "0" to "23".
|}

===Formatting suffix===

An origin/content key combination can have a formatting suffix, similar to that for <tt>CABRILLO_LINE</tt>. 
For instance,

<code>DEST->RCVD{F=R,2,0}:SOURCE->ITUZONE</code>

will zero pad the received exchange to a length of two before comparing. ITUZONE and CQZONE are always two digits.

===Extension suffix===

An origin/content key combination can have an extension suffix, which can also be a regular expression. 
For instance

<code>DEST->RCVD:DEST->CONT+[MQY]</code>

will evaluate true when the received exchange is identical to your own continent abbreviation followed by either M, Q, or Y.

===Examples===

1. We want to validate a value which could change on each entry into the log.

For example, we want to calculate points for each QSO with the same country, on the 160m band, in the CW and SSB mode, with 1 point.

The relevant contest configuration key for QSO points calculation is <code>POINTS_FIELD_BAND_MODE</code>. 
To create the calculation, as per the previous example, we need the following definition in the contest config file:

<code>POINTS_FIELD_BAND_MODE=SOURCE->DXCC:DEST->DXCC;ALL;^160$;^(CW|SSB)$;1</code>

We can read this definition in the following way: 
If the <code>SOURCE</code> (our) DXCC is the same as <code>DEST</code> (other station's) DXCC and the 
band is 160 and the mode is CW or SSB then the QSO is worth 1 point. In the above definition notice 
the <code>SOURCE</code> and <code>DEST</code> keys. We can also use the <code>CONFIG</code> key.

2. We want to display a per-mode QSO breakdown for mixed mode contest entry

<code>SCORE=BY_BAND_MODE</code> 
<code>SCORE_DISPLAY=BAND;QSO;*RGX:CONFIG->MODE:MIX>>QSO(CW){CW};*RGX:CONFIG->MODE:MIX>>QSO(SSB){SSB};MULT1(CTY);DUP;POINTS</code>

'''Important:''' The first "QSO" key can not be made conditional due to internal limitations.

==Functions and FX expressions==

Some keys allow not only keywords but also functions as arguments.

Functions follow C# syntax and have access to all string, number, and boolean manipulation functions in the language plus a number of helper functions.

The keywords available for regular expressions (see above) area also available in functions.

Some keywords assume an expression that returns a string, like MULT1_FX and FIELD_RCVD_CHECK_FORMAT_FX.

Examples: 
<tt><nowiki>MULT1_FX=$FIELDVALUE.Substring(0,4)</nowiki></tt> 
<tt><nowiki>MULT1_FX=$FIELDVALUE.Substring(0,$FIELDVALUE.IndexOf('/'))</nowiki></tt>

The first example picks the first four characters in the string as multiplier. 
The second example picks the string following the first slash ("/") character as multiplier. 
Two variables are available: $FIELDVALUE which is the multiplier or exchange itself, and $CALLSIGN which is the other station's call.

===String helper functions===

{|class="wikitable"
|+style="text-align:Left;"|Available string helper functions
|-
| <tt><nowiki>Helpers.GetBrazilUF($FIELDVALUE,$CALLSIGN)</nowiki></tt>
| Returns the two letter Brazilian region. Uses the exchange if valid, otherwise derives it from the callsign.
|-
| <tt><nowiki>Helpers.GetLastLetter($FIELDVALUE)</nowiki></tt>
| Returns the last character of a callsign, including slashed number suffixes.
|-
| <tt><nowiki>Helpers.GetLastLetterPure($FIELDVALUE)</nowiki></tt>
| Returns the last character of a callsign with a slashed prefix and suffixes removed.
|-
| <tt><nowiki>Helpers.GetOblast($FIELDVALUE)</nowiki></tt>
| Returns the Russian region based on field which should be callsign.
|-
| <tt><nowiki>Helpers.GetOblastSPLO($FIELDVALUE,$CALLSIGN)</nowiki></tt> 
| Returns the Russian region based on field which should be RCVD. Uses the RDA exchange for SP/LO stations to determine oblast and the callsign for all others. Used in UA1DZ Memorial contest. Multiplier field must be FROM_DXCC.
|-
| <tt><nowiki>Helpers.GetPureCall($FIELDVALUE)</nowiki></tt> 
| Returns the field (callsign) without prefix, slashes, etc.
|-
| <tt><nowiki>Helpers.GetPrefixArea($FIELDVALUE, $CALLSIGN)</nowiki></tt> 
| Returns the prefix area as NN.0. Multiplier field must be FROM_DXCC.
|-
| <tt><nowiki>Helpers.GetPrefixAreaVEGeo($FIELDVALUE, $CALLSIGN)</nowiki></tt>
| Returns the prefix area as NN.0 but treats Canadian geographical prefixes (VY2, etc.) as own call areas. Multiplier field must be FROM_DXCC.
|-
| <tt><nowiki>Helpers.GetSARLArea($FIELDVALUE)</nowiki></tt>
| Returns the SARL contest call area based on field which should be callsign.
|-
| <tt><nowiki>Helpers.GetSuffix($FIELDVALUE)</nowiki></tt>
| Returns the callsign suffix (characters after last number) based on field which should be callsign.
|-
| <tt><nowiki>Helpers.PadNumber3($FIELDVALUE)</nowiki></tt>
| Returns a single or double digit string string padded to three digits. Useful for contests with mixed serial and letter exchange.
|-
| <tt><nowiki>Helpers.PadNumber2($FIELDVALUE)</nowiki></tt>
| Returns a single digit string padded to two digits. Useful for contests with mixed zone and letter exchange.
|-
| <tt><nowiki>Helpers.ExtendCountyLine($FIELDVALUE,length)</nowiki></tt>
| Extends abbreviated county line exchanges in North American QSO parties. E.g., MABAR/BER is converted into MABAR/MABER.
|-
| <tt><nowiki>Helpers.Canada13($FIELDVALUE)</nowiki></tt>
| Returns NL when exchange is NF or LB. Does nothing for all other values, such as ELBE or NFX.
|}

===String list helper functions===

Some keywords assume an expression that returns a '''list of strings''', like WINDOWS_CML_LIST_FX. 

{|class="wikitable"
|+style="text-align:Left;"|Available string list helper functions
|-
| <tt><nowiki>GetList_PrefixArea(dxccList,regex)</nowiki></tt>
| Creates a multiplier list with all call areas prefixes
|-
| <tt><nowiki>GetList_PrefixAreaVEGeo(dxccList,regex)</nowiki></tt>
| Creates a multiplier list including Canadian (VY1, etc.) call areas
|-
| <tt><nowiki>GetList_CustomRange(format,start,end)</nowiki></tt>
| Creates a list of numbered multipliers
|-
| <tt><nowiki>GetList_CustomArray(string,separator)</nowiki></tt>
| Creates a custom list
|-
| <tt><nowiki>GetList_BrazilUF()</nowiki></tt>
| Creates a list containing the 27 Brazilian regions
|-
| <tt><nowiki>GetList_Oblast()</nowiki></tt>
| Creates a list containing the 85 Russian regions
|-
| <tt><nowiki>GetList_SARLArea()</nowiki></tt>
| Creates a list containing the 13 SARL contest call areas
|-
| <tt><nowiki>GetList_GridArray(center,height,width))</nowiki></tt>
| Creates a list of four letter grids around center
|}

'''Examples'''

<tt><nowiki>GetList_PrefixArea(dxccList,"^LA$")</nowiki></tt> - Creates a multiplier list with all Norwegian call areas. 
<tt><nowiki>GetList_PrefixAreaVEGeo(dxccList,"^(VE|K)$)</nowiki></tt> - Creates a multiplier list with all US and Canadian prefixes. 
<tt><nowiki>GetList_CustomRange("00",1,6)</nowiki></tt> - Creates the list 00, 01, 02, 03, 04, 05, and 06. 
<tt><nowiki>GetList_CustomArray("AB|AC|AD|AK|AM","|")</nowiki></tt> - Creates the list AB, AC, AD, AK, and AM. 
<tt><nowiki>GetList_GridArray(ownGrid,11,11)</nowiki></tt> - Creates a list of 121 grids centered around own location. 
<tt><nowiki>GetList_GridArray("JP81",9,9)</nowiki></tt> - Creates a list of 81 grids centered around JP81. 

===Number helper functions===

Some keywords assume an expression returning '''a number''', such as <tt>SCORE_TOTAL_FX</tt> and the second element of <tt>POINTS_CALC_F</tt>.

These assume FLEE syntax (see below).

<tt>SCORE_TOTAL_FX</tt> is the formula for the score for an individual QSO. 
Available variables available are <tt>$FIELDVALUE.Points</tt>, <tt>$FIELDVALUE.Mult1</tt>, 
<tt>$FIELDVALUE.Mult2</tt>, and <tt>$FIELDVALUE.Mult3</tt> having the values of the corresponding 
sums in the Summary window.

Example: <tt>SCORE_TOTAL_FX=$FIELDVALUE.Points+$FIELDVALUE.Mult1*2+$FIELDVALUE.Mult2*5</tt>
Example: <tt>SCORE_TOTAL_FX=$FIELDVALUE.Points*($FIELDVALUE.Mult1+If($FIELDVALUE.Mult2>10,10,$FIELDVALUE.Mult2))</tt>

<tt>POINTS_CALC_F</tt> is the formula for the points for certain QSO conditions.

===Boolean helper functions===

Other keys assume a '''boolean expression''' which can be either a regular expression (as described above) or 
an FX() expression. Examples are FIELD_RCVD_FX_CHECK and the first argument of MULT1_EXCEPTION. 
The syntax and operator repertoire is C#.

Examples: 
<tt><nowiki>MULT1_EXCEPTION=FX(Helpers.GetLastLetter("CONFIG->CALLSIGN").Equals(Helpers.GetLastLetter("DEST->CALL")));NONE</nowiki></tt> 
<tt><nowiki>MULT1_EXCEPTION=FX(("CONFIG->CALLSIGN").Substring(0,3).Equals(("DEST->CALL").Substring(0,3)));NONE</nowiki></tt> 
<tt><nowiki>MULT1_EXCEPTION=DEST->RCVD:^[KNS]DE;FX(("DEST->RCVD").Substring(1,2))</nowiki></tt> 

The first example does not count the QSO as a multiplier if the last letter is the same in the station's 
callsign and own callsign. The second example does not count the QSO as a multiplier if the first three characters 
is the same in the station's callsign and own callsign. The third example counts the first two characters of the 
exchange as multiplier if it starts with KDE, NDE or SDE.

The only available boolean helper function is:

<tt><nowiki>Helpers.Between(number, min, max)</nowiki></tt> - Returns true if number is between min and max.

===Available syntax for arithmetic expressions===

[[image:fleesyntax.png|500px]]

==Custom multiplier lists==

A custom multiplier list can only be used for multiplier type CUSTOM. FX type multipliers can not use a 
a listed set of multipliers but rely on a helper function to create its multiplier list, such as <tt>GetList_CustomRange()</tt>.

===Plain list of custom multipliers===

A list of custom multipliers is started by <tt>[MULTIPLIERS START]</tt> and ends with <tt>[MULTIPLIERS END]</tt>. 
The syntax for a multiplier having more than one name is shown below. In this example both NK and NR 
will count as the same multiplier; Norwich.

Example:
<tt>
: [MULTIPLIERS START]
: ...
: NL=London N1-22
: NN=Northampton
: NP=Newport
: NK{NK;NR}=Norwich
: NW=London NW1-11
: OL=Oldham
: OX=Oxford
: ...
: [MULTIPLIERS END]
</tt>

===Conditional lists of custom multipliers===

For contests such as US state QSO parties there are two types of participants with different sets of custom multipliers. 
To support this, a multiplier list can be conditional just like default messages. The regular expression can be of any type 
and check EXCHANGE, DXCC, CONT or whatever is suitable.

Syntax:
<tt>
: [MULTIPLIERS START]
: [VALID FOR=Regex1]
: M1=First multiplier 1
: M2=First multiplier 2
: ...
: [END VALID FOR]
: [VALID FOR=Regex2]
: L1=Second multiplier 1
: L2=Second multiplier 2
: ...
: [END VALID FOR]
: [MULTIPLIERS END]
</tt>

Example:
<tt>
: [MULTIPLIERS START]
: [VALID FOR=CONFIG->EXCHANGE:^(ADA|ALL|ARM|BEA|BED|BER|BLA|BRA|BUX)$]
: AK=Alaska
: AL=Alabama
: AR=Arkansas
: AZ=Arizona
: CO=Colorado
: ...
: [END VALID FOR]
: ...
: [MULTIPLIERS END]
</tt>

===Grouped list of custom multipliers===

Multipliers can be grouped for better display in the custom worked multipliers window enabled 
with the <tt>WINDOWS_CML_ENABLED</tt> key. The string following <tt>Group-></tt> is the displayed 
name of the group. The name has no impact on scoring. The syntax for alternative names for the same 
multiplier is different from the straight list. Alternative names for the same multiplier are 
instead separated with a slash. In the example below, QU, QC, and QUE will all count as the same 
multiplier; Quebec.

Example:
<tt>
: [MULTIPLIERS START]
: Group->K1_: CT,MA,ME,NH,RI,VT
: Group->K2_: NJ,NY
: Group->K3_: DE,PA,MD/DC
:...
: Group->VE1: NS
: Group->VE2: QC/QU/QUE
: Group->VE3: ON/ONT
: Group->VE4: MB/MAN
: ...
: [MULTIPLIERS END]
</tt>

Tip: In group names, the underscore character will be displayed as space. This is a simple way to 
create an even column width when groups have different length.

==General contest description keys==
{|class="wikitable"
|+style="text-align:Left;"|These keys are used for general contest description in the contest config file, such as the contest name, link to the rules etc.
|'''CONTESTGROUP'''
| Used for group contest when displaying the config screen for contest selection.
| e.g., DIGITAL MODES, 9A LOCAL CONTEST, etc.
|-
|'''CONTESTNAME'''
| The contest name as it will be shown and recognized in the contest selection box. Note: this can be same as the Cabrillo contest name, but usually it is the full contest name.
| This field is mandatory and must be unique for all files in contest definition directory.
|-
|'''CONTESTEXCH'''
| Web link to definition of contest exchange. Shown when entering invalid data in configuration panel's exchange field.
| e.g., https://www.iota-world.org/
|-
|'''CONTESTRULES'''
| External HTTP Link to contest rules. Adds "Contest rules" item to Help menu.
| e.g., https://www.cqww.com/rules.htm
|-
|'''CONTESTWEB'''
| External HTTP Link to contest rules. Adds "Contest web" item to Help menu.
| e.g., https://www.cqww.com
|-
|'''CONTEST_INFORMATION'''
| String with helpful information about operating the current contest. Adds "Contest information" item to Help menu and "Info" button in the Contest configuration window.
| e.g., Bonus stations are not recognized.\nLog non-members as 0000.
|}

==Contest configuration panel control keys==

{|class="wikitable"
|+style="text-align:Left;"|These keys are used for setting the contest configuration variables in the user configuration window.
|'''CATEGORIES'''
| Semicolon-separated list of contest categories shown in the category selection dropdown menu in the contest configuration panel. '''Important''': When defining own categories, the values of CABRILLO_OPERATOR, CABRILLO_TRANSMITTER, and CABRILLO_ASSISTED may have to be changed from their defaults. Also contests with only EDI export needs correct Cabrillo export keys. C.f the Cabrillo section below.
| Default value: Single operator, assisted;Single operator;Multi-operator, single transmitter; Multi-operator, two transmitters;Multi-operator, multi-transmitter;Checklog
|-
|'''CATEGORY_MODES'''
| Semicolon-separated list of contest modes shown in the mode selection dropdown menu in the contest configuration panel. '''Important:''' There is no contest mode key for CATEGORY-MODE. Phone, SSB, and AM are SSB. CW is CW. RTTY is RTTY. Mixed is MIXED. Digital, PSK31, JT65, FT8, and other digital modes are DIGI.
| Default value: CW;SSB;Mixed
|-
|'''CLASS'''
| Semicolon-separated list of contest power classes shown in the class selection dropdown menu in the contest configuration panel.
| Default value: High;Low;QRP
|-
|'''CFG_EMAIL_MANDATORY'''
| Controls if the Email field in the contest configuration panel requires an entry or can be empty. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_MULT'''
| Controls the use of the exchange field in contest configuration panel. Valid values are: ON and OFF. If OFF, the exchange field is greyed out.
| Default value: OFF
|-
|'''CFG_MULT_DX_ALLOWED'''
| Controls if "DX" is an acceptable entry in exchange field. For example in ARRL DX Contest, all USA/VE stations needs to enter their state/province, while all other stations enters DX here. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_MULT_SLASH_ALLOWED'''
| Allows the use of "/" in the Exchange field as separator for contests where the exchange can be one or more elements of the same type, such as county-line stations in some US QSO parties where a station can belong to more than one counties and thereby represent more than one multiplier in one QSO. '''Important:''' CFG_MULT_SLASH_IGNORED and CFG_MULT_SLASH_ALLOWED must never both be YES. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_MULT_SLASH_IGNORED'''
| Allows the use of "/" in the Exchange field as part of the exchange itself rather than as a separator '''Important:''' CFG_MULT_SLASH_IGNORED and CFG_MULT_SLASH_ALLOWED must never both be YES. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_MULT_MANDATORY'''
| Controls if the exchange field requires an entry or can be empty. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_MULT_ERRORTEXT'''
| Defines error text which is shown if the validity test for the exchange field fails. For example, in ARRL DX Contest, if the user enters a state abbreviation which is not in the approved list.
| Default value: "Invalid value in exchange field!"
|-
|'''CFG_MULT_FROM'''
| Alternative to using a regular expression to check validity of entry in Exhange field. Valid values are CUSTOM_MULT_LIST, CQZONE, and ITUZONE. '''Important''': CUSTOM_MULT_LIST obviously cannot be used if own exchange is not a valid multiplier
| Default value: Unused
|-
|'''CFG_MULT_RGX_CHECK'''
| Regular expression used to test validity of entry in Exchange field. Note that the regular expression can include the key CUSTOM_MULT_LIST meaning that any entry listed in the custom multiplier list is considered valid. Example: <tt><nowiki>CFG_MULT_RGX_CHECK=^AF$|^AS$|^EU$|^NA$|^OC$|^SA$|CUSTOM_MULT_LIST</nowiki></tt>
| Default value: ALL
|-
|'''CFG_CQZONE_ERRORTEXT'''
| Defines the error text shown if the entry in the CQ zone field fails the validity test.
| Default value: "Invalid CQ zone!"
|-
|'''CFG_CQZONE_MANDATORY'''
| Controls if the CQ zone field requires an entry or can be empty. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_GRID_ERRORTEXT'''
| Defines the error text shown if the entry in the GRIDSQUARE field fails the validity test.
| Default value: "Invalid entry in gridsquare field!"
|-
|'''CFG_GRID_MANDATORY'''
| Controls if the GRIDSQUARE field requires an entry or can be blank. Valid values are: YES and NO. Is automatically set to YES if contest has QRB-based scoring.
| Default value: NO
|-
|'''CFG_GRID_RGX_CHECK'''
| Regular expression used to test validity of data entered in the GRIDSQUARE field.
| Default value: <tt><nowiki>^[A-R][A-R][0-9][0-9][A-X][A-X]$</nowiki></tt>
|-
|'''CFG_ITUZONE_ERRORTEXT'''
| Defines error text shown if the entry in the ITU zone field fails the validity test.
| Default value: "Invalid ITU zone!"
|-
|'''CFG_ITUZONE_MANDATORY'''
| Controls if the ITU zone field requires an entry or can be empty. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_MYDXCC_ERRORTEXT'''
| Defines the error text shown if the entry in the DXCC field fails the validity test.
| Default value: "Unrecognized DXCC from DXCC field. Please enter valid country prefix in DXCC field"
|-
|'''CFG_MYDXCC_MANDATORY'''
| Controls if the DXCC field requires an entry or can be empty. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_OPNAME_ERRORTEXT'''
| Defines the error text shown if the entry in the operator name field fails the validity test.
| Default value: "Operator name field is mandatory!"
|-
|'''CFG_OPNAME_MANDATORY'''
| Controls if the operator name field requires an entry or can be empty. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_POWER_ERRORTEXT'''
| Defines the error text shown if the entry in the power field fails the validity test.
| Default value: "Invalid value in power field!"
|-
|'''CFG_POWER_MANDATORY'''
| Controls if the power field requires an entry or can be empty. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_POWER_RGX_CHECK'''
| Regular expression used to determine the validity of the power field entry.
| Default value: ALL
|-
|'''CFG_STATE_ERRORTEXT'''
| Defines the error text shown if the entry in the state/province/other field fails the validity test.
| Default value: "Invalid value in state/other field!"
|-
|'''CFG_STATE_FROM=CUSTOM_MULT_LIST'''
| Defines a list-based validity test for the state/province/other field. Alternative to to using a regular expression.
| Default value: absent
|-
|'''CFG_STATE_MANDATORY'''
| Controls if the state/province/other field requires an entry or can be empty. Valid values are: YES and NO
| Default value: NO
|-
|'''CFG_STATE_RGX_CHECK'''
| Regular expression used to test validity of entry in state/province/other field. Note that the regular expression can include the key CUSTOM_MULT_LIST meaning that any entry listed in the custom multiplier list is considered valid. Example: <tt><nowiki>CFG_STATE_RGX_CHECK=^YL$|^OM$|CUSTOM_MULT_LIST</nowiki></tt>
| Default value: ALL
|-
|'''OVERLAY'''
| Semicolon-separated list of contest overlays shown in the Overlay dropdown menu in the contest configuration panel. Disable CATEGORY-OVERLAY in the Cabrillo export by assigning OVERLAY one single value.
| Default value: ---;Classic;Rookie;Tribander/Single element;Youth;Novice/Tech;Over 50
|-
|'''OVERLAY_ASSISTED'''
| Single keyword or semicolon-separated list of YES/NO controlling if an overlay represents an unassisted category. With a single keyword, this applies to all overlays. Must have one or the same number of entries as OVERLAY. If the selected overlay corresponds to a NO, incoming cluster spots are blocked. In other cases, CABRILLO_ASSISTED decides.
| Default value: YES
|-
|'''STATION'''
| Semicolon-separated list of contest station categories shown in the Station dropdown menu in the contest configuration panel.
| Default value: Fixed;Distributed;Headquarter;Mobile;Portable; Rover;Rover-Limited;Rover-Unlimited;Expedition;School
|}

==Cabrillo export keys==

===Contest configuration keys===

{|class="wikitable"
|+style="text-align:Left;"|
| '''CABRILLO_ASSISTED'''
| Semicolon-separated list of mapping of categories to Cabrillo assistance types. MUST have the same number of entries as the defined contest categories. Valid list items are ASSISTED and NON-ASSISTED. '''Important: When a NON-ASSISTED category is selected, incoming cluster spots are blocked.'''
| Default value: ASSISTED;NON-ASSISTED;ASSISTED;ASSISTED;ASSISTED;ASSISTED
|-
| '''CABRILLO_ASSISTED_DISABLED'''
| No CATEGORY-ASSISTED line will be included in exported file. Tip: With this set to YES, cluster spots are never blocked.
| Default value: NO.
|-
| '''CABRILLO_BAND''' '''CABRILLO_BAND_SPECIAL'''
| Semicolon-separated list of band definition names for contests with band-limited categories. For value AUTO the band category will be ALL unless the log only contains QSO from a single band. In this case the band category will be this single band. For all other values of the key, log content is ignored. If only assigned a single value, such as 10M, ALL, or AUTO, this will be valid for all categories. Must be accompanied by a LIVESCORE_BANDS key when non standard values are used. Band names are Cabrillo convention 160M, ...6M, 2M, 222, 432, .... CABRILLO_BAND_SPECIAL allows the use of non-WWROF-standard values.
| Default value: AUTO;AUTO;ALL;ALL;ALL;ALL
|-
| '''CABRILLO_CLUB_FIELD'''
| Club name for Cabrillo export. Overrides the club field in the contest configuration window. Valid values are STATE or EXCHANGE.
| No default value
|-
| '''CABRILLO_CONTEST_NAME'''
| Formal contest name for Cabrillo export. If name contains <tt>{MODE}</tt> this will be replaced by the selected contest mode capitalized.
| No default value
|-
| '''CABRILLO_DEF_RECINFO''' '''CABRILLO_DEF_RECINFO2''' '''CABRILLO_DEF_RECINFO3'''
| Value to use in Cabrillo export if field is empty.
| Default value: Empty
|-
| '''CABRILLO_EXPORT_TYPE'''
| Controls structure of Cabrillo export. Valid values: PER_MODE and ALL.
| Default value: ALL
|-
| '''CABRILLO_LINE'''
| Use: <tt>CABRILLO_LINE=FREQ;MODE;DATE;TIME;MYCALL;SENT;NR{F=R,3,0,4}</tt> Data is taken from the field names and added to the Cabrillo line in the order entered. FREQ represents frequency of QSO, MODE represents mode etc. For more details on valid keywords and the use of conditional entries, see below.
| No default value
|-
| '''CABRILLO_LOCATION'''
| Semicolon-separated list of mapping of contest categories to Cabrillo LOCATION key. If defined, MUST have the same number of entries as the defined contest categories. Any string is a valid value. If left undefined, contest category has no effect on LOCATION in Cabrillo export. Alternative to CABRILLO_LOCATION_FIELD.
| Default value: Disabled
|-
| '''CABRILLO_LOCATION_FIELD'''
| Defines the source of the LOCATION: key in the Cabrillo export. Valid values are EXCHANGE, STATE, GRID, GRID4, GRID2, ITUZONE, and CQZONE. Alternative to CABRILLO_LOCATION.
| Default value: Disabled
|-
| '''CABRILLO_MODES'''
| Semicolon-separated list of mapping of the contest's modes (as defined by the MODES key) to Cabrillo modes in QSO lines. MUST have the same number of entries as the defined number of modes for the contest. WWROF defined values are CW, PH, DG, RY, and FM. See below for the full list of de-facto standard mode acronyms. Must be accompanied by a LIVESCORE_MODES key when non standard values are used.
| Default value: CW;PH
|-
| '''CABRILLO_OPERATOR''' '''CABRILLO_OPERATOR_SPECIAL'''
| Semicolon-separated list of mapping of categories to to Cabrillo operator count. MUST have the same number of entries as the defined contest categories. Valid list items are SINGLE-OP, MULTI-OP, and CHECKLOG. Must be accompanied by a LIVESCORE_OPERATOR key when non standard values are used. CABRILLO_OPERATOR_SPECIAL allows the use of non-WWROF-standard values.
| Default value: SINGLE-OP;SINGLE-OP; MULTI-OP;MULTI-OP;MULTI-OP;CHECKLOG
|-
| '''CABRILLO_OVERLAY''' '''CABRILLO_OVERLAY_SPECIAL'''
| Semicolon-separated list of mapping of category overlays to Cabrillo overlays. MUST have the same number of entries as the defined overlays. Any string is a valid entry. It is possible to block incoming cluster spots for one or several overlays. C.f. OVERLAY_ASSISTED. CABRILLO_OVERLAY_SPECIAL allows the use of non-WWROF-standard values.
| Default value: ;CLASSIC;ROOKIE;TB-WIRES;YOUTH;NOVICE-TECH;OVER-50
|-
| '''CABRILLO_OVERLAY_DISABLED'''
| Suppresses CATEGORY-OVERLAY in export.
| Default value: NO
|-
| '''CABRILLO_POWER''' '''CABRILLO_POWER_SPECIAL'''
| Semicolon-separated list of mapping of category power classes to Cabrillo power classes. MUST have the same number of entries as the contest's power classes. List items can be any string but WWROF defined keywords are HIGH, LOW, and QRP. Must be accompanied by a LIVESCORE_POWER key when non standard values are used. CABRILLO_POWER_SPECIAL allows the use of non-WWROF-standard values.
| Default value: HIGH;LOW;QRP
|-
| '''CABRILLO_QTC_LINE'''
| Definition of Cabrillo output for QTC. C.f. '''CABRILLO_LINE'''. Valid keywords are: FREQ, MODE, DATE, TIME, RCVDBY, GRNUM, SENTBY, QTCTIME, QTCCALL, and QTCSERIAL.
| Default value: Disabled
|-
| '''CABRILLO_STATION''' '''CABRILLO_STATION_SPECIAL'''
| Semicolon-separated list of mapping of station categories to Cabrillo station categories. MUST have the same number of entries as the defined station categories. CABRILLO_STATION_SPECIAL allows the use of non-WWROF-standard values.
| Default value: FIXED;DISTRIBUTED;HQ;EXPLORER;MOBILE;PORTABLE;ROVER; ROVER-LIMITED;ROVER-UNLIMITED;EXPEDITION;SCHOOL
|-
| '''CABRILLO_TIME''' '''CABRILLO_TIME_SPECIAL'''
| Semicolon-separated list of duration for each contest category. '''Important:''' Must have the same number of entries as there are contest categories. WWROF defined values are 6-HOURS, 8-HOURS, 12-HOURS, and 24-HOURS. CABRILLO_TIME_SPECIAL allows the use of non-WWROF-standard values.
| Default value: Disabled
|-
| '''CABRILLO_TRANSMITTER''' '''CABRILLO_TRANSMITTER_SPECIAL'''
| Semicolon-separated list of mapping of categories to Cabrillo operator counts. '''Important:''' Must have the same number of entries as the defined contest categories. WWROF defined values are ONE, TWO, LIMITED, UNLIMITED, and SWL. Must be accompanied by a LIVESCORE_TRANSMITTER key when non standard values are used. CABRILLO_TRANSMITTER_SPECIAL allows the use of non-WWROF-standard values.
| Default value: ONE;ONE;ONE;TWO;UNLIMITED;UNLIMITED
|}

===CABRILLO_LINE keywords===

Important note: If you want to take full control of the columns to e.g. concatenate fields in the export, 
this is done by adding a trailing asterisk ("*") to the keys below. This will remove the extra space 
following a field to guarantee separation. Extra spaces required to align to certain character positions 
can be added using the <tt>DUMMY</tt> keyword.

Surrounding the keyword with parentheses (e.g., <tt>(EXCHANGE)</tt>) means the key is optional at import. 
This typically only works for keywords at the end of the line, such as STN.

{|class="wikitable"
|+style="text-align:Left;"|
| '''Key'''
| '''Content'''
| '''Default format'''
|-
| <tt>CALL</tt>
| Logged station's call.
| <tt>{F=L,13, }</tt>
|-
| <tt>DATE</tt>
| Date of QSO. Format YYYY-MM-DD.
| <tt>{F=L,10, }</tt>
|-
| <tt>DUMMY</tt>
| Only spaces.
| <tt>{F=L,5, }</tt>
|-
| <tt>DXCC</tt>
| DXCC of logged station. Derived from CTY database.
| <tt>{F=L,6, }</tt>
|-
| <tt>EXCHANGE</tt>
| Exchange as entered in the contest configuration panel. Can optionally take a string function instead of formatting arguments within curly brackets. E.g. <tt><nowiki>EXCHANGE{FX=$FIELDVALUE.Substring(0,4)}</nowiki></tt> Breaks up slashed entries.
| <tt>{F=L,6, }</tt>
|-
| <tt>FREQ</tt>
| Frequency in kilohertz.
| <tt>{F=R,6, }</tt>
|-
| <tt>FREQMHZ</tt>
| Frequency in Megahertz.
| <tt>{F=R,6, }</tt>
|-
| <tt>GRID</tt>
| Grid locator as entered in the contest configuration panel.
| <tt>{F=L,6, }</tt>
|-
| <tt>GRID4</tt>
| First four positions of the grid locator entered in the contest configuration panel.
| <tt>{F=L,6, }</tt>
|-
| <tt>MODE</tt>
| QSO mode with Cabrillo coding.
| <tt>{F=L,2, }</tt>
|-
| <tt>MYCALL</tt>
| Own call as entered in the contest configuration panel.
| <tt>{F=L,13, }</tt>
|-
| <tt>MYCQZONE</tt>
| Own CQ zone as entered in the contest configuration panel.
| <tt>{F=L,2,0,6}</tt>
|-
| <tt>MYDXCC</tt>
| Own DXCC prefix as entered in the contest configuration panel.
| <tt>{F=L,6, }</tt>
|-
| <tt>MYITUZONE</tt>
| Own ITU zone as entered in the contest configuration panel.
| <tt>{F=L,2,0,6}</tt>
|-
| <tt>NOTHING</tt>
| An empty string. Add a trailing asterisk for literally nothing.
| <tt>{F=L,0, }</tt>
|-
| <tt>NR</tt>
| Own serial number for the QSO.
| <tt>{F=R,3,0,6}</tt>
|-
| <tt>OPNAME</tt>
| Operator name as entered in the contest configuration panel.
| <tt>{F=L,10, }</tt>
|-
| <tt>PERIOD</tt>
| Contest period.
| <tt>{F=L,2, }</tt>
|-
| <tt>POWER</tt>
| Station power string as entered in the contest configuration panel.
| <tt>{F=L,6, }</tt>
|-
| <tt>PREV_RCVD</tt>
| First element in previously received exchange.
| <tt>{F=L,3,0}</tt>
|-
| <tt>PREV_RECINFO</tt>
| Second element in previously received exchange.
| <tt>{F=L,3,0}</tt>
|-
| <tt>PREV_RECINFO2</tt>
| Third element in previously received exchange.
| <tt>{F=L,3,0}</tt>
|-
| <tt>PREV_RECINFO3</tt>
| Fourth element in previously received exchange.
| <tt>{F=L,3,0}</tt>
|-
| <tt>PTS</tt>
| Points of QSO.
| <tt>{F=R,3,0}</tt>
|-
| <tt>RCVD1</tt>
| Received RST.
| <tt>{F=L,3, }</tt>
|-
| <tt>RCVD2</tt>
| First element in received exchange without RST. Can optionally take a string function instead of formatting arguments within curly brackets. E.g., <tt><nowiki>RCVD2{FX=$FIELDVALUE.Substring(0,4)}</nowiki></tt>
| <tt>{F=L,6, }</tt>
|-
| <tt>RECINFO</tt>
| Second element of received exchange. Can optionally take a string function instead of formatting arguments within curly brackets. E.g., <tt><nowiki>RECINFO{FX=$FIELDVALUE.Substring(0,4)}</nowiki></tt>
| <tt>{F=L,5, }</tt>
|-
| <tt>RECINFO2</tt>
| Third element of received exchange. Can take optionally a string function instead of formatting arguments within curly brackets. E.g., <tt><nowiki>RECINFO2{FX=$FIELDVALUE.Substring(0,4)}</nowiki></tt>
| <tt>{F=L,5, }</tt>
|-
| <tt>RECINFO3</tt>
| Fourth element of received exchange. Can optionally take a string function instead of formatting arguments within curly brackets. E.g., <tt><nowiki>RECINFO3{FX=$FIELDVALUE.Substring(0,4)}</nowiki></tt>
| <tt>{F=L,5, }</tt>
|-
| <tt>SENT</tt>
| Sent RST.
| <tt>{F=L,3, }</tt>
|-
| <tt>SLASH</tt>
| The character '/'. Add trailing asterisk to remove separating space.
| <tt>{F=L,1, }</tt>
|-
| <tt>STATE</tt>
| State or province as entered in the contest configuration panel.
| <tt>{F=L,5, }</tt>
|-
| <tt>STN</tt>
| Station. "0" for all stations except radio 2 in SO2R, the multiplier station in Multi/Single, and Run2 in Multi/Two which all are "1". '''Important:''' It is a good idea to wrap STN in parentheses to make it optional at import. Some loggers only include it for certain categories.
| <tt>{F=L,2, }</tt>
|-
| <tt>TIME</tt>
| Time of QSO. Format HHMM.
| <tt>{F=L,4, }</tt>
|-
| <tt>'</tt>
| A literal. E.g., <tt>'ABC{F=L,6,}</tt> means "ABC ". Add * after the literal (<tt>'ABC*</tt>) avoid a trailing space.
| <tt>{F=L,6, }</tt>
|-
|}

===CABRILLO_LINE formatting and conditionals===

<tt>CABRILLO_LINE</tt> formatting information is contained within curly brackets with the following syntax: 

<tt>{''F=AL'',''PS'',''PC''(,''TS'')}</tt>

: ''F='': Formatting flag
: ''AL'': Alignment, can be ''L'' (for left) or ''R'' (for right)
: ''PS'': Padded size. Total size of text including character padding.
: ''PC'': Character used for padding. E.g., 0 for serial numbers.
: ''TS'': Total size of field. Space padding to the right is used to reach this size. Optional.

Example: <tt>RCVD2{F=R,3,0,4}</tt> 

Means <tt>RCVD2</tt> field value will be aligned right, to a length of 3 characters. The "0" character is 
used to pad to the specified length. Total size will be 4 characters (padding with spaces to reach 4). 
This means that if <tt>RCVD2</tt> field value is "1", it will be formatted as " 001" in the Cabrillo QSO line.

Regardless if total size is specified or not, each field will always be surrounded by spaces.

For some keys it is possible to replace the formatting information with a string operation, using an <tt>FX=</tt> 
syntax and the <tt>$FIELDVALUE</tt> keyword to represent a string containing the field's characters.

<tt>CABRILLO_LINE</tt> also supports conditional formatting using a <tt>*RGX:</tt> syntax.

Example: <tt><nowiki>*RGX:SOURCE->DXCC:^(DL|OE)$>>EXCHANGE{F=L,6, }/NR{F=R,3,0,6};</nowiki></tt> 

means the content of the Exchange box in the contest configuration panel station for German and Austrian 
stations, otherwise a three position serial number. Both of total length 6.

per-own-DXCC conditional formatting is also supporting using a <tt>*NN></tt> syntax

Example: <tt><nowiki>*DL>EXCHANGE{F=L,6, }/NR{F=R,3,0,6};</nowiki></tt> 

means the same as the above example, but only for German stations. This conditional can 
also be repeated, to cover several DXCC entities.

===CABRILLO_QTC_LINE keywords===

{|class="wikitable"
|+style="text-align:Left;"|
| '''Key'''
| '''Content'''
| '''Format'''
|-
| <tt>FREQ</tt>
| Frequency in kilohertz
| 6 positions, right adjusted
|-
| <tt>MODE</tt>
| Mode when receiving QTC
| 3 positions, left adjusted
|-
| <tt>DATE</tt>
| Date QTC exchanged
| 12 positions
|-
| <tt>TIME</tt>
| Time QTC exchanged
| 4 positions
|-
| <tt>RCVDBY</tt>
| Call of receiving station
| 13 positions, left adjusted
|-
| <tt>GRNUM</tt>
| Group number of QTC
| 10 positions, left adjusted
|-
| <tt>SENTBY</tt>
| Call of sending station
| 13 positions, left adjusted
|-
| <tt>QTCTIME</tt>
| Time in QTC line
| 4 positions
|-
| <tt>QTCCALL</tt>
| Call in QTC line
| 13 positions, left adjusted
|-
| <tt>QTCSERIAL</tt>
| Serial in QTC line
| 3 positions, right adjusted
|-
|}

===Configuration keys' relation to Cabrillo export===

{|class="wikitable"
|+style="text-align:Left;"|Default relation between contest category configuration and Cabrillo export 
!'''Key type'''
!'''DXLog Key'''
!'''Cabrillo key'''
!colspan="6"|'''Default values'''
|-
| Configuration
| CATEGORIES
|
| Single operator, assisted
| Single operator
| Multi-operator, single transmitter
| Multi-operator, two transmitter
| Multi-operator, multi-transmitter
| Checklog
|-
| Cabrillo
| CABRILLO_OPERATOR
| CATEGORY-OPERATOR
| style="white-space: nowrap;" | SINGLE-OP
| style="white-space: nowrap;" | SINGLE-OP
| MULTI-OP
| MULTI-OP
| MULTI-OP
| CHECKLOG
|-
| Cabrillo
| CABRILLO_TRANSMITTER
| CATEGORY-TRANSMITTER
| ONE
| ONE
| ONE
| TWO
| UNLIMITED
| UNLIMITED
|-
| Cabrillo
| CABRILLO_ASSISTED
| CATEGORY-ASSISTED
| ASSISTED
| style="white-space: nowrap;" | NON-ASSISTED
| ASSISTED
| ASSISTED
| ASSISTED
| ASSISTED
|-
| Cabrillo
| CABRILLO_BAND
| CATEGORY-BAND
| AUTO
| AUTO
| ALL
| ALL
| ALL
| ALL
|}

{|class="wikitable"
|+style="text-align:Left;"|Default relation between contest overlay configuration and Cabrillo export 
!'''Key type'''
!'''DXLog Key'''
!'''Cabrillo key'''
!colspan="5"|'''Default values'''
|-
| Configuration
| OVERLAY
|
| style="width:150px;"|<nowiki>---</nowiki>
| style="width:150px;"|School
| style="width:150px;"|Dxpedition
| style="width:150px;"|Headquarter
| style="width:150px;"|...
|-
| Cabrillo
| style="white-space: nowrap;" | CABRILLO_OVERLAY
| style="white-space: nowrap;" | CATEGORY-OVERLAY
| style="white-space: nowrap;" | Key omitted
| CLASSIC
| ROOKIE
| TB-WIRES
| ...
|}

{|class="wikitable"
|+style="text-align:Left;"|Default relation between contest power class configuration and Cabrillo export 
!'''Key type'''
!'''DXLog Key'''
!'''Cabrillo key'''
!colspan="5"|'''Default values'''
|-
| Configuration
| CLASS
|
| style="width:150px;"|High
| style="width:150px;"|Low
| style="width:150px;"|QRP
|-
| Cabrillo
| CABRILLO_POWER
| CATEGORY-POWER
| HIGH
| LOW
| QRP
|}

{|class="wikitable"
|+style="text-align:Left;"|Default relation between contest mode category and Cabrillo export 
!'''Key type'''
!'''DXLog Key'''
!'''Cabrillo key'''
!colspan="5" | '''Default values'''
|-
| Configuration
| CATEGORY_MODES
|
| style="width:170px;" | CW
| style="width:170px;" | SSB
| style="width:170px;" | Mixed
|-
| Cabrillo
| N/A
| CATEGORY-MODE
| CW
| SSB
| MIXED
|}

{|class="wikitable"
|+style="text-align:Left;"|CATEGORY_MODE to CATEGORY-MODE mapping
!'''Value of CATEGORY_MODE'''
!'''Resulting CATEGORY-MODE'''
|-
| Phon*
| SSB
|-
| SSB
| SSB
|-
| FM
| FM
|-
| AM
| AM
|-
| CW
| CW
|-
| RTTY*
| RTTY
|-
| FT*
| DIGI
|-
| Digi*
| DIGI
|-
| *PSK*
| BPSK
|-
| All others
| MIXED
|-

{|class="wikitable"
|+style="text-align:Left;"|Default relation between available contest QSO modes and Cabrillo export 
!'''Key type'''
!'''DXLog Key'''
!'''Cabrillo key'''
!colspan="5" | '''Default values'''
|-
| Configuration
| MODES
|
| style="width:150px;" | CW
| style="width:150px;" | SSB
|-
| Cabrillo
| CABRILLO_MODES
| style="width:150px;" | QSO
| CW
| PH
|}

{|class="wikitable"
|+style="text-align:Left;"|Default relation between contest band category and Cabrillo export 
!'''Key type'''
!'''DXLog Key'''
!'''Cabrillo key'''
!colspan="6" | '''Default values'''
|-
| Configuration
| BANDS
| style="width:130px;" |
| style="width:130px;" | 160
| style="width:130px;" | 80
| style="width:130px;" | 40
| style="width:130px;" | 20
| style="width:130px;" | 15
| style="width:130px;" | 10
|-
| Cabrillo
| style="width:130px;" | N/A
| style="white-space: nowrap;" | CATEGORY-BAND
|colspan="7" | Value is determined automatically for single operator entries. For multi-operator entries it is always ALL.
|}

=== De-facto standard Cabrillo QSO line ===

[[image:cabrilloqsocolumns.png]]

{|class="wikitable"
|+style="text-align:Left;"| De-facto standard Cabrillo mode codes
| '''Cabrillo'''
| '''Mode'''
|-
| AM
| AMTOR
|-
| AX
| Packet AX.25
|-
| CO
| Contestia
|-
| CW
| CW
|-
| DO
| Domino
|-
| FM
| FM
|-
| HE
| Hellschreiber
|-
| MF
| MFSK16
|-
| OL
| Olivia
|-
| PH
| SSB, AM
|-
| PM
| PSK63
|-
| PO
| PSK125
|-
| PS
| PSK31
|-
| PT
| PACTOR
|-
| RM
| RTTYM
|-
| RY
| RTTY
|-
| TH
| THROB
|-
| TV
| SSTV
|-
|}

==Band and mode keys==

{|class="wikitable"
|+style="text-align:Left;"|
| '''BANDS'''
| A semicolon-separated list of allowed bands for the contest. Valid band names are: 2190, 630, 560, 160, 80, 60, 40, 30, 20, 17, 15, 12, 10, 50, 70, 144, 222, 432, 902, 1296, 2300, 3400, 5650, 10G, and 24G.
| Default value: 160;80;40;20;15;10
|-
| '''MODES'''
| A semicolon-separated list of modes allowed in the contest. Not to be confused with CATEGORY_MODES.
| Default value: CW;SSB
|-
| '''EDI_BANDS'''
| A semicolon-separated list of EDI values for bands specified in BANDS key. Must contain same number of entries as BANDS key. Used for generating EDI log files for VHF/UHF/SHF contests in IARU Region I. Valid values are: 28 MHz, 50 MHz, 70 MHz, 144 MHz, 432 MHz, 1,3 GHz, 2,3 GHz, 3,4 GHz, 5,7 GHz, 10 GHz, 24 GHz, 47 GHz, 76 GHz, 120 GHz, 144 GHz, and 248 GHz. Note the space between the number and the frequency multiplier and that commma is used as decimal separator. '''Very important: To support EDI export the <tt>SCORE</tt> key must contain BAND.'''
| No default value and if not set, EDI export is disabled.
|-
| '''DISPLAY_MODE_GROUPING'''
| Formatting of display of modes in check multiplier window. Should always be used if <tt>DOUBLE_QSO_MODE_CHECK=PER_MODE_GROUP</tt> is used. Syntax: <tt>DISPLAY_MODE_GROUPING=modename1:mode1+mode2;modename2:mode3+mode4</tt> Tip: An emtpy mode name can be used to avoid showing modes with per band multipliers.
| No default value
|}

==QSO entry field definition keys==

{|class="wikitable"
|+style="text-align:Left;"|These keys are used to control the layout and behavior of QSO entry fields. The keys set the visibility, length, labels, checking procedures etc. for each of the fields which the user can enter data or display for any QSO.
| '''FIELD_AZ_VISIBLE'''
| Controls the visibility of the Azimuth field. Mostly used on VHF/UHF/SHF to get the azimuth angle from a gridsquare. Valid values are YES and NO.
| Default value: NO
|-
| '''FIELD_CALLSIGN_GRID_CHECK'''
| If YES, an entry in the log callsign field be checked for a gridsquare entry. If a gridsquare closer than 4000km away is found, the callsign field value be copied to the gridsquare entry field and the azimuth angle be calculated and shown. Recommended for VHF/UHF contests where you turn your antenna a lot. Valid values are YES and NO.
| Default value: NO
|-
| '''FIELD_DISPLAYED_EXCHANGE'''
| Controls which of several exchange elements is displayed in the bandmap. With -1, the first static exchange element is displayed. With 0, 1, 2, or 3, Rcvd, Recinfo, Recinfo2, or Recinfo3 is displayed, respectively. Valid values are -1, 0, 1, 2, or 3.
| Default value: -1
|-
| '''FIELD_MODE_VISIBLE'''
| If YES, or MIXED and contest mode category name contains "mixed" or "digi", overrides menu option <code><nowiki>Options|Log|Always show mode in QSO lines</nowiki></code> and makes the mode column always visible in the log. If NO, has no effect. Valid values are YES, NO, and MIXED.
| Default value: NO
|-
| '''FIELD_MODE_NAME'''
| Heading for mode column.
| Default value: "Mode"
|-
| '''FIELD_MULT_NAME'''
| Heading for multiplier column.
| Default value: "Mult"
|-
| '''FIELD_MULT_VISIBLE'''
| If MULT field is visible on the screen. Valid values are YES and NO.
| Default value: YES
|-
| '''FIELD_MULT_MAX_LENGTH'''
| Width of MULT column.
| Default value: 5
|-
| '''FIELD_NR_VISIBLE'''
| If sent QSO SERIAL NUMBER is visible on the QSO entry line. Valid values are YES and NO.
| Default value: NO
|-
| '''FIELD_NR_HIDDEN_DXCC'''
| Semicolon separated list of DXCC. If our own DXCC is on this list, sent serial number field be hidden. Useful for contests where some stations are sending a serial number exchange and other stations are sending other data (for example a local province).
| Default is to hide none
|-
| '''FIELD_NR_HIDDEN_RGX'''
| Semicolon separated list of regular expressions. If one of the expressions are valid, sent serial number field be hidden. Useful for contests where some stations are sending a serial number exchange and other stations are sending other data (for example a local province).
| No default value
|-
| '''FIELD_PERIOD_VISIBLE'''
| If PERIOD number column is visible. Valid values: YES and NO.
| Default value: NO
|-
| '''FIELD_PERIOD_NAME'''
| Heading for PERIOD number column.
| Default value: "P"
|-
| '''FIELD_PTS_VISIBLE'''
| If POINTS column is visible. Valid values: YES and NO.
| Default value: YES
|-
| '''FIELD_PTS_NAME'''
| Heading for POINTS column. Width of column scales with string.
| Default value: "Pts"
|-
| '''FIELD_RCVD_CHECK_FORMAT_FX'''
| C# expression to reformat entered value in the field before further validity checking. The value in the field is represented as $FIELDVALUE. Example: <tt>FIELD_RCVD_CHECK_FORMAT_FX=$FIELDVALUE.Substring(0,2)+$FIELDVALUE.Substring(2).TrimStart('0')</tt> reshape RCVD by taking the first two characters and then remove any leading zeroes in the remainder before further validity or multiplier checking.
| Default value: $FIELDVALUE
|-
| '''FIELD_RECINFO_CHECK_FORMAT_FX''' '''FIELD_RECINFO2_CHECK_FORMAT_FX''' '''FIELD_RECINFO3_CHECK_FORMAT_FX'''
| One or several, semicolon separated, regular expressions to conditionally reformat the entered value in the field before further validity checking. The regular expression and the formatting expression are separated by ">>" as in CABRILLO_LINE. The entered value is represented as $FIELDVALUE. Example: <tt><nowiki>FIELD_RECINFO_CHECK_FORMAT_FX=!DEST->DXCC:^YO$>>'.'+$FIELDVALUE</nowiki></tt> add a period before the second part of the exchange for all stations that are not from Romania. <tt><nowiki>FIELD_RECINFO_CHECK_FORMAT_FX=!DEST->DXCC:^K$|^KL$|^KH6$|^VE$>>""</nowiki></tt> ignore any value in the second exchange field for all stations not from US, Hawaii, Alaska, or Canada.
| Default value: ALL>>$FIELDVALUE
|-
| '''FIELD_RCVD_COPY''' '''FIELD_RECINFO_COPY''' '''FIELD_RECINFO2_COPY''' '''FIELD_RECINFO3_COPY'''
| If the field's value is automatically copied from previous QSO with same station. Also controls if the exchange is shown with callsign in bandmap when <code><nowiki>Display options|Exchange</nowiki></code> is selected. Valid values: YES and NO.
| Default value: NO
|-
| '''FIELD_RCVD_COPY_EXC_DXCC''' '''FIELD_RECINFO_COPY_EXC_DXCC'''
| Semicolon separated list DXCC entities for which RCVD/RECINFO is copied from earlier QSO in spite of FIELD_RCVD_COPY/FIELD_RECINFO_COPY=NO. Useful in case only some DXCC have a fixed exchange in the contest.
| Default value: NONE
|-
| '''FIELD_RCVD_COPY_EXC_RGX''' '''FIELD_RECINFO_COPY_EXC_RGX'''
| Semicolon separated list of regular expressions. For QSO where any of the conditions are true, the content of the field be copied from earlier QSO in spite of FIELD_RCVD_COPY/FIELD_RECINFO_COPY=NO. Useful if only certain types of exchanges are fixed for stations in contest.
| No default value
|-
| '''FIELD_RCVD_COPY_FX'''
| C# expression used to determine value to be copied from earlier QSO. The value of the field is $FIELDVALUE. For example: <tt>FIELD_RCVD_COPY_FX=$FIELDVALUE.Substring(0,6)</tt> copy the first six characters from the RCVD field from the previous QSO with the same station.
| Default value: $FIELDVALUE
|-
| '''FIELD_RCVD_DEFAULT_VALUE'''
| Value to be used in as prefill if RCVD field is empty. Valid values are: CQZONE, ITUZONE, CONT, or any string, which be used verbatim.
| No default value
|-
| '''FIELD_RCVD_EXC_CHECK_DXCC'''
| List of destination DXCC countries separated by ":" (or keyword ALL for all) for which multiplier list validity checking is enforced. E.g. <tt>FIELD_RCVD_EXC_CHECK_DXCC=K:KL:KH6:VE:XE;CUSTOM_MULT_LIST</tt> Note that this key only applies to <tt>FIELD_RCVD_TYPE=MULT</tt>. Also note that this key does not override <tt>FIELD_RCVD_RGX_CHECK</tt>, so if used, this key needs to accept all possible values of RCVD. E.g. <tt><nowiki>FIELD_RCVD_RGX_CHECK=DEST->RCVD:^[0-8][0-9]?$|^90$;DEST->RCVD:CUSTOM_MULT_LIST</nowiki></tt> '''Important:''' There is no such key for <tt>RECINFO</tt> etc. since validity checking is automatic for those of MULT type.
| No default value
|-
| '''FIELD_RCVD_FORMAT_FX''' '''FIELD_RECINFO_FORMAT_FX''' '''FIELD_RECINFO2_FORMAT_FX''' '''FIELD_RECINFO3_FORMAT_FX'''
| C# expression used to format entered value before saving.
| No default value
|-
| '''FIELD_RCVD_FX_CHECK''' '''FIELD_RECINFO_FX_CHECK''' '''FIELD_RECINFO2_FX_CHECK''' '''FIELD_RECINFO3_FX_CHECK'''
| Boolean C# expression used to check if value entered in the field is valid. For example: <tt>FIELD_RCVD_FX_CHECK=Helpers.Between($FIELDVALUE,1,40)</tt> checks if RCVD is between 1 and 40.
| No default value
|-
| '''FIELD_RCVD_MANDATORY''' '''FIELD_RECINFO_MANDATORY''' '''FIELD_RECINFO2_MANDATORY''' '''FIELD_RECINFO3_MANDATORY'''
| If RCVD field entry is mandatory. Valid values are YES and NO.
| Default value: NO
|-
| '''FIELD_RCVD_MANDATORY_RGX_EXC''' '''FIELD_RECINFO_MANDATORY_RGX_EXC''' '''FIELD_RECINFO2_MANDATORY_RGX_EXC''' '''FIELD_RECINFO3_MANDATORY_RGX_EXC'''
| Defines exceptions from mandating rule via a regular expression. For example: <tt><nowiki>FIELD_RCVD_MANDATORY_RGX_EXC=!DEST->DXCC:^(G|GD|GI|GJ|GM|GU|GW)$</nowiki></tt> means RCVD is not mandatory for non-UK stations. You can only have one exception per entry field.
| No default value
|-
| '''FIELD_RCVD_MAX_LENGTH'''
| Maximum number of characters accepted in the field.
| Default value: 10
|-
| '''FIELD_RECINFO_MAX_LENGTH''' '''FIELD_RECINFO2_MAX_LENGTH''' '''FIELD_RECINFO3_MAX_LENGTH'''
| Maximum number of characters accepted in the field.
| Default value: 6
|-
| '''FIELD_RCVD_MIN_LENGTH''' '''FIELD_RECINFO_MIN_LENGTH''' '''FIELD_RECINFO2_MIN_LENGTH''' '''FIELD_RECINFO3_MIN_LENGTH'''
| Minimum number of characters accepted in the field.
| Default value: 0
|-
| '''FIELD_RCVD_NUMERIC''' '''FIELD_RECINFO_NUMERIC''' '''FIELD_RECINFO2_NUMERIC''' '''FIELD_RECINFO3_NUMERIC'''
| Controls if the field accepts only numeric characters. Valid values are YES and NO.
| Default value: NO
|-
| '''FIELD_RCVD_NAME'''
| Column heading for RCVD field.
| Default value: Rcvd
|-
| '''FIELD_RCVD_SLASH_ALLOWED''' '''FIELD_RECINFO_SLASH_ALLOWED''' '''FIELD_RECINFO2_SLASH_ALLOWED''' '''FIELD_RECINFO3_SLASH_ALLOWED'''
| Controls if the field accepts a slash "/" character. Valid values are YES and NO.
| Default value: NO
|-
| '''FIELD_RCVD_RGX_CHECK'''
| Semicolon separated list of logical expressions for entry validity checking. For contests with more than one type of exchange (e.g. grid and serial number or oblast and grid), more than one rule can be listed, separated by semicolon. The check is then done against the rules combined with logical OR, i.e. if any of the rules checks OK, the entry is approved.
| No default value
|-
| '''FIELD_RECINFO_RGX_CHECK''' '''FIELD_RECINFO2_RGX_CHECK''' '''FIELD_RECINFO3_RGX_CHECK'''
| A single regular expression for entry validity checking.
| No default value
|-
| '''FIELD_RCVD_TYPE'''
| Defines data type of the field. Valid values are: GRID, GRID4, GRID6, CONT, NR, CUSTOM (any text), MULT (a listed keyword, associated with <tt>MULT#_TYPE=CUSTOM</tt>), CQZONE, ITUZONE, and NAME. Note that there is no automatic validity checking for CUSTOM, CQZONE, NAME, and ITUZONE. Validity checking of MULT is enabled using the key <tt>FIELD_RCVD_EXC_CHECK_DXCC</tt>. This means a <tt>FIELD_RCVD_RGX_CHECK</tt> or key may be required. The type can also be per-DXCC using the syntax <tt>DXCC:regex=type1;!DXCC:regex=type2</tt> where regex is matched against the station's main DXCC prefix and can be e.g. <tt><nowiki>^(JA|JD/o|JD/m)$</nowiki></tt> '''Important:''' Since the types are used to determine e.g. ADIF export, only use NAME for a real name and only use NR for the exchange serial number.
| Default value: Empty
|-
| '''FIELD_RECINFO_TYPE''' '''FIELD_RECINFO2_TYPE''' '''FIELD_RECINFO3_TYPE'''
| Defines data type of the field. Valid values are: GRID, GRID4, GRID6, NR, CONT, CUSTOM, MULT, CQZONE, ITUZONE, and NAME. There is an automatic validity check on all types except CUSTOM and NAME. '''Important:''' Since the types are used to determine e.g. ADIF export, only use NAME for a real name and only use NR for the exchange serial number.
| Default value: Empty
|-
| '''FIELD_RCVD_GRID_CHECK'''
| If YES, entry in RCVD field be checked if it can be possible gridsquare entry. It it is gridsquare, then RCVD field value be moved to the RECINFO entry field and Azimuth be calculated and shown. Valid values are YES and NO.
| Default value: NO
|-
| '''FIELD_RECINFO_NAME''' '''FIELD_RECINFO2_NAME''' '''FIELD_RECINFO3_NAME'''
| Heading for field's column.
| Default value: Empty
|-
| '''FIELD_RECINFO_RGX_SEL_POS''' '''FIELD_RECINFO2_RGX_SEL_POS''' '''FIELD_RECINFO3_RGX_SEL_POS'''
| Filtering function for composite multipliers. Exact function is unclear.
| No default value
|-
| '''FIELD_RECINFO_VISIBLE''' '''FIELD_RECINFO2_VISIBLE''' '''FIELD_RECINFO3_VISIBLE'''
| Controls if the the field is visible. Valid values: YES, NO, HIDDEN, and READONLY.
| Default value: NO
|-
| '''FIELD_RST_3RD_LETTER'''
| Semicolon-separated list of allowed third characters apart from numbers. For example: <tt>FIELD_RST_3RD_LETTER=A;S</tt> allows 59A and 59S as reports.
| Default value: None
|-
| '''FIELD_RST_VISIBLE'''
| Controls visibility of RST field. Valid values are: YES and NO.
| Default value: YES
|-
| '''FIELD_SENT_VISIBLE'''
| Controls visibility of Sent field in log. Valid values are: YES and NO.
| Default value: YES
|-
|}

==Default message keys==

{|class="wikitable"
|+style="text-align:Left;"|Default messages for F-keys, Plus and Ins.
| '''Message'''
| '''Usage'''
| '''Default value'''
|-
| '''CW_MESSAGE_1'''
| Default F1 message for Run
| <nowiki>"CQ $MYCALL $MYCALL TEST"</nowiki>
|-
| '''CW_MESSAGE_2'''
| Default F2 message for Run
| "$RST $EXCHANGE"
|-
| '''CW_MESSAGE_3'''
| Default F3 message for Run
| "$EXCHANGE"
|-
| '''CW_MESSAGE_4'''
| Default F4 message for Run
| "$MYCALL"
|-
| '''CW_MESSAGE_5'''
| Default F5 message for Run
| "$LOGGEDCALL"
|-
| '''CW_MESSAGE_6'''
| Default F6 message for Run
| "AGN?"
|-
| '''CW_MESSAGE_7'''
| Default F7 message for Run
| "?"
|-
| '''CW_MESSAGE_INS'''
| Default Insert message for Run
| "$F2"
|-
| '''CW_MESSAGE_PLUS'''
| Default Plus message for Run
| "$CORRECT TU $CR $MYCALL"
|-
| '''SP_CW_MESSAGE_1'''
| Default F1 message for S&P
| "$MYCALL"
|-
| '''SP_CW_MESSAGE_2'''
| Default F2 message for S&P
| "$RST $EXCHANGE"
|-
| '''SP_CW_MESSAGE_3'''
| Default F3 message for S&P
| "$EXCHANGE"
|-
| '''SP_CW_MESSAGE_4'''
| Default F4 message for S&P
| "$MYCALL"
|-
| '''SP_CW_MESSAGE_5'''
| Default F5 message for S&P
| "$LOGGEDCALL"
|-
| '''SP_CW_MESSAGE_6'''
| Default F6 message for S&P
| "AGN?"
|-
| '''SP_CW_MESSAGE_7'''
| Default F7 message for S&P
| "?"
|-
| '''SP_CW_MESSAGE_INS'''
| Default Insert message for S&P
| "$F2$CR"
|-
| '''SP_CW_MESSAGE_PLUS'''
| Default Plus message for S&P
| "TU$CR"
|-
| '''CW_MESSAGE_EXCHANGE_FILTER'''
| Controls selection of alternative standard messages
|
|-
|}

Message definitions following the <tt>CW_MESSAGE_EXCHANGE_FILTER</tt> key will only be effective if regular expression after equal sign evaluates true for content in exchange entry box. Example: <tt>CW_MESSAGE_EXCHANGE_FILTER=^DX$</tt> means that messages below this line will be used for stations entering DX in the exchange entry box. '''Important:''' Only has effect for the first log created or when the Defaults button is clicked in the Standard messages panel. All subsequent logs for the same contest will inherit the messages from the previous log.

==Additional configuration keys==

=== DXCC related keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''DXCC_DB_TYPE'''
| This entry allows the use of a custom country file (for example, R150S.dat). If a custom country file is defined, the selection in <tt><nowiki>Option|Data files|Country files</nowiki></tt> will be ignored and the country file defined in the contest config file will be used. Valid values are: <tt>CUSTOM_CTY</tt> and <tt>CTY</tt>
|Default value is CTY which will use the data base set in the <tt><nowiki>Options|Data files|Country files</nowiki></tt> panel.
|-
| '''DXCC_DB_FILENAME'''
| Used to enable the use of an alternative country data base. Used in conjunction with the <tt>DXCC_DB_TYPE</tt> key to define the data file name. The file format is the same as the normal <tt>CTY.DAT</tt> file.
| Default value: <tt>CTY.DAT</tt>
|-
| '''DXCC_DB_USE_ARRL_LIST'''
| Controls the use of the ARRL country list instead of CQ/WAE country list. Valid values: YES and NO.
| Default value: NO
|}

=== Contest timing and period keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''MIN_OFF_TIME'''
| Minimum time in minutes without QSO to count as off time. C.f. OFF_TIME_ROUND_UP.
| style="white-space: nowrap;" | Default value: 30
|-
| '''OFF_TIME_ROUND_UP'''
| Off time is calculated based on time difference between QSO instead of minutes without QSO. YES means that QSO at e.g. 4:12 and 5:12 represents 60 minutes of off time. NO means that QSO at e.g. 4:12 and 5:13 represents 60 minutes of off time. Valid values: YES and NO.
| Default value: NO
|-
| '''CONTEST_LENGTH'''
| Duration of contest in minutes. Ignored for contests without periods.
| No default value
|-
| '''CONTEST_FIRST_HOUR'''
| Time of day for start of contest in UTC. Ignored for contests without periods. If the value is negative, DXLog will assume the contests starts a the beginning of the current hour. Valid formats: -1, H, HH, HMM, and HHMM.
| No default value
|-
| '''PERIOD'''
| Whether the contest has periods. Valid values: ON and OFF.
| style="white-space: nowrap;" | Default value: OFF
|-
| '''PERIOD_LENGTH'''
| The length of each contest period in minutes. Valid values: Any integer.
| Default value: 0
|-
| '''PERIOD_AUTOSWITCH'''
| If the next period should start automatically. '''Important: Does not work if contests stretches past midnight UTC.''' Valid values: YES and NO.
| Default value: NO
|-
| '''PERIOD_NUMBER'''
| Number of periods in contest. CALC_FROM_TIME means duration divided by period length. Valid values: CALC_FROM_TIME or any integer. '''Important:''' When CALC_FROM_TIME is used, it must be preceded by CONTEST_LENGTH and PERIOD_LENGTH.
| Default value: 0
|-
| '''PERIOD_MODES'''
| Optional, semicolon-separated list of modes for each period in the contest. Must have the same number of items as number of periods. Valid values: Mode acronyms supported by DXLog.
| No default value
|-
|}

=== Database, prefill, and check keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''DB_FILE''' or '''DB_FILE1''' '''DB_FILE2''' '''DB_FILE3''' '''DB_FILE4''' '''DB_FILE5'''
| File name of prefill data base. '''Important: File name casing must be correct for online update to work.''' For file format etc., see the [[Menu_Options#Prefill_database_settings|Prefill database settings]] section.
|
|-
| '''DB_FILE_TYPE''' or '''DB_FILE1_TYPE''' '''DB_FILE2_TYPE''' '''DB_FILE3_TYPE''' '''DB_FILE4_TYPE''' '''DB_FILE5_TYPE'''
| Extension of data base file.
| style="white-space: nowrap;" | Default value: TXT
|-
| '''DB_FILE_COL_RCVD''' or '''DB_FILE1_COL_RCVD''' '''DB_FILE2_COL_RCVD''' '''DB_FILE3_COL_RCVD''' '''DB_FILE4_COL_RCVD''' '''DB_FILE5_COL_RCVD'''
| Column number of RCVD field in data base file. '''Important: At least one DB_FILE_COL* statement must be included for each data base file.''' '''Important: Since look-up for RCVD is enabled by default, it needs to be actively disabled if not wanted. Set it to -1 to disable undesired look-up. '''
|
|-
| '''DB_FILE_COL_RECINFO''' or '''DB_FILE1_COL_RECINFO''' '''DB_FILE2_COL_RECINFO''' '''DB_FILE3_COL_RECINFO''' '''DB_FILE4_COL_RECINFO''' '''DB_FILE5_COL_RECINFO'''
| Column number of RECINFO field in data base file.
|
|-
| '''DB_FILE_COL_RECINFO2''' or '''DB_FILE1_COL_RECINFO2''' '''DB_FILE2_COL_RECINFO2''' '''DB_FILE3_COL_RECINFO2''' '''DB_FILE4_COL_RECINFO2''' '''DB_FILE5_COL_RECINFO2'''
| Column number of RECINFO2 field in data base file.
|
|-
| '''DB_FILE_COL_RECINFO3''' or '''DB_FILE1_COL_RECINFO3''' '''DB_FILE2_COL_RECINFO3''' '''DB_FILE3_COL_RECINFO3''' '''DB_FILE4_COL_RECINFO3''' '''DB_FILE5_COL_RECINFO3'''
| Column number of RECINFO3 field in data base file.
|
|-
| '''DB_FILE_FILL_FORMAT''' or '''DB_FILE1_FILL_FORMAT''' '''DB_FILE2_FILL_FORMAT''' '''DB_FILE3_FILL_FORMAT''' '''DB_FILE4_FILL_FORMAT''' '''DB_FILE5_FILL_FORMAT'''
| C# <code>string.Format</code> expression defining how prefill from data base file will be used. Example: <tt>/{0}</tt> will precede prefill with a slash. This function is often combined with the menu option to use INSERT mode in the RCVD field.
|
|-
| '''RGX_GUESS_DB'''
| Regular expression "rule base" for guessing exchange of unworked stations. Syntax is <tt>RGX_GUESS_DB=Field;DXCC Regex;Callsign Regex2;Filename[;Result regex]</tt>. A look-up is done for stations fulfilling at least one of the regular expressions. An empty regular expression or "ALL" matches everything and "NONE" never matches. If the Result regex is used, the look-up only returns values that matches it. The syntax of the file is callsign regex=prefill, DXCC:regex=prefill, !DXCC:regex=prefill, CONT:regex=prefill, or !CONT:regex=prefill where "prefill" is either a literal string or <tt>$DXCC</tt>, <tt>$CONT</tt>, <tt>$ITUZONE</tt>, or <tt>$CQZONE</tt>. The file is parsed from top to bottom and the first match is used.
|
|-
| '''DXC_COMMENT_EXTRACT'''
| This entry is used to extract exchange or multiplier information from DX cluster comments. For example, the line: <tt><nowiki>DXC_COMMENT_EXTRACT=RECINFO;(AF|AN|AS|EU|NA|OC|SA)[ /\-\.]?\d{1,3};[ /\-\.]</nowiki></tt> will extract a typical IOTA designation such as AF-025 and insert it into the <tt>RECINFO</tt> prefill field for the spot. The first part of the configuration (before the ;) defines into which entry field the data should be placed. The second part of the configuration is a regular expression that defines the data that is to be matched. The third part defines which characters should be removed from the matched result. It is mandatory but can be empty. A fourth part is optional. It is a regular expression and all comments matching it are ignored. This can, for instance, be used to ignore skimmer spots. '''Important''': All comments are converted to upper case before comparison.
|
|-
| '''CALLSIGN_EXTRACT'''
| This entry is used to extract exchange information from an entered or spotted callsign. For example, the line: <tt><nowiki>CALLSIGN_EXTRACT=RCVD;/(ABC|DEF|KIJ)$;[/]</nowiki></tt> will extract the string after the slash into the RCVD field into the entry line or in the spot. The first part of the configuration (before the ;) defines into which entry field the data should be placed. The second part of the configuration is a regular expression that defines the data that is to be matched. The third part defines which characters should be removed from the matched result. It is mandatory but can be empty.
|
|-
| '''SCP_DATABASE_DISABLE'''
| Disable file-based prefill and check partials database. (for e.g., WRTC). Valid values are: YES and NO or a semicolon separated list of YES or NO with the same number of elements as defined contest categories.
| Default value: NO
|-
| '''DB_SCP_FROM_EXCHANGE'''
| Enables reverse look-up. Searches for all instances of either RCVD or RECINFO in first and second column of all data base files. Search is triggered when pressing space and all entry fields are empty except either RCVD or RECINFO. Search hits are displayed in Check Partials window.
| Default value: NO
|-
|}

=== QSO exchange and numbering keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''INITIAL_SERIAL_NUMBER'''
| Starting value of sent serial number.
| Default value: 1
|-
| '''QSO_NUMBER'''
| QSO numbering principle. Valid values: ALL, PER_MODE, PER_BAND, PER_PERIOD, PER_BAND_MODE, PER_PERIOD_MODE. ALL means chronological numbering.
| Default value: ALL
|-
| '''QSO_NUMBER_CATEGORY'''
| Semicolon-separated list of numbering principles for each contest category. Must contain the same number of elements as contest categories. Valid values: ALL, PER_MODE, PER_BAND, PER_PERIOD, PER_BAND_MODE, PER_PERIOD_MODE.
| If absent, the value of QSO_NUMBER is used.
|-
| '''FIRST_PREV_RCVD'''
| Initial return value of macro $PREV_RCVD. Any string is allowed but also the keyword <tt>EXCHANGE</tt>
| style="white-space: nowrap;" | Default value: "000"
|-
| '''FIRST_PREV_RECINFO'''
| Initial return value of macro $PREV_RECINFO. Any string is allowed but also the keyword <tt>EXCHANGE</tt>
| Default value: "000"
|-
| '''FIRST_PREV_RECINFO2'''
| Initial return value of macro $PREV_RECINFO2. Any string is allowed but also the keyword <tt>EXCHANGE</tt>
| Default value: "000"
|-
| '''FIRST_PREV_RECINFO3'''
| Initial return value of macro $PREV_RECINFO3. Any string is allowed but also the keyword <tt>EXCHANGE</tt>
| Default value: "000"
|-
| '''SLASH_MULTIPLE_QSOS'''
| Controls whether slashed ("/") multipliers in sent and received exchanges are scored as separate QSO.
| Default value: NO
|-
|}

=== Duplicate QSO keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''DOUBLE_QSO'''
| The definition of a dupe. Valid values: PER_PERIOD, PER_BAND, PER_MODE, PER_PERIOD_BAND, PER_PERIOD_MODE, PER_BAND_MODE, PER_BAND_MODE_RECINFO, PER_BAND_MODE_RCVD, PER_BAND_MODE_RCVD_DAY, PER_PERIOD_BAND_MODE, PER_MINUTE_DIFFERENCE, PER_BAND_DAY '''Important: ALL is not a valid value.'''
| PER_BAND
|-
| '''DOUBLE_QSO_MINUTE_DIFFERENCE'''
| Minimum time difference in QSO time to not be counted as a dupe. Used in conjunction with DOUBLE_QSO=PER_MINUTE_DIFFERENCE.
| Default value: 0
|-
| '''DOUBLE_QSO_MODE_CHECK'''
| Definition of dupe principle when it comes to mode. Valid values: PER_MODE, PER_CABRILLO_MODE, and PER_MODE_GROUP. '''Important''': When not using PER_MODE, only use CW, Phone, Digital, and Mixed for CATEGORY_MODES values.
| style="white-space: nowrap;" | Default value: PER_MODE
|-
| '''DOUBLE_QSO_RULE_DURATION'''
| Expiration time of dupe QSO rule. Cannot be used together with DOUBLE_QSO=PER_MINUTE_DIFFERENCE or MIN_VALID_QSO_DIFFERENCE.
| Default value: 0
|-
| '''MIN_VALID_QSO_DIFFERENCE'''
| Minimum allowed time between QSO with the same station (on e.g., another mode). Once this time has passed, the regular dupe rules apply. Cannot be used together with DOUBLE_QSO=PER_MINUTE_DIFFERENCE or DOUBLE_QSO_RULE_DURATION.
| Default value: 0
|-
| '''MODE_GROUP'''
| Semicolon-separated list of mode group names. Used as an alternative to CABRILLO_MODES to group modes together for special dupe rules. One list entry per MODES mode entry. Valid group names are CW, SSB, FM, PH, and DG.
| No default value
|-
|}

=== Multiplier keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''MULT_SUM'''
| Summing method for multipliers. Valid values: NO, ALL, PER_BAND, and PER_PERIOD.
| Default value: ALL
|-
| '''OWN_MULT_VALID'''
| Controls if own multiplier is valid. '''Important:''' Controls the validity of ALL own multipliers but does not consider calculated or derived multipliers, e.g. DXCC or WPX. This means that for the NO option to work, the own multiplier must be specified in the Exchange field in the contest configuration window and only this multiplier will not count.
| Default value: NO
|-
| '''CUSTOM_MULT_LENGTH'''
| Length of an enumerated numeric multiplier. If number is shorter, it is left padded with zeroes. Used with enumerated multipliers, e.g. "=1-1999".
| Default value: 0
|-
| '''CONTINENT_LIST'''
| Custom, semicolon-separated continent list. Syntax is: <tt>CONTINENT_LIST=</tt>''continent1;continent2;continent3''
| Default value: EU;NA;SA;AS;AF;OC
|-
| '''MULT1_CONT_LIST''' '''MULT2_CONT_LIST''' '''MULT3_CONT_LIST'''
| Custom, semicolon-separated continent list. Syntax is: <tt>MULT1_CONT_LIST=</tt>''continent1;continent2;continent3''
| Default value: EU;NA;SA;AS;AF;OC
|-
| '''MULT1_TYPE''' '''MULT2_TYPE''' '''MULT3_TYPE'''
| Multiplier type. Can be <tt>CALLSIGN, DXCC, CQZONE, WPX, CUSTOM, HQ, NUM, FIELD, LASTLETTER, LETTER1</tt>, or <tt>FX</tt>. <tt>FX</tt> is a calculated multiplier and requires an <tt>MULT#_FX</tt> key. <tt>CUSTOM</tt> requires an explicit multiplier list. For contests with more than one multiplier, the use of LIVESCORE_MULT may be necessary for correct reporting. Check [https://contestonlinescore.com/settings/ here] for valid live score multiplier attributes and below for more details about how to use the types.
| Default value: None
|-
| '''MULT1_FX''' '''MULT2_FX''' '''MULT3_FX'''
| A C# expression used to create the effective value of an <tt>FX</tt> type multiplier. The entered string is available in the object <tt>$FIELDVALUE</tt>. For example <tt>MULT1_FX=$FIELDVALUE.Substring(0,$FIELDVALUE.IndexOf('/'))</tt> will make the characters before the slash the actual multiplier.
|
|-
| '''MULT1_COUNT''' '''MULT2_COUNT''' '''MULT3_COUNT'''
| Counting method for <tt>MULT1, MULT2</tt>, and <tt>MULT3</tt>. Can be <tt>PER_BAND, PER_PERIOD, PER_MODE, PER_BAND_MODE, PER_PERIOD_MODE, PER_PERIOD_BAND, PER_PERIOD_BAND_MODE,</tt> or <tt>ALL</tt>. '''Important:''' Do not use e.g. <tt>PER_BAND</tt> for a single band contest or <tt>PER_MODE</tt> for a single mode contest.
| Default value: None
|-
| '''MULT1_ADD_DXCC''' '''MULT2_ADD_DXCC''' '''MULT3_ADD_DXCC'''
| Only used with multiplier type <tt>HQ</tt>. Adds an asterisk and the DXCC entities main prefix to the entered string. Can be reversed using the multiplier exception <tt>REMOVE_DXCC</tt>. Example: <tt>MULT2_EXCEPTION=DEST->RCVD:^R[1-3]$;REMOVE_DXCC</tt> means that HQ stations sending R1, R2, or R3 as exchange will not count for DXCC multipliers. Valid values: YES and NO.
| Default value: NO
|-
| '''MULT1_FIELD''' '''MULT2_FIELD''' '''MULT3_FIELD'''
| Source of the multiplier string. Valid values: <tt>RCVD, CALLSIGN, FROM_DXCC, FROM_WPX, RECINFO, RECINFO2, RECINFO3,<tt> and <tt>NONE</tt>.
| Default value: None
|-
| '''MULT1_DISPLAY''' '''MULT2_DISPLAY''' '''MULT3_DISPLAY'''
| Text to show in MULT column. Syntax: MULT1_DISPLAY=''regex;string''. The ''regex'' can be omitted. Example: <tt><nowiki>MULT1_DISPLAY=DEST->DXCC:^(K|KL|KH6)$;S</nowiki></tt> Example: <tt>MULT1_DISPLAY=FN</tt>
| Default value: None
|-
| '''MULT1_BAND_BONUS''' '''MULT2_BAND_BONUS''' '''MULT3_BAND_BONUS'''
| Per band multiplier scaling factor. Syntax <tt>MULT1_BAND_BONUS=<tt>''band;scaling''. Example: <tt>MULT1_BAND_BONUS=80;2.0</tt> doubles the multiplier count for the 80m band.
| Default value: 1
|-
| '''MULT1_BONUS''' '''MULT2_BONUS''' '''MULT3_BONUS'''
| Bonus score for a defined achievement in V/U/SHF contests with EDI log submission. Example: With country defined as a "multiplier" number one, <tt>MULT1_BONUS=100</tt> will add 100 points to the total score for each new country worked. Affects the EDI keys <tt>CWWLs</tt>, <tt>CExcs</tt>, and <tt>CDXCs</tt>. '''Has no effect on on-screen scoring or Cabrillo export.'''
| Default value: 0
|-
| '''MULT1_EXCEPTION''' '''MULT2_EXCEPTION''' '''MULT3_EXCEPTION'''
| Exception from the general rule for the multiplier. Syntax: <tt>MULT1_EXCEPTION=boolean;multiplier definition</tt>. The boolean function can either be a regular expression (c.f. above) or <tt>FX()</tt> expression. Example: <tt><nowiki>MULT1_EXCEPTION=DEST->DXCC:^K$|^VE$;CUSTOM_MULT_LIST</nowiki></tt> will use the custom list (normally last in the contest definition file) to determine multipliers for US and Canadian stations. Example: <tt><nowiki>MULT1_EXCEPTION=FX("CONFIG->CALLSIGN"<>"K1DG");NONE</nowiki></tt> will not count this multiplier for anyone except Doug K1DG. However, a less roundabout way to achieve the same is <tt><nowiki>MULT1_EXCEPTION=!CONFIG->CALLSIGN:^K1DG$;NONE</nowiki></tt> For valid values, see table below.
|
|-
| '''MULT1_MULTIPLIER''' '''MULT2_MULTIPLIER''' '''MULT3_MULTIPLIER'''
| Multiplication factor for a selected value. Syntax ''value;factor''. For instance <tt>MULT1_MULTIPLIER=AZ;4</tt> means all "AZ" are worth four multipliers. One <tt>MULT1_MULTIPLIER</tt> line is required for each value of <tt>MULT1</tt> which has a multiplier but ALL matches all values.
|
|-
| '''MULT1_REPEAT''' '''MULT2_REPEAT''' '''MULT3_REPEAT'''
| Specifies a list of values of the multiplier and the number of times they count as multipliers. For instance <tt>MULT1_REPEAT=VD[3];PA[2]</tt> means the first three "VD" and the first two "PA" count as multipliers. If only a multiplier without a bracketed number is listed, the number is one. '''Important: This function is not correctly implemented in DXLog's bandmap.'''
| By default multipliers only count once
|-
| '''MULT1_CONT_LIST''' '''MULT2_CONT_LIST''' '''MULT3_CONT_LIST'''
| List used when MULT is of type CONT. '''Important: Antarctica is not included by default.'''
| Default value: EU;NA;SA;AS;AF;OC
|-
| '''MULT1_NO_ALERT''' '''MULT2_NO_ALERT''' '''MULT3_NO_ALERT'''
| Hides the multiplier and QSY alert at the bottom of the screen for the multiplier. Valid values: YES and NO.
| Default value: NO
|-
|}

'''Multiplier field considerations'''

<tt>CALLSIGN</tt> 
Ignores multiplier type for processing but a MULT#_FX key is always honored. 
Multiplier type can still be used for creating a list of valid multiplier values so 
CUSTOM can be useful for a derived multiplier (such as the last letter of a callsign). 
A dummy multiplier type CALLSIGN can be used for clarity.

<tt>FROM_DXCC</tt> 
Valid multiplier types are DXCC and FX. With DXCC, worked multipliers are displayed in the 
Worked DXCC window. With FX, the list of workable multipliers need to be defined, e.g., 
using <code>WINDOWS_CML_LIST_FX=GetList_...</code>.

<tt>FROM_WPX</tt> 
The multiplier type is ignored but a dummy type WPX can be used for clarity. Worked multipliers are 
displayed in a growing window.

'''Multiplier type considerations'''

<tt>HQ</tt> 
Like FIELD but with the exception that the multiplier will only be valid if the QSO does not 
represent a multiplier with lower number. For instance, if MULT3 is HQ, it will only be valid 
if neither MULT1 nor MULT2 are valid. A DXCC entity qualifier can be added using the 
<tt>MULT#_ADD_DXCC</tt> key, making sure the same multiplier is valid once per country. 
For example if you receive ARRL from W1AW, the multiplier's value will be "ARRL*K". 
Worked multipliers are displayed in a growing window.

<tt>CQZONE</tt> and <tt>ITUZONE</tt> 
Can be used with the RCVD, RECINFO, RECINFO2, and RECINFO3 fields. 
The set of workable multipliers is created automatically.

<tt>FX</tt> 
Can be used with the CALLSIGN, RCVD, RECINFO, RECINFO2, and RECINFO3 fields. 
The set of workable multipliers need to be defined, e.g., using <tt>WINDOWS_CML_LIST_FX=GetList_...</tt>.

<tt>FIELD</tt> 
Can be used with the RCVD, RECINFO, RECINFO2, and RECINFO3 fields. 
This is typically used for multipliers with too many possible values 
that visual tracking is infeasible. But it is still possible, 
The set of valid multiplier values is undefined by default and 
typically created using <tt>WINDOWS_CML_LIST_FX=GetList_...</tt>.

<tt>CUSTOM</tt> 
Can be used with the RCVD, RECINFO, RECINFO2, RECINFO3, and CALLSIGN fields. 
The list of valid multiplier values is created by a values listed between 
<code>[MULTIPLIERS START]</code> and <code>[MULTIPLIERS END]</code>.

<tt>NUM</tt> 
Can be used with the CALLSIGN, RCVD, RECINFO, RECINFO2, and RECINFO3 fields. 
Like FIELD but strips leading zeroes.

<tt>LASTLETTER</tt> and <tt>LETTER1</tt> 
Can be used with the CALLSIGN, RCVD, RECINFO, RECINFO2, and RECINFO3 fields. 
The list of workable multipliers is automatically created.

'''Multiplier exception considerations'''

{|class="wikitable"
|+style="text-align:Left;"|
| '''Exception'''
| '''Value when triggered'''
|-
| <tt>PFX_AREA</tt>
| The prefix area of the QSO's callsign.
|-
| <tt>WPX</tt>
| The WPX prefix of the QSO's callsign.
|-
| <tt>NONE</tt>
| An empty string, i.e., no multiplier.
|-
| <tt>CUSTOM_MULT_LIST</tt>
| The value of the multiplier, if it matches an item in the list of valid multipliers.
|-
| <tt>REMOVE_DXCC</tt>
| The value of the multiplier with a "*BBB" suffix stripped. Only meaningful for HQ multiplier.
|-
| <tt>LETTER1</tt>
| The first letter of the multiplier.
|-
| <tt>LASTLETTER</tt>
| The last letter of the multiplier.
|-
| <tt>VALUE</tt>
| The value of the multiplier.
|-
| <tt>VALUE:ABC</tt>
| The string following the colon.
|-
|}

=== Rate window keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''STATS_TYPE'''
| Type of statistics in Rate window. Valid values: STANDARD and WRTC.
| Default value: STANDARD
|-
| '''DISPLAY_TIME_ON_PER_MODE'''
| Display time on per mode in Rate window.
| Default value: NO
|-
| '''DISPLAY_LAST_MODE_CHANGE'''
| Display time of last mode change in Rate window.
| Default value: NO
|-
|}

=== Band change rule keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''BAND_MIN_LIMITS'''
| Bandwise minimum and maximum times. Only used by Bande Basse local Italian contest. Syntax: <tt>BAND_MIN_LIMITS=band;maxminutes;minfromlastqsominutes.</tt>
|
|-
| '''MULTISINGLE_RULE10_ENABLED'''
| 10-minute rule for Multi-Single operation.
| Default value: YES
|-
| '''MULTISINGLE_RULE10_FOR_MULT'''
| 10-minute rule applies to multiplier station.
| Default value: YES
|-
| '''MULTISINGLE_RULE10_MINUTES'''
| Actual number of minutes for 10-minute rule.
| Default value: 10
|-
| '''MULTISINGLE_RULE10_CHECKMODE'''
| Checking principle for 10-minute rule. Valid values: PER_BAND or PER_BAND_MODE
| style="white-space: nowrap;" | Default value: PER_BAND
|-
| '''MULTITWO_RULE10_ENABLED'''
| 10-minute rule for Multi-Two operation.
| Default value: NO
|-
| '''MULTIOP_BANDCHANGECOUNTER_ENABLED'''
| Band change counter for multi operator operation enabled.
| Default value: YES
|-
| '''MULTIOP_BANDCHANGES_ALLOWED'''
| Semicolon-separated list with number of band changes allowed in one hour in multi operator operation. Must have same number of entries as MULTIOP_BANDCHANGES_CBR_TRANSMITTERS.
| Default value: 8
|-
| '''MULTIOP_BANDCHANGES_CHECKMODE'''
| Type of counting method for band changes in multi operator operation. Valid values: PER_BAND or PER_BAND_MODE
| Default value: PER_BAND
|-
| '''MULTIOP_BANDCHANGES_TYPE'''
| Semicolon-separated list with type of band changes counted for band change rule in multi operator operation. Valid values are R, RM, or ALL. R is for M/2 and keeps two separate counters. RM is for M/1 where you have a separate counter for the Run and Multiplier stations. ALL means a single, common counter for all station types. The list must have the same number of entries as MULTIOP_BANDCHANGES_CBR_TRANSMITTERS.
| Default value: R
|-
| '''MULTIOP_BANDCHANGES_CBR_CATEGORIES'''
| Semicolon-separated list of Cabrillo operator categories subject to band change rule.
| Default value: MULTI-OP
|-
| '''MULTIOP_BANDCHANGES_CBR_TRANSMITTERS'''
| Semicolon-separated list of Cabrillo transmitter categories subject to band change rule.
| Default value: TWO
|-
|}

=== Contest score keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''SCORE'''
| Scoring principle. Valid values: BY_BAND, BY_BAND_MODE, BY_PERIOD, BY_PERIOD_BAND, and BY_PERIOD_BAND_MODE. Additional values are BY_MODE_GROUP and BY_BAND_GROUP. Their function is unknown. '''Important: BY_MODE does not exist.'''
| Default value: BY_BAND
|-
| '''SCORE_DISPLAY'''
| Displayed columns in Summary window. Available elements in their standard order: PERIOD, BAND, MODE, QSO, DUP, MULT1, MULT2, MULT3, QTC, POINTS, AVG, AVG0, and AVG1. A string within parenthesis following the element name will set the column header. Per mode display can be achieved by including the relevant mode(s) within curly brackets. Multiple modes are separated by '+'. Example: <tt>SCORE_DISPLAY=BAND;QSO(SSB){SSB};QSO(CW){CW};QSO(DIGI){RTTY+PSK31+PSK63};DUP</tt> will group all RTTY, PSK31, and PSK63 QSO under the same heading. Elements can be conditional using the <tt>*+NN:MM:LL></tt> syntax or <tt>*RGX:</tt> followed by a regular expressions (see above). Example: <tt>*-K:VE></tt> will display the column if your station is not a K or VE station. Example: <tt>*+SM:OZ:LA:OH></tt> will display the column only if you are a SM, OZ, LA, or OH station.
| Default value: BAND;QSO;DUP;MULT1(MULT);POINTS
|-

| '''SCORE_TOTAL_FX'''
| Formula for calculating total score for a QSO. Uses FLEE syntax which includes e.g. If(). Example: <tt>SCORE_TOTAL_FX=$FIELDVALUE.Points*$FIELDVALUE.Mult1+$FIELDVALUE.Mult3</tt>
| Default value: SCORE_TOTAL_FX= $FIELDVALUE.Points*($FIELDVALUE.Mult1+ $FIELDVALUE.Mult2+$FIELDVALUE.Mult3)
|-

|}

=== QSO points keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''POINTS_TYPE'''
| Type of points. Valid values: CALC, QRB, QRB_EXCHANGE+CALCF, QRB+CALCF, QRB+GRIDP2, RAEM, and FROM_TABLE() CALC expects the presence of POINTS_FIELD_BAND_MODE keys. QRB means one point per kilometer. QRB_EXCHANGE+CALCF requires at least one POINTS_CALC_F key and uses a grid in the configuration panel's Exchange field for QRB calculation. QRB only works with 6-position grids. QRB+CALCF requires at least one POINTS_CALC_F key and uses the configuration panel's Grid field for QRB calculation. RAEM uses the special RAEM contest point system. QRB+GRIDP2 is the number of large grids in distance plus two. FROM_TABLE(''filename;keytype;sourcekey;destkey'') requires a database text file that maps an exchange value to points. ''keytype'' is always INT, ''sourcekey'' is always "EXCHANGE", ''destkey'' can be RCVD, RECINFO, RECINFO2, or RECINFO3. The format of each line in the file is ''sourcekey value;destkey value=points''.
| style="white-space: nowrap;" | Default value: CALC
|-
| '''POINTS_BAND_BONUS'''
| Per band scaling factor. Syntax POINTS_BAND_BONUS=band;scaling. Example: <tt>POINTS_BAND_BONUS=160;2</tt> doubles the points number on the 160m band.
| Default value: 1 on all bands.
|-
| '''POINTS_FIELD_BAND_MODE'''
| Conditional point calculation. Syntax: <tt>POINTS_FIELD_BAND_MODE=</tt>''regex1;regex2;bandregex;moderegex;points;optionalregex'' The points item can be either a numeric (1, 10, etc.) or an aritmetic expression involving RCVD, RECINFO, RECINFO2, or RECINFO3. '''Important: When designing points rules, keep in mind the first valid rule encountered, reading from the top, overrides all subsequent rules. This can simplify rule-writing greatly.'''
| No default value
|-
| '''POINTS_CALC_F'''
| Formula for points calculation with <tt>POINTS_TYPE</tt> <tt>QRB_EXCHANGE+CALCF</tt> and <tt>QRB+CALCF</tt>. Syntax: <tt>POINTS_CALC_F=</tt>''sourceregex;pointsformula;bandregex;calculationregex'' Example: <tt>POINTS_CALC_F=ALL;VALUE*5.0;^15$;QRB>=100&&QRB<=800</tt> multiplies points with 5 on 15m if QRB is between 100 and 800km. All mathematical functions in C# syntax, plus the points number (<tt>VALUE</tt>) are available for expressions. In the ''calculationregex'', the keyword <tt>QRB</tt> can also be used for e.g. comparisons. Additionally, three additional syntax elements are available: <tt>VALUE{QRB:''grid''}</tt> which has the value of the distance (in km) from you to ''grid'', <tt>VALUE{*QRB:''grid''}</tt> which has the value of distance from ''grid'' to the party station, and <tt>VALUE{QRB:IARU}</tt> which has the value of the distance according to the IARU R1 rules for 6 and 4m MGM contests which is the distance between the centers of the origin and destination large square (four first characters) rounded up and if same, 50 points.
| No default value
|-
|}

=== Progress tracking keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''WINDOWS_CML_ENABLED'''
| Enable custom multiplier window #1.
| style="white-space: nowrap;" | Default value: NO
|-
| '''WINDOWS_CML2_ENABLED'''
| Enable custom multiplier window #2.
| Default value: NO
|-
| '''WINDOWS_CML3_ENABLED'''
| Enable custom multiplier window #3.
| Default value: NO
|-
| '''WINDOWS_CML_NAME'''
| Name of custom multiplier #1.
| No default value
|-
| '''WINDOWS_CML2_NAME'''
| Name of custom multiplier #2.
| style="white-space: nowrap;" | No default value
|-
| '''WINDOWS_CML3_NAME'''
| Name of custom multiplier #3.
| No default value
|-
| '''WINDOWS_CML_LIST_FX''' '''WINDOWS_CML2_LIST_FX''' '''WINDOWS_CML3_LIST_FX'''
| C# expression for the multipliers listed in custom multiplier window for MULT. Syntax: <tt>WINDOWS_CML_LIST_FX=function</tt>. Example: <tt><nowiki>WINDOWS_CML_LIST_FX=GetList_PrefixArea(dxccList,"^(VK|ZL)$")</nowiki></tt> Example:<tt> <nowiki>WINDOWS_CML_LIST_FX=GetList_CustomArray("A|C|CA|CC|CE|V|VI|Z","|")</nowiki></tt>
| No default value
|-
| '''WINDOWS_CML_DATA''' '''WINDOWS_CML2_DATA''' '''WINDOWS_CML3_DATA'''
| Source of data for custom multiplier window 1, 2, and 3. Valid values: MULT1, MULT2, MULT3, QSODIFF, QSODIFF_SP, and QSODIFF_CQ.
| No default value
|-
| '''WINDOWS_CML_SHOW_GROUP''' '''WINDOWS_CML2_SHOW_GROUP''' '''WINDOWS_CML3_SHOW_GROUP'''
| Controls if custom multiplier window 1, 3, and 3 show the multipliers grouped, if groups are defined. Valid values: YES and NO.
| Default value: NO
|-
| '''WINDOWS_CML_RESIZABLE''' '''WINDOWS_CML2_RESIZABLE''' '''WINDOWS_CML3_RESIZABLE'''
| Controls if custom multiplier windows are resizable.
| Default value: NO
|-
| '''WINDOWS_CML_LABELS_IN_ROW''' '''WINDOWS_CML2_LABELS_IN_ROW''' '''WINDOWS_CML3_LABELS_IN_ROW'''
| Controls number of MULT labels in each row of its custom multiplier window. Valid values: -1 and positive integers. -1 means DXLog default 10.
| Default value: -1
|-
| '''WINDOWS_CML_ALL_LABELS_IN_ROW''' '''WINDOWS_CML2_ALL_LABELS_IN_ROW''' '''WINDOWS_CML3_ALL_LABELS_IN_ROW'''
| Controls the number of MULT labels in each row of its custom multiplier window when all bands are displayed. Valid values: -1 and positive integers. -1 means DXLog default 20.
| Default value: -1
|-
| '''WINDOWS_CML_HIDDEN_CONT''' '''WINDOWS_CML2_HIDDEN_CONT''' '''WINDOWS_CML3_HIDDEN_CONT'''
| Hides a custom multiplier window for stations from selected continents. Currently not used in any contest.
| style="white-space: nowrap;" | Default value: None
|-
| '''WINDOWS_CML_HIDDEN_DXCC''' '''WINDOWS_CML2_HIDDEN_DXCC''' '''WINDOWS_CML3_HIDDEN_DXCC'''
| Hides a custom multiplier window for stations from selected DXCC. Syntax: <tt>WINDOWS_CML_HIDDEN_DXCC=list</tt> Example: <tt>WINDOWS_CML_HIDDEN_DXCC=*+G;GI;GW;GM;GJ;GU;GD</tt> hides the custom multiplier window for UK stations. Example: <tt>WINDOWS_CML_HIDDEN_DXCC=*-SM;LA;OZ;OH</tt> shows the custom multiplier window only for Scandinavian stations.
| No default value
|-
| '''WINDOWS_WKD_DXCC_ENABLED'''
| Enables worked DXCC window. '''Important:''' The worked DXCC window will only update on logging if DXCC is a valid multiplier for the contest. If you want to use this window for e.g., a VHF contests, you must define a zero-worth DXCC multiplier. E.g. <tt>MULT2_TYPE=DXCC</tt> <tt>MULT2_FIELD=FROM_DXCC</tt> <tt>MULT_SUM=NO</tt> Valid values: YES and NO.
| Default value: NO
|-
| '''WINDOWS_WKD_DXCC_HIDDEN_CONT'''
| Hides worked DXCC window for stations from selected continent. Example: <tt>WINDOWS_WKD_DXCC_HIDDEN_CONT=*-AS<tt> shows only the worked DXCC window for Asian stations.
| No default value
|-
| '''WINDOWS_WKD_DXCC_HIDDEN_DXCC'''
| Hides worked DXCC window for stations from selected DXCC. C.f. WINDOWS_CML_HIDDEN_DXCC above for syntax.
| No default value
|-
| '''WINDOWS_WKD_DXCC_SHOW_ONLY_CONT'''
| Show only entities from the listed continents in the worked DXCC window. Example: <tt>WINDOWS_WKD_DXCC_SHOW_ONLY_CONT=NA;SA</tt> shows only NA and SA entities in the worked DXCC window.
| No default value
|-
| '''WINDOWS_WKD_DXCC_CONT_FILTER'''
| Defines which DXCC entities from a selected continent to show in the worked DXCC window. Example: <tt>WINDOWS_WKD_DXCC_CONT_FILTER=SA:9Y;P4;PJ2;PJ4</tt> will only include 9Y, P4 and PJ2 from South America. You can have several of this key.
| No default value
|-
| '''WINDOWS_WKD_DXCC_HIDE_DXCC'''
| Hides a list of DXCC entities from the worked DXCC window. Example: <tt>WINDOWS_WKD_DXCC_HIDE_DXCC=K;VE</tt> hides US and Canada from the worked DXCC window.
| No default value
|-
| '''WINDOWS_WKD_GRID_ENABLED'''
| Enables worked grids window. Valid values: YES and NO.
| Default value: NO
|-
| '''WINDOWS_WKD_PFX_ENABLED'''
| Enables worked prefixes window. Valid values: YES and NO.
| Default value: NO
|-
| '''WINDOWS_WKD_PFX_HIDDEN_CONT'''
| Hides worked prefixes window for stations from selected continent. C.f. WINDOWS_WKD_DXCC_HIDDEN_CONT above for syntax.
| Default is to hide nothing
|-
| '''WINDOWS_WKD_PFX_HIDDEN_DXCC'''
| Hides worked prefixes window for stations from selected DXCC. C.f. WINDOWS_CML_HIDDEN_DXCC above for syntax.
| Default is to hide nothing
|-
| '''WINDOWS_WKD_PFX_DATA'''
| Source of worked prefixes data. Valid values: MULT1, MULT2, and MULT3.
| No default value
|-
|}

=== Livescore keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''LIVESCORE_ASSISTED'''
| List of assistance categories used for live score reporting. List must have the same number of items as mode CATEGORIES.
| Default value: Value of CABRILLO_ASSISTED
|-
| '''LIVESCORE_BAND''' '''LIVESCORE_BAND_SPECIAL'''
| List of band categories used for live score reporting. List must either have one single value of the same number of items as CABRILLO_BAND. If a single value, this is valid for all categories. Band names are Cabrillo convention. Non standard band categories recognized by score boards are: 2-BAND, 3-BAND, LOW-BAND, and HIGH-BAND. LIVESCORE_BAND_SPECIAL allows the use of non-standard values.
| Default value: Value of CABRILLO_BAND
|-
| '''LIVESCORE_CATEGORY_MODES'''
| List of contest mode categories used for live score reporting. List must have the same number of items as CATEGORY_MODES.
| Default value: Value of CATEGORY_MODES
|-
| '''LIVESCORE_CONTEST_NAME'''
| Contest name used for live score reporting. If the string contains <tt>{MODE}</tt> this will be replaced by the current contest mode capitalized.
| Default value: Value of CABRILLO_CONTEST_NAME
|-
| '''LIVESCORE_MODES'''
| List of modes used for live score reporting. List must have the same number of items as MODES.
| Default value: Value of CABRILLO_MODE
|-
| '''LIVESCORE_MULT'''
| List of multiplier "names" in numerical order used for live score reporting. Must have the same number of items as contest multipliers, but names may be repeated. Used when the multiplier type is not explicit, such as grid square. Valid multiplier types are <tt>ZONE, COUNTRY, STATE, GRIDSQUARE, WPXPREFIX, PREFIX, HQ</tt> and <tt>NONE</tt>.
| By default DXLog recognizes "country", "zone", "hq", "wpxprefix", and "state".
|-
| '''LIVESCORE_OPERATOR''' '''LIVESCORE_OPERATOR_SPECIAL'''
| List of types of operation used for live score reporting. List must have the same number of items as CATEGORIES. LIVESCORE_OPERATOR_SPECIAL allows the use of non-standard values.
| Default value: Value of CABRILLO_OPERATOR
|-
| '''LIVESCORE_POWER'''
| List of output power classes used for live score reporting. List must have the same number of items as CLASS.
| Default value: Value of CABRILLO_POWER
|-
| '''LIVESCORE_RTC_SENT_EXCHANGE'''
| List of the exchange elements sent by own station. Accepts *RGX conditionals like CABRILLO_LINE. Valid keywords are NR, OPNAME, EXCHANGE, POWER, MYCQZONE, MYITUZONE, MYDXCC, STATE, GRID4, GRID, and NOTHING. A literal string must be preceded by a single quote '. '''Important: This key is required in contest definition file to enable Real Time Contest QSO upload.'''
| Default value: None
|-
| '''LIVESCORE_TRANSMITTER'''
| List of number of transmitters categories used for live score reporting. List must have the same number of items as CATEGORIES.
| Default value: Value of CABRILLO_TRANSMITTER
|-
|}

=== QTC keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''QTC_ENABLED'''
| Enables QTC mechanics.
| Default value: NO
|-
| '''QTC_SEND_ENABLED'''
| Enables QTC sending.
| Default value: !SOURCE->CONT:^EU$
|-
| '''QTC_RECV_ENABLED'''
| Enables QTC receiving.
| Default value: SOURCE->CONT:^EU$
|-
| '''QTC_SEND_RGX'''
| Regular expression controlling the transmission of QTC.
|Default value: DEST->CONT:^EU$
|-
| '''QTC_RECV_RGX'''
| Regular expression controlling the reception of QTC.
|Default value: !DEST->CONT:^EU$
|-
|}

=== Other keys ===

{|class="wikitable"
|+style="text-align:Left;"|
| '''ADIF_KEYS'''
| Allows for including custom keys in ADIF export. The syntax is <tt>ADIF_KEYS=</tt>''ADIFKEY;expression;regex1;regex2''. ''regex1'' and ''regex2'' are optional but must both evaluate as true for the key to be included in the export. The syntax for ''expression'' is C# and based on internal <tt>DXQSO</tt> object structure. Received exchanges are <tt>$VALUE.Rcvd</tt>, <tt>$VALUE.Rcvd4</tt>, <tt>$VALUE.RecInfo</tt>, <tt>$VALUE.RecInfo2</tt>, and <tt>$VALUE.RecInfo3</tt>. <tt>Rcvd4</tt> is the <tt>Rcvd</tt> object without the signal report. So to, for instance, export the received exchange as US/VE state use <tt><nowiki>ADIF_KEYS=STATE;$VALUE.Rcvd4;DEST->DXCC:^(K|KL|KH6|VE)$;DEST->RCVD:^[A-Z]{2}$</nowiki></tt>. To export the second exchange as operator name use <tt>ADIF_KEYS=NAME;$VALUE.RecInfo</tt> but note that DXLog will export a field of type NAME automatically. The following <tt>$VALUE.xxx</tt> keys are available: <tt>Sent, Rcvd, Rcvd4, RecInfo, RecInfo2, RecInfo3, Az, Mult, Mult1, Mult2, Mult3, Lp, Period, Band, Mode, Callsign, QRB (integer), Nr (integer), Stn, OriginStnID, Operator,</tt> and <tt>RadioVFO</tt>. Please note that you can also use C# style string manipulation such as <tt>Substring(start, length)</tt> etc. There is no limit on the number of <tt>ADIF_KEYS</tt> lines in a contest definition file, but with the exception of COMMENT, only one per key is allowed to be valid at one time. Multiple COMMENT keys are appended. The keywords $EXCHANGE, $POWER, $ITUZONE, $CQZONE, $DXCC, $TIME, $SERIAL, $GRID, $GRID4, $OPNAME, $STATE, or any C# string expression are also allowed, e.g., <tt>ADIF_KEYS=MY_SIG;WWFF</tt> and <tt>ADIF_KEYS=MY_SIG_INFO;$EXCHANGE</tt>. The following keys are reserved and cannot be customized QSO_DATE, TIME_ON, STATION_CALLSIGN, FREQ, BAND, CONTEST_ID, MODE, CALL, RST_SENT, RST_RCVD, OPERATOR, APP_DXLOG_RCVD, APP_DXLOG_RECINFO, APP_DXLOG_RECINFO2, APP_DXLOG_RECINFO3, APP_DXLOG_POINTS, APP_DXLOG_STNID, APP_DXLOG_STN, APP_DXLOG_MULT1, APP_DXLOG_MULT2, APP_DXLOG_MULT3, APP_DXLOG_NR, MY_GRIDSQUARE, MY_NAME, MY_CQ_ZONE, MY_ITU_ZONE, PFX, OWNER_CALLSIGN, and TX_PWR.
|Default value: None
|-
| '''ASTROPHYSICS'''
| Enables DXLog's propagation enhancing features. Valid values: YES and NO.
| Default value: NO
|-
| '''EDI_TOTAL_SCORE'''
| Defines how CToSc in EDI export is calculated. Valid values: ALL or PER_BAND.
| Default value: PER_BAND
|-
| '''OVERRIDE_INVALID_QSO_MESSAGE'''
| Suppress invalid QSO message for selected cases. Syntax is <tt>OVERRIDE_INVALID_QSO_MESSAGE=</tt>''IncaseRegex;AndRegex'' Example: <tt>OVERRIDE_INVALID_QSO_MESSAGE=DEST->DXCC:^K$;DEST->RCVD:^$</tt> will suppress complaints about invalid QSO when the RCVD field is empty US stations. This is a legacy function with limited usefulness. To ensure stations without valid exchanges are correctly displayed in the bandmap you typically need to add zero-points dummy rules that will prevent error messages anyway.
| style="white-space: nowrap;" | Default value: None
|-
| '''SATELLITE_BAND'''
| Makes all QSO on a particular band or bands treated as satellite QSO. Example: <tt>SATELLITE_BAND=2300;QO-100;8089500</tt> will make all 13cm QSO in the log QO-100 satellite QSO with a receive frequency 8089500kHz higher than the logged frequency. Only affects UDP broadcast and ADIF export. More than one per contest definition is allowed.
| Default value: None
|-
| '''SELF_SPOT_ALLOWED'''
| Enables spotting of own station. Either a single YES/NO or a semicolon separated list of YES/NO with the same number of entries as CATEGORIES.
| Default value: NO
|-
| '''SELF_SPOT_MINPERIOD'''
| Controls the minimum time in minutes between spots of own station.
| Default value: 10
|-
| '''SELF_SPOT_MODES'''
| Controls the modes for which self spotting is allowed. Either ALL or a semicolon separated list of modes.
| Default value: ALL
|-
| '''SELF_SPOT_PER_RADIO'''
| Controls whether the self spotting period is per radio or per station.
| Default value: YES
|-
| '''SPRINT_LOGIC_ALLOWED'''
| Enable "sprint logic" check box in the Standard Messages panel's Options tab.
| Default value: NO
|-
| '''WARNING_FILE'''
| Name of a frequency range warning file located in <tt>%appdata%\DXLog\Database</tt>. The format of each line in the warning file is: <tt>Mode regular expression;frequency range;Message</tt> Example: <tt><nowiki>CW;3400-3520;Warning: Operation not allowed on this frequency</nowiki> <nowiki>CW;3550-3900;Warning: Operation not allowed on this frequency</nowiki> <nowiki>SSB;3400-3600;Warning: Operation not allowed on this frequency</nowiki> <nowiki>SB;3675-3700;Warning: Operation not allowed on this frequency</nowiki> <nowiki>SSB;3725-3900;Warning: Operation not allowed on this frequency</nowiki></tt> '''Important:''' File name casing must be correct for online update to work.
| No default value
|-
| '''WINDOWS_ON4KST_ENABLED'''
| Enables ON4KST messaging window
| Default value: NO
|-
|}

==Less obvious constructs==

Entry type based on DXCC of logged station.

<tt>FIELD_RCVD_TYPE=DXCC:^PA$=MULT;!DXCC:^PA$=NR</tt> 

The first match in the line is used, allowing "all others" type of constructs

<tt>FIELD_RCVD_TYPE=DXCC:^(K|KH6|KL|VE)$=MULT;DXCC:.=NR</tt>

Other multiplier than the defined.

<tt>MULT1_EXCEPTION=!SOURCE->DXCC:^(JW|JX|LA|OH|OH0|OJ0|OX|OY|OZ|SM|TF)$;PFX_AREA</tt>

Zero padding of an exchange. Normally not needed since DXLog zero pads several input types.

<tt>POINTS_FIELD_BAND_MODE=DEST->CONT:SOURCE->CONT;!SOURCE->ITUZONE:DEST->RCVD{F=R,2,0};ALL;ALL;3</tt>

Using a field value as the QSO score

<tt>POINTS_FIELD_BAND_MODE=!CONFIG->EXCHANGE:^ZZ$;ALL;ALL;ALL;RECINFO2</tt>

Adding alternative exchanges to multiplier list

<tt>CFG_MULT_RGX_CHECK=^0?[1-9]$|^[1-8][0-9]?$|^90$|CUSTOM_MULT_LIST 
FIELD_RCVD_RGX_CHECK=DEST->RCVD:^0?[1-9]$|^[1-8][0-9]?$|^90$;DEST->RCVD:CUSTOM_MULT_LIST</tt>

Disabling exchange checking for certain stations

<tt>FIELD_RECINFO_MANDATORY_RGX_EXC=!DEST->DXCC:^(K|KL|KH6|VE)$;DEST->CALL:/[AM]M$ 
FIELD_RECINFO_CHECK_FORMAT_FX=!DEST->DXCC:^(K|KL|KH6|VE)$>>""</tt>