ADIF Import not setting profile information

[KT5V]

I've noticed that an ADIF input is not setting profile information like "My City", "My Grid Square" etc.

This information can be added somewhat easily within QSO manager, but it would seem logical that this information would be added from the active profile on import.

Maybe I'm missing something.

Thanks and 73
de David KT5V

[G4POP]

During thirty eight years as a radio ham my call sign, city, country and all other details have changed many times! I also currently have multiple locations like main address, vacation address, alternative address, how should Log4om decide which details to use.

Entering your profile details must always remain a manual function

[KT5V]

I think you misunderstood my concern Terry or maybe I mis-stated it. Of course entering profile information must be manual - in the set-up. I set up nine or ten profiles so far. I'm talking about what happens when importing an ADIF.

If I have the appropriate profile information filled out correctly and that profile is active, why wouldn't the appropriate fields related to my QTH in the profile not be filled in when importing an ADIF file?

For example: Let's say I'm using my active profile "KT5V". I have it completely filled out with my grid square, city, state county etc. If I make a QSO and add it manually, then the appropriate columns (e.g. my city, my grid square etc.) are filled in the log automatically as one would expect.

But, now let's say, I import an ADIF while using the active profile "KT5V". The ADIF contains QSOs I made from the QTH represented by that active profile (say contest QSOs made in N1MM). I was expecting that the appropriate columns (e.g. my city, my grid square etc.) would all be filled in the log automatically, the same as entering the QSO manually. The program isn't getting this information from the ADIF, its getting it from the profile.

To me this seems to be an error. Maybe this functionality doesn't exist and this thread should move to user requests.

73 de David KT5V

[G4POP]

If I have the appropriate profile information filled out correctly and that profile is active, why wouldn't the appropriate fields related to my QTH in the profile not be filled in when importing an ADIF file?

For example: Let's say I'm using my active profile "KT5V". I have it completely filled out with my grid square, city, state county etc. If I make a QSO and add it manually, then the appropriate columns (e.g. my city, my grid square etc.) are filled in the log automatically as one would expect.

But, now let's say, I import an ADIF while using the active profile "KT5V". The ADIF contains QSOs I made from the QTH represented by that active profile (say contest QSOs made in N1MM). I was expecting that the appropriate columns (e.g. my city, my grid square etc.) would all be filled in the log automatically, the same as entering the QSO manually. The program isn't getting this information from the ADIF, its getting it from the profile.

Clearly there is some major misunderstanding here!

If the ADIF being imported contains the profile information (e.g. my city, my grid square etc.) then the appropriate fields will be filled with that information and can be displayed and filtered in Log4OM as shown below. (Three different profiles used for three different QSO's)

However if you are expecting Log4OM to automatically fill incomplete data in an imported ADIF, for example from N1MM, by using whatever current profile data you happen to be using then I think that would not work because the profile data that you have entered may not necessarily correspond to the actual location, station call, rig, antenna etc used for the competition in the incoming ADIF

On the other hand if you want to update information that is missing from an incoming N1MM contest log ADIF then the best way is to bulk edit in the QSO archive manager. This is far quicker than modifying a profile prior to import, restarting the software, importing the ADIF, resetting the active profile and restarting the software!

There could be an option provided on import to "Update ADIF with current profile data" if there were enough users requesting this feature, so far you are the first!

I don't consider this to be an error in the program its more a feature request! so I will move the thread to the appropriate area

Logging.JPG (52.29 KiB) Viewed 6450 times

[KT5V]

Thanks Terry. I was simply expected the program to something it wasn't designed for. As I look at more and more ADIF files, the issue is less with Log4OM, its the way every program spins the ADIF file differently and often incorrectly as you note in your video on the subject.

QSO archive is an easy solution for data applies to every QSO.

Though not so easy when you have information from the ADIF that varies by QSO that you want to capture in the main log.

73 de David KT5V

[G4POP]

Though not so easy when you have information from the ADIF that varies by QSO that you want to capture in the main log.

What is the missing information that varies by QSO

The best idea is to ask the other software provider to add the missing ADIF fields and provide a method for the user to add that information. If all software providers adhered to the Amateur Data Interchange Format (bad as it is) it would make our lives considerably easier

[KT5V]

Hi Terry, an example would be capturing the information in app specific tags like:

<APP_N1MM_EXCHANGE1:2>CA to fill in the state column

<APP_N1MM_EXCHANGE1:4>DALS to fill the county column (this has the additional complexity of translating a contest exchange like DALS to an ADIF string - TX, DALLAS)

<APP_N1MM_EXCHANGE1:4>1252 to fill the notes column (or SIG) with a CW Ops member's number

A true tower of Babel. I am experimenting with options to massage the ADIF from an app like N1MM into some more standard prior to import.

Thanks again for your patience with my questions Terry

73 de David KT5V

[G4POP]

Hi Terry, an example would be capturing the information in app specific tags like:

<APP_N1MM_EXCHANGE1:2>CA to fill in the state column

<APP_N1MM_EXCHANGE1:4>DALS to fill the county column (this has the additional complexity of translating a contest exchange like DALS to an ADIF string - TX, DALLAS)

<APP_N1MM_EXCHANGE1:4>1252 to fill the notes column (or SIG) with a CW Ops member's number

A true tower of Babel. I am experimenting with options to massage the ADIF from an app like N1MM into some more standard prior to import.

Thanks again for your patience with my questions Terry

73 de David KT5V

State, county and SIG fields are standard ADIF fields, I cannot understand why N1MM has to use App specific fields instead of standard ADIF fields!!!!

There is no way we can capture/Convert Application specific fields during an ADIF import or translate those fields once imported because every program has different app specific fields so there are just too many variations.

There have been many times that we have been asked to modify Log4om because of another programs peculiararities, indeed the import option of updating the country fields and most of the special update choices in the archive manager are due to shortcomings and peculiararities of other software. If we are not careful we will end up spending all our time resolving the shortcomings of other software to the detriment of Log4om development.

Perhaps N1MM could provide a standard format TCP/IP or other live interface for their software so that QSO's logged in N1MM could be automatically recorded in other logging software in real time. Fldigi and JTAlert manage to provide that real time interchange of data, it's not difficult!

[G4NVB]

There are various Excel utilities that combined with AdifMaster that can help with manipulating data from one format to another. Just make sure you are using a backed up file before modifing.

[KT5V]

If we are not careful we will end up spending all our time resolving the shortcomings of other software to the detriment of Log4om development.

Right you are Terry, there are way too many variables.