View source for Additional Information

==Using alternative configurations==

Window positions, coloring and general look and feel is saved in each log file but all other settings such as<br>
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>. It is located in the <tt>%appdata%\DXLog.net</tt> configuration directory.

This directory is also reachable via the <code>File|Open configuration directory</code> menu.


[[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<br>
and give it a meaningful name. 


[[image:Desktopshortcut.png]]


The command line option is simply added to the end of the <i>Target</i> text box in the shortcut's properties.<br>
Double-clicking the icon will start DXLog with the alternative configuration which will also be remembered between sessions.<br>
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<br>
since this shortcut will be deleted when you upgrade DXLog. Instead make a copy, rename, and add the command line option.<br>
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)<br>
logged serial numbers are the same. In a straightforward SO1R or SO2V scenario, serial numbers are simply<br>
chronological but in more complex station configurations such as Multi-single or Multi-2 with inband, and<br>
advanced SO2R, QSO can be interleaved and requires a central source source of serial numbers together<br>
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<br>
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<br>
using a single computer in SO2R. In the case of multiple stations, UDP networking or Client-Server<br>
networking must also be enabled to transfer the numbers over the LAN. For SO2R, this is however not<br>
necessary. When using Client-Server networking, a client cannot be number server. 

<u>There must only be one number server</u> in a local network and all stations using it must have<br>
<code>Options|Networking|Use number server</code> checked like in the picture below.

'''Important:''' The number client/server functionality is not very robust. <br>
If you have stations joining/leaving your network or being rebooted, it is <br>
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<br> 
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.<br>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<br>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.<br>

These methods can of course also be combined.<br>

The $RESERVENR macro is "smart" and will only reserve a serial number if the callsign entry field is not empty and a<br>
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<br>
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>.<br>
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<br>
<code>[Alt][W]</code> and start typing. If this is your habit, this option will prevent you from releasing the<br>
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''<br>
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/<br>
FreeLan http://www.freelan.org/<br>
Player.me https://player.me/<br>
OpenVPN https://openvpn.net/

Each VLAN solutions have their own particular set up which is covered in their respective documentations.<br>
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.<br>
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'''.<br>
'''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<br>
for the wide-area network and UDP for the local network at each station location. Below you will find the station<br>
set up for the Swedish HQ station SE9HQ in the 2019 IARU HF Championship. The DXLog.net.DXC cluster client was run<br>
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<br>
: 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,<br>
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.<br>
Any DXLog station running the same contest configuration, knowing the URL or IP address and IP port of the<br>
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.

===DXLogStream===

DXLogStream is a basic Windows utility (which can run minimized) that uses the radio information broadcast over<br>
UDP from DXLog and uploads logged QSO to Club Log for display using its Live Stream feature. Typical use cases<br>
are DXPeditions, IOTA activation, Special event stations, etc.

The utility requires a valid Club Log account <u>with the used station call sign registered</u>. 

Please note that passwords containing non-ASCII characters may not work due to coding limitations.

Networking must be enabled with <code>Options|Enable Network</code>. 

Also, UDP networking must be enabled and the '''station ID''' and used '''port''' must be the same as<br>
set in the <code>Options|Configure network</code> panel.

Settings are saved by hitting ENTER or clicking the Save button. If the UDP port is changed,<br>
the utility needs to be restarted. 

The station callsign entered into the text box is the one used for upload. DXLog does not convey this as<br>
part of the logging information via UDP which means that the corresponding setting in DXLog's contest<br>
configuration is ignored. 

The utility can be downloaded <u>[http://dxlog.net/sw/#files%2Futilities here]</u>.

You will find more information about the Club Log Live Stream feature on the [https://clublog.freshdesk.com/support/solutions/articles/3000092445-using-club-log-live-streams Club Log web site].


[[File:Dxlogstream.PNG|none|border|400px]]

===Club Log Gateway===

Since the release of the utility above, Michael Wall, G7VJR, the founder of Club Log, has developed a much<br>
more powerful agent for real time uploads. It works with all the three major loggers, DXLog, N1MM Logger+,<br>
and Win-Test.

Unlike the utility above, which is using DXLog's multi-station networking, it can also use<br>
N1MM style UDP XML broadcast of QSO information. 

This is enabled by checking <code>Options|Broadcast|QSOs</code> and the address/port settings are found in the<br>
right half of DXLog's network configuration panel. 

The Club Log Gateway can either listen to DXLog's native multi-station networking protocol or to the N1MM style broadcast.

It is recommended to use the N1MM style broadcast since it contains information like logged on operator, etc.

In DXLog this is done by checking:

<code>Options|Broadcast|QSOs</code><br>
<code>Options|Broadcast|Use N1MM QSO format</code> <br>
<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"<br>
in the ADIF export configuration to avoid creating virtual dupes, since Club Log does not know seconds.

It is less user friendly and more demanding to set up. But for serious use, this is the preferred agent.

You can find more information about it <u>[https://clublog.freshdesk.com/support/solutions/articles/3000093504-club-log-gateway-for-real-time-uploads here]</u>

==Diversity reception==

Diversity means receiving the same signal through two different receive chains, including antenna.<br>
With two antennas having different characteristics this can give substantial benefits in receiving <br>
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<br>
the necessary mechanics. Diversity operation is indicated by a small <b>DIV</b> icon in the frequency<br>
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.<br>
Enabling this will make DXLog update both VFO with the same information when grabbing spots.<br>
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO.<br>
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.<br>
Enabling this will make DXLog update both VFO with the same information when grabbing spots.<br>
It will also adjust the sub VFO with the correct amount when RIT is applied to the main VFO.<br>
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. <br>
It should be noted that Elecraft's implementation where the main VFO controls both the main and <br>
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<br>
XML datagrams over UDP.<br>

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<br>
interoperability with some online services and software such as MSHV.

In addition, DXLog can also recognize QSY commands from <i>Waterfall Bandmap</i> and create<br>
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.<br>
Please note that up to three ports can be specified for each broadcast, thereby supporting <br>
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 <br>
for creating an object from a sample XML datagram here https://xmltocsharp.azurewebsites.net/<br>

In C# parsing is easily done using Linq. One example of XML parsing and deserialization using Linq<br>
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.<br>Note that the qsoid is only unique within one instance of DXLog. If the computer is networked to others running <br>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<br>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<br>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.
|-
| mult1 
| The name of the multiplier if this station is a new multipllier, blank otherwise.
|-
| mult2 
| The name of the multiplier if this station is a new multiplier, blank otherwise.
|-
| mult3 
| The name of the multiplier if this station is a new multiplier, blank 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>
    <mult1>GA</mult1>
    <mult2></mult2>
    <mult3></mult3>
    <points>3</points>
    <period>1</period>
    <guid>11223344556677889900aabbccddeeff</newqso>
    <newqso>True</newqso>
</contactinfo>
</pre>

<b>Alternative N1MM format</b>

Note that the band name uses the computer's local number format so it may use either comma<br>
or period as decimal separator. The ID is a number rather than an alphanumeric string.

<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],<br>
[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<br>
K3's RX-ANT OUT is connected to the input of a 3dB power splitter. The two outputs from the splitter<br>
are connected RX-ANT IN on the K3 and the SDR Receiver antenna input, respectively. On a K3 you<br>
need to enable the RX-antenna input to make this to work. An additional benefit with this method <br>
is that the SDR is protected during transmission. It is a widely used method and is e.g. described <br>
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" <br>
the CAT communication. microHAM's USB Device Router provides a second, independent, <br>
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 <br>
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 <br>
back to DxLog after clicking on the HDSDR waterfall and in DXLog it allows you to use hotkeys to <br>
control HDSDR. <code>[Ctrl][Alt]+</code> and <code>[Ctrl][Alt]-</code> zooms the waterfall/spectrum <br>
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<br>
running at the same time.

I have not yet found a way to display cluster spots in the HDSDR spectrum panel.<br>
But I still find it very useful to check band activity and it allows me to easily find <br>
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 <br>
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 <br>
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.<br>
Membership is free.


[[Image:Waterfallbandmap.png]]


The SDR can be connected either to a separate receive antenna, an external receiver output on<br>
your transceiver or to an IF output, should your transceiver have one. If connected to an antenna,<br>
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.<br>
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.<br>
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.)<br>
To enable this functionality, check the option <code>Options|Broadcast|Receive Broadcasts</code><br>
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<br>
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<br>
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.<br>
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<br> 
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.<br>
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. <br>
When in doubt, you can always add the global server "pool.ntp.org" to the list and use that.<br>

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", <br>
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.<br>
From here on, you can basically forget the application.<br>
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<br>
when it believes there is inactivity. Some USB-to-serial and USB audio devices <br>
respond poorly to being suspended or powered down so as a rule this "feature" should<br>
be disabled when used in a ham radio environment.

There are two places where this functionality needs to be disabled; the device driver<br>
and Windows' energy management.

To disable it for each USB interface and device, open Windows settings. (Click the Windows <br>
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,<br>
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)'',<br>
''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<br>
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<br>
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,<br>
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<br>
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<br>
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<br>
an unlimited number of transmitters and receivers on a single band for multi-operator categories.<br>
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<br>
other station transmits. This means it requires a separate, high performance receive antenna<br>
with very good isolation from the transmitter antenna. The most common way to<br>
achieve this is physical separation and geographic orientation to minimize the situations<br>
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<br> 
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<br>
band, operating mode, or station role. It supports an unlimited number of stations interlocking each other<br>
using a great variety of strategies. 

The interlock relies on UDP networking and is overlaid on the communication for multi-station logging. <br>
UDP networking has the benefit of speed and low latency but is, unlike TCP, susceptible to packet loss.<br>
This means that a '''wired LAN''' is a necessity for any station using interlock.<br>
For the same reason, it is also not recommended to run interlock over e.g. VLAN/VPN link for<br>
geographically distributed stations.

A software interlock is not 100% reliable. Computer or software malfunction, networking issues such as packet<br>
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.<br>
Without hardware supported interlock you run the risk of not only violating contest rules but also cause serious equipment damage.<br>
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.<br>
One example of a simple but effective two station hardware interlock which also supports <br>
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<br>
DXLog and microHAM keyers. The microHAM keyers are not mandatory but offers a much better user experience<br>
and removes the need for additional hardware.

'''Pro tip:''' Consider checking <code>Options|Networking|Allow other stations to abort sending</code><br>
which will allow your partner station to interrupt your transmission with <code>[Shift][Esc]</code> in<br> 
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<br>
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<br>
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]]<br>

===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><br>
is '''not''' enabled. This option completely prevents transmission if more than one networked station is set to the same band<br>
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><br>
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<br>
option ''Same band from status list'' is a good choice. This option will prevent more than one station transmitting<br>
on the same band, regardless of mode.

In an environment with many stations (such as a multi-operator-multi-transmitter station) it is<br>
recommended to use the bottom option to only interlock with one or several named stations.<br>
This will reduce both LAN traffic and inband operation latency. This is particularly important when<br>
running parts of the DXLog network over high latency links such as VLAN/VPN or if some stations (albeit not<br>
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<br>
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<br>
most commonly used is ''First one wins''. This is also typically the behavior of "unintelligent"<br>
hardware solutions when not assisted by software. With this strategy, the station starting to transmit<br>
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<br>
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.<br>
This is a powerful tool but requires both operators to be aware of it and may require<br>
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<br>
from the keyboard using the <code>[Alt][K]</code> function and ''MAN'' means manual transmission using either paddle<br>
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.<br>
It is also possible to connect a footswitch to the DSR pin (pin 6) on a physical COM-port on the PC, but today<br>
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<br>
transmission and and it will make DXLog aware of the microHAM device's PTT status. The latter is particularly<br>
important since it means DXLog will recognize PTT assertion not only by a footswitch connected to the<br>
microHAM device but also by the built-in Winkeyer (requires microHAM USB Device Router version 9.3.0 or later)<br>
'''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,<br>
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)<br>
or if its CAT interface is not connected to the radio. This option will make sure the e.g. keying and<br>
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<br>
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, <br>
doing S&P on the inband station can increase the points per minute significantly. <br>
However, if Run is strong, an overly active inband operator doing S&P, but not working <br>
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<br>
<code>Windows|Radio status</code>. 


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


For Phone contesting, you typically rely on footswitches for PTT and the option<br>
<code>Options|Networking|Show QSO status when blocking</code> makes the blocking<br>
station send a more helpful blocking cause than ''MAN''.

With this option enabled, the blocking station will instead send ''CQ'', ''QSO'', or ''EXCHANGE''<br> 
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)<br>
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''<br> 
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.<br>
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<br>
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<br> 
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.<br>
Today many cluster nodes runs this version and thereby offer this mechanic.<br>
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>.<br>
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,<br>
in some cases, a corrected callsign within parenthesis. This syntax is recognized by DXLog and can reduce the<br>
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.<br>If the callsign of an unverified spot closely resembles an already verified one on the same frequency, the verified callsign<br>is provided within parenthesis in the spot's comment field. When two or more skimmers agree on the spot, it is considered<br>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.<br>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<br>same frequency. If the resemblance is high enough, the spot is considered busted "B" and the corrected callsign is provided<br>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.<br>
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.

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.<br>
It is safe to receive busted spots since DXLog will ignore them if there is no corrected callsign included.<br>

For assisted operation in serious contesting you however need to allow also unknown spots since weak stations spotted<br>
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.<br> 
These windows will show two additional tags; L and C. L stands for local spot, created by yourself or one of your team members.<br>
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 <b>by far</b> most dominant DX cluster software but has historically not been a good choice for contesters. <br>
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<br>
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<br>
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<br>
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. 
: '''U''' 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.<br>
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].

==Interacting with WSJT-X==

<b>Important: When in a DXpedition/multi-station setting, always use local host 127.0.0.1 as the<br>
broadcast address to prevent packets being picked up by other stations in the network.<br>
Also, enabling the creation of local spots from decodes may overflow DXLog.</b>

DXLog can add QSO performed with WSJT-X to its log. Note that this functionality only works<br>
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<br>
<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<br>
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<br>
Rafal EI6LA has developed a plugin for MMTTY that makes this possible. 

You can find it <u>[https://github.com/RafalLukawiecki/WinKeyerMMTY here]</u>.

==Interfacing with LogHX==

Christian F8GHE has prepared a guide on how to do this. 

You can find it <u>[http://dxlog.net/sw/files/utilities/DXLOG-LogHX_UDP-config_v2.pdf here]</u>.

==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.<br>
Should you find that DXLog incorrectly allows or blocks self-spotting, please make<br>
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<br>
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>