This project is very ham radio related and dedicated to a very special aspect of the VHF contest activity. If you are not fimilar with that and you wants to know what that supposed to mean, look at my related blog article.
There is a new version in 2023, which is described in a further blog article
Locator database for N1MM? What’a the reasons behind the project?
In the (region 1) VHF contest it is important to know the locator (the position in maidenhead coordinates) of the potential partner station at a possible early point in time. First, it is good to know in which direction the station is located to rotate the antenna quick without a long search. Or to decide that a rotation will take too long or that the backward direction will also work 😉 If you hear a station calling and you need to long to answer the station may further rotate their antenna and disapear. The chance for the QSO is missed. Second the locator is part of the data which must be logged. Especially in bad conditions it is very usefull to have an expectation.
That’s why the call-locator database is an important part of a contest logging software for VHF contests. Long times I used the German WinContest software from DD3KU. But in my eyes it has some disadvantages which became as more boring as more I got into the contest business. For instance, there is no support for transceiver control and CW output. And: some details in the user interface disturb a fluid work flow especially in hectic moments. In short wave contests I use the N1MM logger software that also supports Region 1 VHF contests but don’t have an appropriate call-locator database. So, a solution must be found.
There exist some result lists with locators on the net and some result lists linked to the full contest log of stations which had worked many other stations. Together with the past logs of our local radio club it seems that this is a solid base for a suitable call-locator database. I wrote a program to import various data sources and to generate an import file for the N1MM logger. The import file can be imported via the ” Import call history” function. (thanks to DL5MO)
My program is a command line tool that reads in the files in the subdirectory “data” and generates the following output files:
- n1mm_qth.txt: This file contains the generated locator data base ans can be imported in N1MM before the contest using the “Import Call History”-Function .
- master_dta.txt: File with the calls only. It can be used to create specific master.dta using the free MEdit
.dat: This is the extracted data base from the fies in the data-directory. It can be used as an input file in further runs of the software. Simply delete all files in the data directory and copy this file there.
At this point it is from interest what kind of data can be put in the data directory to be read in by the program:
- A good base is the locator database VHF.DTB of the WinTest software, a commercial contest program. The database can be found on hte net :hier in the vhf.zip ot the vhf_r1_2011.zip (or which year ever). Unfourtunately this data base is too small.
- (own) logs in ADIF-format. The file extension must be .adi.
- WinContest .exp files, which should be sent to DD3KU to enhance his own data base.
- .edi files, which are used to clear the contest. Beside own files there can be found some logs on the net.
- nearly all text files which contains columns with call and locator. The format of the text files must be defined in the qthconv.ini. Several different formats can be used if every format gets it’s own extension. The format if the qthconv.ini is describes in the file. It is convenient to copy contest results from the net.
- … and of course the
files from past runs of the program.
In reality a mix from several data sources is needed. The official result lists are difficult to convert (much manual cut and past, and correcting some lines, and so on) and contain only the station which had sent their logs. Real logs in .edi or .adi format are very easy to integrate (just copy in the data directory, perhaps the file names must be renamed) but may contain errors and containing normally only few stations. But the logs from you and your friends containing also stations from your environment which do not send in their logs.
From this page the software to create the data base can be downloaded. I provide a base data base and master.dta based on German result files from 2011 and 2012 and from some OK logs. For stations in OK and OL it may be enough but others need additional input.
The weighting factors
Logs may contain errors. That’s why the program tries to manage possible failures. QSOs from .edi or .adi logs gets a weighting of one point . QSOs from other sources may get an higher weighting. some factors are configurable in the qthconv.ini file.
The weighting points for a locator are added if the locator is contained in several sources. N1MM can only deal with two locators per call and so the program selects the two locators with the highest weighting point count.
A Linux version I will create on request. Please ask.
A ready to use import file and master.dta is included with the program.
- Extract the ZIP-file in any directory which is writeable (NOT under c:\programs if you use Win7 or you are not Admin)
- Fill the data directory with data (own logs, result tables…, see above)
- Launch qthconv(.exe) This is a command line program (you will see a black shell window) without any graphical interface
- Import n1mm_qth.txt in n1mm (“File/Import Call History”)
- If desired, convert master_dta.txt with MEdit to a master.dta and copy it – for the VHF contest – into the N1MM program directory. Keep the original master.dta for the next short wave contest 😉
Have fun !
May 2023, Version 1.3
- selects always the locator with the most references in the data
- more data directories can be configured in the ini-file
dein qthconv Programm hat schon gute Dienste geleistet, vielen Dank dafür. Ich habe zahlreiche EDI-Logs damit zusammen geführt und vorher die UBN eingearbeitet. Das werden schon fette Dateien. Allerdings habe ich es nicht hinbekommen, dass ganz gewöhnliche txt-Dateien korrekt verarbeitet werden. Ich habe die ini-Datei so angepasst, dass das Call in der ersten Spalte und der Locator in der dritten Spalte erwartet wird. Klappt nicht, das Call am Anfang der Zeile wird immer ignoriert. Zum Glück kann N1MM CallHistoryFiles in diesem Format selber verarbeiten. Aber vielleicht hast du ja irgendwann Lust, deinen alten Code diesbezüglich nochmal anzusehen.
many thanks and congratulations for your very useful program!
Can you please check, it seems data from 6m QSOs is not imported, for ADIF files.
If I replace 6m with 2m and also freq 50 with 144 it works OK…
TNX & 73,
Danke fuer die schoene Zeit auf dieser Webseite. Macht weiter so.
Da komme ich gerne wieder vorbei.
ich bin angehender Funkamateuer ( Prüfung Klasse A im November ).
Mich würde interessieren, wie aktuell die Daten der Rufzeichen im Bezug auf den Locator sind, da ich momentan selbst ein Projekt entwickle, bei dem mir eine Rufzeichen-Locator-Liste gute Dienste tun würde. Reicht zum Beispiel eine Aktualisierung alle 6 Monate aus, oder sind die Abweichungen der Daten dann schon wieder zu groß?
73 de Simon
P.S. Sehr schöne Seite!