Unofficial FAQ on Logger 32
This FAQ is a
work-in-progress. The idea is
to reproduce questions and
answers that come up quite
often on the Logger32 support reflector, and to share further tips for those using Logger32. Please email me your improvement suggestions. In time, when there is enough content here to make it worthwhile, I will sort the entries and provide an index.
Q: I installed Logger32 version now, it is 3.3417 version. Did you test this version? Has it
any bugs? Is DXCC counting ok? I read your reviews about Logger32 that it has some
bugs ...
A:
Like ALL real-world software, Logger32 has bugs and flaws/limitations in every version, but
some are resolved with each new release ... And unfortunately, new bugs appear and new
requirements emerge! On the whole, it works fine and we definitely get our money’s worth (it’s
free!). It's the everyday logger this keen DXer chose and continue to use, so it can’t be too bad.
To be fair, other logging programs, and in fact all other programs, also have bugs and flaws despite
the best efforts of professional and amateur programmers, architects, designers, testers and
support krew.
Q: I have a paper log. I would like to put 3,000 QSO from paper log into Logger32
manually but Logbookentry window has only 5 fields. Can I put DATE and TIME and other
fields on Logbookentry?
A:
We have limited flexibility with the QSO entry window but I would advise using a completely
different program to enter past QSOs rapidly into an ADIF file, then import that ADIF into Logger32.
I have used Fast Log Entry by DF3CB. It is a basic tool to enter the minimal QSO info but it does
that job well.
Q: If I right click on logbook page and Add QSO and Add QSO Manually window appears.
Can I change this window? I don’t need COMMENT, ADDRESS, Primary or Secondary
Admin but I'd like STATE and IOTA instead.
A:
That window appears to be fixed and as far as I can tell is not reconfigurable, I'm afraid. :-(
Q: How can I enter STATE and IOTA data into Logger32 manually from my paper log?
A:
If you use Fast Log Entry or some other program to create an ADIF, you have an option when
you import it into Logger32 to “Add IOTA numbers to QSOs (where possible)”. This presumably
calculates and adds IOTA references for certain island stations whose prefixes unambiguously
indicate their IOTA reference (e.g. VQ9anything is on Chagos Is. and so has the Chagos Is. IOTA
reference). However, Logger32 does not have a comprehensive database of calls and IOTA
references to resolve more ambiguous ones. You can probably figure them out from your old
paper log, plus your QSLs, plus QRZ.com pages, plus Clublog, but it is a painstaking, manual job.
Actually adding IOTA refs to your log is the easy bit provided you have the IOTA field selected to
display in your logbook: simply edit the IOTA field for a QSO in the log, entering the complete
reference in the specified IOTA format XX-NNN e.g. OC-036. Logger32 insists on you entering the
complete reference including the hyphen and leading zero because it is not quite smart enough to
figure out that OC36 or OC-36 or OC036 are all OC-036. It does check the format, and yet it lets
us enter any valid IOTA reference on any continent, no problem, regardless of the station’s country
as indicated by its prefix.
Adding states for Ws etc. is not so quick and easy because you can’t simply enter or directly edit
the state abbreviations in the log as you can do when you are initially entering them through the
log entry window. Instead you need to right-click a QSO line in the log, go to
Edit admin
subdivision info
, then look up and select the info from pick lists.
Those two situations are examples of the program trying hard to protect certain aspects of its data
integrity, at the expense of making it more laborious for us users since we can’t take too may
shortcuts. You win some, you lose some.
Q: I want these fields on the Logbook entry window like my paper log: QSO Number,
Callsign, Name, QTH, State, Date, Time, Frequency, Mode, Send report, Received report,
QSL send, QSL received and IOTA.
A:
That is possible in Logger32. The logbook layout is quite flexible, although personally I find
configuring it awkward. Luckily, that is not something I have to do very often! Right-click in the
logbook window, then select Setup > Grid layout. Tick all the fields you want to appear (and no
more!), then painstakingly drag the fields into the sequence you prefer (drag the little arrows to the
empty squares). Exit the configurer to view your handiwork. Lather, rinse, repeat.
Tip:
you can alter the logbook field/column headings by overtyping the labels in Setup > Grid
layout though this is not entirely obvious (there’s a hint in the help file).
Q: K5D comes up as Texas not Desecheo Island. How do I fix it?
A
: You could either wait until the Logger32 country database is next updated (shortly from Club
Log, or wait for Logger 32 itself to be updated), or do a quick fix for now: go to Tools > Database
maintenance > Country/Prefix maintenance
This opens a window showing the DXCC prefixes:
Scroll down the list to find the normal prefix for Desecheo, KP5, and click that line to bring up a
database edit window:
Now you need to get K5D into that empty box in the middle of the window. Just click in the box
and then type <K5D> (the angle brackets tell Logger32 it is a complete call not just a prefix):
Now before you close the database edit window, click the
Add
button on the far left of the same
line to save the change and add K5D to the prefix/country database. Finally, click the red and white
cross at top right to close the window and return to logging.
Note: if K5D is already explicitly defined elsewhere in the database, you will get a warning message
as it has to be a unique database key value.
Note: DXpeditions to S. Cook Islands such as Rarotonga are granted callsigns with the same E5
prefix as the much rarer N. Cooks. Logger32 unfortunately defaults to N. Cooks and exceptions
have to be entered manually in the same way. Auto-updates from Club Log are the way to go.
Q: How do I correct my PC’s clock?
A
: Windows has its own built-in capability to synchronize the clock to an Internet time server but it
is quite lame. There are better ways.
In Logger32, right-click the shack clock (on the left of the lower status bar) and click Get atomic
clock time. Logger32 finds a convenient reference clock on the Internet and sets the PC clock. It
gets within about 1 second on my system.
If accurate timing is quite important for you (e.g. for WSPR), other software makes an even better
job of it. The best I’ve found is Meinberg’s time server utility, synchronising to a local laboratory’s
NTP service backed by their atomic clock and configured to resynchronise itself regularly and
automatically in the background. It is accurate to within a few milliseconds on my PC, as far as I
can tell. If configuring the Meinberg software is too hard for you, try About Time or Dimension4.
If highly accurate timing is critical, you’ll probably be looking at a local rubidium standard that is
synchronised to atomic clocks orbiting in the GPS satellites.
Q: My PC clock is correct so why are so many DX QSLs arriving with the wrong times?
A
: If, like me, you sometimes spend ages calling some rare or weak DX before finally making a
QSO, make sure the log records the actual time of the QSO, rather than the time you started calling the DX. There’s an option in Logger32 to log the time of QSOs either when the callsign field
loses focus (i.e. when you tab to input the RST etc.) or when you hit enter to complete and log the
QSO. The second option is often more accurate than the first. To do this, right click in the log entry
panel, then select Setup > QSO Start time > When QSO entered in log:
Q: Why are there red and blue arrows on the band map?
A:
Because you have chosen to see the frequency markers for both your VFOs on the band map
under Config > Appearance
Most modern radios (apart from Icoms anyway) will periodically report
the frequencies of VFOs A and B to Logger32 through the serial
connection. The frequency of VFO A is marked on the band map with a
red arrow and VFO B in blue. You can choose to see the blue VFO B
marker only when the rig is in split mode, or all the time (in which case
you can temporarily hide the blue marker by moving VFO B out of band).
The arrows are useful to keep an eye on where you are transmitting, for
example in case you are moving out of band or clash with another
spotted station, as in this example.
I could tell from the DX spot with a blue background on the band map
that 4W/G3ZEM would be a new one for me this year on 20m, so I was
keen to work him.
He was working split. I was listening to him on my K3’s subreceiver (VFO
B) in both ears, shown by the blue arrow. At the same time, in order to
find a good frequency to call him, I was also listening on the main K3
receiver (VFO A) in one ear, moving the VFO and the red arrow gradually
up the band as I heard him working through his pile.
At the instant the screenshot was taken, I almost bumped into ZK3E. I
could hear him in the pile but he was quite weak, our beams being side-to
-side. Luckily I noticed the red arrow approaching ZK3E on the band map
and the red line linking to the spot, so I realized I would be QRMing him if
I transmitted there.
As it happened, the spot for ZK3E had a green background, telling me he would have been a new
mode-band slot-filler (I’ve worked ZK on this band but not yet on CW). It’s definitely not good
practice to QRM your new ones!
Q: How do I do <whatever> in Logger32?
A
: First try right-clicking in the relevant place. Many additional options lurk behind the right click,
provided your cursor is in the relevant part of the screen at the time (e.g. hovering over a data
entry/input field to change data entry defaults; hovering over a report/output area to reformat the
outputs or choose new report fields). As Jim W5IFP put it: “When all else fails try a ‘Right click’. You
might be surprised at all the stuff you can find there.”
Next read the help inside Logger32. There is a lot of good content in there but quite often users
evidently either forget to look things up or can’t find what they are looking for, sometimes because
items are tucked away under headings you might not have considered checking. Try the search
function in help.
If that’s not working, try searching the archives of the Logger32 reflector/online discussion forum
on Yahoo! Groups, which for historical reasons is still named Hamlogger.
Finally, ask your question on the support forum but be prepared to be told either you shouldn’t
really be doing whatever you want to do, or else it’s in the help file!
Q: How do I get Logger32 to connect to the DXcluster network through VE7CC’s Cluster
User program?
A:
VE7CC’s program is very useful for the additional control if gives you over the DX spots (it
makes it simple to configure the cluster filters to send you HF spots but block VHF spots, for
example). Here’s how to use it with Logger32:
-
Download and run VE7CC's excellent, free
Cluster User
program (also known as AR). Get it
to connect to a DXcluster (such as VE7CC's own DXcluster) and get that running sweetly first.
Get the filtering and all that jazz set up how you like it.
-
Configure the Cluster User program to serve spots on the local machine (like having your
very own cluster in the shack). The setting is under Configuration --> Ports/logging program.
Select Enable telnet
and port 7300
(or another if you prefer).
-
In Logger32's cluster settings, tell it to connect to
127.0.0.1:7300
, where 127.0.0.1 is the
same PC and 7300 is the telnet port to which Cluster User is sending the spots. I call mine
"Local". I think you can set this directly by right-clicking in the Logger32 telnet window -->
Setup --> Setup remote hosts and enter the info I've just said. Alternatively, you can add this
info to the cluster hosts file in the Logger32 directory: on my machine, the file is called
TelnetAddresses.INI which contains the single line Local~127.0.0.1|7300
-
Get Logger32 to connect to the “Local” cluster. It is now talking to your Cluster User
program, which in turn is connected to a real DXcluster. Configure the login script in Logger32
to send a show/DX/20, show/WWV or whatever you normally do when you startup.
-
Play with the config settings in Cluster User and/or Logger32 at your leisure e.g. filtering spots
, showing only needed countries, dinging the alarm bell when a new one shows up, showing
automatic Skimmer spots from the Reverse Beacon Network, auto-reconnecting to the
cluster if it drops out, or whatever.
-
For extra clever-clogs bonus marks, run a second instance of Cluster User connected to a
different DXcluster (e.g. one of the private members-only DX club clusters) and connect the
two together by selecting "Enable linking" to receive and merge even more juicy spots.
-
Now, work your socks off to find, work and spot that juicy DX before it appears on the
DXcluster network!
Skimmer spots from the Reverse Beacon Network significantly increase the number of raw spots
while VE7CC’s software and Logger32 together separate the wheat (such as new band/mode
countries) from the chaff (countries I have already worked and confirmed). I have filled numerous
slots and bagged several new ones thanks to the RBN spots plus Logger32’s audio visual alerting.
Q: How do I get Logger32 to ding the bell when I’m spotted, or when someone else I am
hunting is spotted?
A:
Use the audio alerts in the DXcluster window. Right click in the DXcluster window, then select
one of three options:
(1) select Setup > Audio/Callsign/Prefix/Comment alerts to configure the alerts. The options are
fairly obvious. Click the Edit Callsign Alert List button to set up or change the list of callsigns to be
highlit and follow the instructions:
(2) Add alerts for whichever spot you right-clicked - either that specific callsign or the prefix.
(3) This option takes you directly to the Edit list of Country/Callsigns to highlight thing.
Q: Why does Logger32 sometimes wipe the log data I am currently entering before I
have hit enter to save it?
A: Details such as the reports, name and QTH info are sometimes lost from the log entry window,
which can catch you by surprise. This happens deliberately (by design) under at least four known
circumstances:
-
If you correct the callsign of a station you are working, Logger32 automatically erases any
information it retrieved and entered automatically for the original callsign, as it is no longer
relevant for the corrected callsign.
-
The control-W (wipe) and control-C (clear) commands both erase all data from the log entry
panel.
-
Clicking in the area down the left hand side of the log entry panel (where it says call, sent,
received etc.) also erases all data from the log entry panel.
-
Clicking a callsign in the DXcluster windows will replace any current data in the log entry panel
with the callsign you have clicked plus any related information (e.g. default reports, name and
other info from previous QSOs with that station, and any other info taken from that station’s
QRZ.com, HamQTH or callbook lookup).
There have been reports from users that the fields are mysteriously cleared at other times too but
if this is happening at all, it is hard to reproduce the behaviour on demand. One user noted that the
wipe occurred during very long QSOs. I’ve occasionally noticed disappearing user-entered (not
default or system retrieved) data when correcting the station’s callsign, and suspect there might
possibly be a bug in the process of doing callsign lookups ... but again I can’t reproduce this so it
could well just be operator error (PICNIC - Problem In Chair Not In Computer).
Q: Can I QSY the rig to an arbitrary frequency directly using Logger32?
A:
Yes, this is easier than using the direct frequency keypad on the rig. Simply
enter the
frequency as if it were a callsign
into the log entry panel. Enter it in kHz (e.g. 28020.3) or MHz
(e.g. 28.0203), depending on whether you have configured Logger32 to display frequencies in kHz
or MHz under Setup > Frequency. Logger32 knows a string of numbers is not a callsign so when
you hit <Enter> it QSYs the rig and erases the numbers from the log entry panel. This only works,
of course, if your rig is connected to a serial port to which Logger32 can send the command.
Loggers32 also changes the rig to the appropriate mode for the band segment (as configured in
setup bands and modes) if it is configured to do so under Setup > Radio.
I find this function useful when someone asks me to try a different band. With automatic antenna
switching and a no-tune amplifier, I can QSY instantly, check the band map for spots on/near the
new frequency, listen briefly and send “QRL?” to check if the frequency is clear, and then start
calling the other station while he is still pondering which buttons to press next.
Q: Why doesn’t help work in Logger32?
A:
Most likely, your oh-so-helpful PC is blocking access to Logger32.chm, the compiled HTML help
file for Logger32, which is a security risk. Just like other executable stuff you download from the
Internet, it could be a Trojan horse. Provided you are willing to look gift horses in the mouth (and
you are running Logger32.exe after all), unblock the file by finding Logger32.chm in the Logger32
program directory using Windows Explorer, then right-click the file, pull up the file’s properties and
there at the bottom is the magic option to unblock it:
Q: I have other questions about Logger32. Can you help, Gary?
A:
Possibly - I’ll do my best. But please do your bit by checking in three places first:
1) Check the Logger32 help file, accessed from the menu in Logger32. A lot of effort over many
years has gone into hiding many answers deep within the help file. Your task is to find them. The
index/contents function is very unforgiving, meaning that if you don’t look for exactly what the
authors of the help file called something, you may not find it. This is tricky, of course, if you don’t
know exactly what you are looking for. There are three solutions: (1) Keep trying in the hope that
you’ll strike lucky. (2) Read the entire help file so you will find whatever you are looking for if it is in
there somewhere, and you’ll also learn how the help authors phrase things. (3) Use the help search
function in the hope of eventually homing-in on your answer.
2) Check the Logger32 support reflector on Yahoo! Search the group’s archives. By all means send
your query to the forum for answers the merry band of elves.
3) Check this FAQ and the Logger32 page here on my website.
If you’ve done all three but still have questions, as a last resort please email me but be aware that I
am very busy, so I may take a while to respond. Also, I don’t know much about Logger32’s inner
workings. I’m just a ham who has been a heavy user of the program for most of a decade and a
beta tester for a few years but I’ll do my best, and I’ll probably update this FAQ accordingly.
|