WA9YSD wrote: "No one has the balls to create a program and make it public domain, that converts files from ADIF 1 to ADIF 2 and vise versa."

ADIF 2 is an upward-compatibile extension of ADIF 1. Any ADIF-compliant application should correctly import an ADIF 1 file; if it fails to do so, its defective.

Since ADIF 2 both extends ADIF 1 fields and defines new fields not supported by ADIF 1, it is not possible to convert an ADIF 2 file to ADIF 1 without loss of information.

What is possible is to extract the ADIF 1 subset of information from an ADIF 2 file. DXKeeper provides an "Export ADIF 1.0" option for this purpose.

There are two more serious threats to "interchange without information loss". The first is the use of proprietary tags and encodings to convey information. To overcome this, DXKeeper can import ADIF files containing proprietary tags and encodings exported by DX4Win, DXBase, Logger16, LOGic, MMTTY, WinLog32, and WriteLog.

The second more serious threat to "interchange without information loss" is that ADIF is silent on the topic of field capacity. If program A is limited to a 16-character QTH and program B is limited to a 32-character QTH, then a QSO logged in program B and exported to an ADIF file that is then imported by program A will not arrive with its QTH intact if that QTH exceeds 16 characters in length.

A proposal to mitigate this problem by specifying a minimum capacity for each ADIF field was defeated because the commerical firms were concerned with the cost of implementation.

Al, as we talked on the phone the other day, is it true that a program that takes the log data and compiles it to and ADIF 1 file has these field definitions QSLMSG, QSLRDATE, QSLSDATE, QSL_RCVD, QSL_SENT, QSL_VIA?

Assuming they are, after exporting an ADIF 1 file to another program say one that uses ADIF 1 or 2, why would a program, with LOTW credit from DXBase, interpret it as QSL_RCVD? There was no card. Now the LOTW credit and Card credit are mixed with the LOTW credit and there is no way to seperate the 3000 cards that I have from LOTW credit unless it go through all those cards again. Not doing it. All that work wasted. Why did that happen and is it a standard practice?

From an ADIF 1 file after exporting, I find some QSOs that had QSL received get dropped off and lost when transfered. What would cause that in eather program? clock timeing? Compiler incompatability, corruption, interuption in data flow or Murphy's Law?

I received from the ARRL my complete upload of LOTW submissions in a ADIF file. What ADIF 1 or 2 I had no time to look at it. Just spent the last 32 hours snow plowing.

Any ways, with the complete upload copy from the ARRL, I do not know, nor do I care right now cause of the hours I put in push that white SHXX around. I do not know if they have CARD and LOTW Credit separated or just said Card Credit. What else can I do with the copy. Please do not confuse this copy with the LOTW Credit file. 2 completely different files.

I would like to know vy looking at my loging program what ever it is, if I need to look for my card in the file or go to LOTW and look for it there. With them merged and by down loading my LOTW CREDIT to the program I have about a 50-50 chance ok 75-25, what ever in looking at the card file and finding it. With DXBase I knew where it was by looking if it was lotw, card or both were cause the program showed me.

<< It's not designed to let you keep the old log when you start the new contest (i.e. 2008 SS does not let you keep 2007 SS). >>

I use N3FJP's VHF contest log along with his AC LOG program. True, there is no option to save old contest logs in VHF LOG. However, there is a simple workaround. Before starting a new contest in VHF LOG, I just rename the log file. I have saved every log from every contest I have worked under N3FJP VHFlog using this method. That way they are always available for future reference.

The log file in VHF LOG is your call sign with a LOG extention. So in my case, it's KA1MDA.LOG. I just rename it to something like 2004_Jan_VHF.LOG before starting new contest. Perhaps this technique might work with the SS log program?

I have only been in one contest where I used a logger.On Jan. 19th I participated in the NAQP SSB contest. This was my first contest in several years and the first at my new station. After reading some positive reviews I downloaded N1MM a few days prior and learned how to run it with some fake qso's. The program worked great and was very easy to use. Yesterday before the big game I went ahead and made an ADIF file and imported into DXkeeper. It worked perfect. My NAQP log contained call, name and state/province. DXkeeper imported the ADIF file, interfaced with QRZ during the import and filled in the blank fields.

Not one error. I was very impressed. I was only able to work a few hours of the contest but import of 400+ contacts wit no hiccups was cool. I set DXkeeper to default all of the QSL fields blank on import and that worked just fine.

Now I am trying to get started with LOTW so I can start using that upload feature of DXkeeper as well. The more I use this software the more I like it as I rack up some experience.

I use DXLabs Suite of software - it is excellent. It does have its drawbacks - for instance it is not really set up for chasing grids on VHF and tracking them. But that is a smal portion of what I do. One thing that excels is Dave's (AA6YQ) support. I do not think he ever sleeps - I can pose a question and usually within minutes I have an answer from him - or from someone else in the user group.

For contesting, I use the N3FJP programs. Scott (N3FJP) is also VERY fast on responding to questions. The programs are also very good - I use them for contests because they work well on a network, and easy to set up. When the contest is over, I export to an ADIF file - open up DXKeeper and with a couple of key clicks - import all the log. Then once I add those QSOs, I make two! additional key clicks and upload them to LOTW or print out needed QSL cards. Very fast and seamless.

Personally I would recommend DXLabs for general logging and record keeping and the N3FJP logging programs for contesting.

Copyright 2000-2015 eHam.net, LLC
eHam.net is a community web site for amateur (ham) radio operators around the world.
Contact the site with comments or questions.
WEBMASTER@EHAM.NETSite Privacy Statement