Description

How it works

Help and manual files

An essential thing.

Generic IOTA support

There is impossible to predict IOTA reference number from the callsign, however any non- earthbound country has a limited number of possible IOTA numbers. A database with prefixes and corresponding possible IOTA numbers is already finished. Next step is to incorporate it into log - if such prefix appears, the IOTA box on the logging screen should change to popup menu allowing to simply choose the right one. Also, a warning "Possible IOTA" should appear. An IOTA statistic sheet should be derived from all IOTA entries present in the log, also warnings on the possible new ones.

Membership lists support

There are many clubs with their contests, activities and hard-to-get awards. It is very interesting to see if an operator is a member of a particular club. A set of 60+ databases is already prepared, the next step is to incorporate it into log. Type a call or click on a spot, you will see the memberships. As above, it should be employed for filter criteria building and stats. Except YPlog (Windows), there is no logger with this option suitable for on-line logging!

Local CD-ROM callbook support

An usual feature known from many Windows loggers, however only QRZ is known to support Linux. Since the CD ROM is rather slow, it should work also with local copy on your hard drive.

QRZ CD-ROM needed. There is no other known CD-ROM Callbook publisher supporting Linux. The data format of any Callbook (ie. Buckmaster, Flying Horse etc.) can be hacked but we don't want to do this - we prefer an arrangement with the publisher who should also provide his format specification.

County resolution from the ZIP code

ZIP codes in many countries are suitable for county or any other local information. You can retrieve the ZIP code from the callbook (web or later local) and compare with already prepared database. This option is primarily meant for US County hunters but can be easily extended to any other country (ie. my ZIP code is 128 00 which means my county ID is APB :-)

CW interface

Many Windows loggers have a CW interface enabling to use F-keys or direct typing into a dedicated box. In Linux, there is possible to evaluate cwdaemon but there is a rough edge - this daemon was initially made by not so keen high-speed operators so the versions 0.8 and down are rather useless at speeds above 20 WPM. Since the mostly used speed range is from 30 to 45 WPM, you will need a custom-built low latency kernel, then the cwdaemon ver. 0.9.1 and above is quite good up to 40 WPM, acceptable to 50 WPM and can be used up to 60 WPM but the speed setting and weighting is not very accurate. A good advantage of cwdaemon is the standard parallel port interface compatible with N6TR's TRlog, CT by K1EA and many others.

Another option is sound card generated code which can be pretty good also at 200 WPM! You need to build a dedicated interface where the beeps from the souncard are rectified and the resulting voltage drives a switching transistor. Which option (or both), to be considered. In contrary to other known application, this CW interface should support both letter and word modes (word mode - the sending starts if you type down the whole word and press spacebar, during sending you type another word and press spacebar and so on).

A good choice is also a support of the Winkey by K1EL.

RTTY and digital modes interface

There is a lot of sound card programs which can be interfaced with the logger, however we should look for a program providing reasonable DSP filtering (at least at the MMTTY level), a number of supported modes and last but not least, true FSK output enabling direct switching of your radio in the FSK mode. Sound card/AF input generated RTTY is a nightmare!

Incomplete resources. The is no known Linux program providing true FSK. The most promising seems fldigi by W1HKJ with its pseudo-FSK. A preliminary arrangement with the author has been made, now we need more cooperation with the group around fldigi. A task for early 2009.

QSL processing

A "fast mode" option should enable tagging of single records or groups of records in the database and export it into a file which can be processed either directly or converted into PDF and printed later. Essential is grouping by callsign, allowing to print more QSO with the same station on a single label/QSL card and an should be possible to mark differently QSL sent via bureau and via a manager.

LoTW interface

A set of QSL records made in a similar way as above should be processed into a signed .tq8 file which will be send directly from the log to the LoTW server. A corresponding mark of LoTW QSLing should be made into log.

eQSL interface

A set of QSL records made in a similar way as above should be processed into an ADIF file which will be send directly from the log to the eQSL.cc server. A corresponding mark of eQSL QSLing should be made into log.

Questionable. >A standard ADIF file can be used, no need of a dedicated interface. Also, eQSL is still not world wide accepted, we decided to wait with counting the eQSL records as accepted.

xplanet interface

Xplanet is very known mapper which can be very easily adapted to interface with any logger. There is possible to mark cluster spots on the map. Xplanet also allows to change map projection so the user has a choice of azimuthal (directional) and a wide variety of planar projections.

band output interface

A part of the standard parallel port interface is the BCD-coded band output permitting to drive antenna switches, band filters or any band related devices directly from the logger. Pins 2, 7, 8 and 9 are used.

Questionable. Many modern computer main boards are now equipped with USB ports only. The LPT port became a hard-to-find one and serial ports also disappearing. Relying to ports other than USB is a dead horse ride. The former standards became obsolete, there is no current standard

voice recorder interface

Similar to the CW interface allowing to send our predefined messages using F-keys, voice recorder does the same on phone. A dedicated interface must be used.

remaining

to do

done

assumed as finished. If no comments till end of June 2009, will disappear from the TODO list.

in process

we just work on it. Very possible to appear in next 1-2 releases.

postponed

Incomplete resources. Read the footnote in corresponding paragraph.

to be removed or reworked

User input asked. Since first TODO list (Sep. 2007) things changed making our solution obsolete.

user definable default radio control frequencies

The radio control panel contains buttons allowing quick band change. The radio is now tuned to a fixed frequency in the upper CW band. This should be changed and the 'button frequencies' should be user definable.

tracking band map

Tuning the radio, the band map entries (calls) should jump automatically into the call box in the logging window. This should be done if the radio frequency matches the frequency in the band map within user definable tolerance (say, +/- 200 Hz as reasonable default). The record should be highlighted in the band map, say with changed background. This strip will move if tuning the radio (not continuously, is should jump from a record to another).

user definable on-line award statistics

Records matching the criteria should be tracked on-line, not just on demand. These statistics should be available from the same menu group as DXCC, zones, etc., also with new ones visible in the details window.