Import ADIF data from CQRLog into QLog

[dl2ki]

Hi,

after there was an update to version 0.9 from the Ubuntu PPA today, I will now switch from CQRLog to QLog as my primary logging program.

Therefore I ported my ADIF data from CQRLog to QLog. Here is a short report. Perhaps it will yield some additional ideas.

=== 1. ===

After exporting the ADIF data from CQRLog, I found incorrectly encoded UTF-8 characters ('ü', 'á, 'Ž', ...) in the data fields 'NAME_INTL', 'QTH_INTL', 'COMMENT_INTL' and 'NOTES_INTL' in many records of the adi file.

Examples:

<NAME_INTL:7>JürgenQTH:10Ca ...
<NAME_INTL:6>Jónas<QTH_INTL:10>ReykjavÃk<QS ...

These are older records and I think this is/was a problem with CQRLog. The encoding of the adi file itself is 'UTF-8'.

These incorrectly encoded UTF-8 characters were still present in the data fields after the first import of the ADIF data into QLog. Therefore I corrected the characters with a Python script and the Python module 'ftfy' in the original adi file first.

I can't judge if this will be a problem for other users, but maybe a similar function can be integrated into the QLog import, if it's not a big effort. The functionality is only needed once.

After re-importing into QLog, the fields are correct. Also the character matching of the fields 'name' and 'qth' is ok.

• It might be good to have a checkbox option during import to delete the existing data before import.
• Furthermore a checkbox 'import without duplicates' would be useful.

=== 2. ===

Subsequently, additional station profiles were created for the previously logged portable QSOs. The basis for this were the locators of the portable QTH's entered so far under 'my_gridsquare'. Additional portable antennas and portable rigs (Hamlib dummy) used here were also created.

Depending on the portable locator stored in the data field '_my_gridsquare_intl', the data fields 'tx_pwr', 'my_antenna', 'my_antenna_intl', 'my_city', 'my_city_intl', 'my_gridsquare', 'my_rig' and 'my_rig_intl' were then filled with the corresponding data.

For this purpose, a simple Python script was created that processes the data directly in the QLog database.

=== 3. ===

Afterwards the city name and the rig from the CQRLog QTH profile were taken over for the own home QTH.

If 'QRP Transceiver' was specified as rig in the CQRLog QTH profile, the data field 'tx_pwr' was set uniformly to '5'.

Depending on the band entered in the data field 'band' the data fields 'my_antenna' and 'my_antenna_intl' were assigned to a corresponding antenna (here: ZS6BKW, GAP-Titan DX 30m and 15m). This is no longer exactly traceable, but corresponds to the rule case.

The corresponding values (14, 28) were entered into the data fields 'my_cq_zone' and 'my_itu_zone'. Additional data fields can also be assigned with data later via a corresponding Python script.

A simple Python script was also created for this, which processes the data directly in the QLog database.

[foldynl]

I will now switch from CQRLog to QLog as my primary logging program.
Thank you. I am pleased that it is also useful for someone else.

=== 1. ===

After exporting the ADIF data from CQRLog, I found incorrectly encoded UTF-8 characters ('ü', 'á, 'Ž', ...) in the data fields 'NAME_INTL', 'QTH_INTL', 'COMMENT_INTL' and 'NOTES_INTL' in many records of the adi file.

Examples:

<NAME_INTL:7>JürgenQTH:10Ca ... <NAME_INTL:6>Jónas<QTH_INTL:10>ReykjavÃk<QS ...

Please, could you send the origin records generated by CQRLog? I will verify whether CQRLog has an issue with export or what happened.

I can't judge if this will be a problem for other users, but maybe a similar function can be integrated into the QLog import, if it's not a big effort. The functionality is only needed once.

It is not good idea to implement fixes for other applications in QLog. Qlog would become confusing. But I can imagine an external utility (written in python ;-) ) that preprocesses the incorrect CQRLog export.

• it might be good to have a checkbox option during import to delete the existing data before import.

It is very danger option. This is not a feature that would be needed every day. It is otherwise possible to do this by deleting the QSO via the log - CTRL + A and DEL (sometime is it needed to repeat the action because CTRL+A does not mark all QSO - must verify why it occurs).

• Furthermore a checkbox 'import without duplicates' would be useful.

No sure if I understand you correctly but this function is already implemented. If you import ADIF file and QLog detected duplicates, then it ask how the duplicates should be resolved.

=== 2. ===

Subsequently, additional station profiles were created for the previously logged portable QSOs. The basis for this were the locators of the portable QTH's entered so far under 'my_gridsquare'. Additional portable antennas and portable rigs (Hamlib dummy) used here were also created.

Depending on the portable locator stored in the data field '_my_gridsquare_intl', the data fields 'tx_pwr', 'my_antenna', 'my_antenna_intl', 'my_city', 'my_city_intl', 'my_gridsquare', 'my_rig' and 'my_rig_intl' were then filled with the corresponding data.

For this purpose, a simple Python script was created that processes the data directly in the QLog database.

how would you solve it without an external script?

I see two possible solutions.

1. In the import field, define multiple default values to be filled in when importing
2. perform the import as is and then use Group Edit to add the necessary information.

A simple Python script was also created for this, which processes the data directly in the QLog database.
maybe it would really be useful for us to add your script directly as part of QLog (as an external part). QLog itself cannot perform various conversion from external applications (CQRLog, N1MM etc). But the external script cat do it.

[dl2ki]

Thank you. I am pleased that it is also useful for someone else.

I hope that there will be more people using QLog. QLog has the potential to be a good alternative. Maybe you should do some more advertising.

Please, could you send the origin records generated by CQRLog? I will verify whether CQRLog has an issue with export or what happened.

I will filter out some of the records from the ADI file of CQRLog once. As far as I remember, the topic was already addressed in the CQRLog forum. Presumably this no longer occurs with newer CQRLog versions, so it's more likely to affect older records

No sure if I understand you correctly but this function is already implemented. If you import ADIF file and QLog detected duplicates, then it ask how the duplicates should be resolved.

Yes, you are right. I had several duplicates here during the import and therefore had to confirm several times. But it is not a big effort to leave it with the current handling.

how would you solve it without an external script?

No idea!

It's just very individual, which data the user wants to continue using after the import.

But since I wanted to try the Python module 'sqlite3' anyway, this was a good opportunity, hi.

I think that other users will also ask the question how to import the QTH profiles from CQRLog. But the application of external Python scripts can't be expected from everyone.

I also don't know the specific peculiarities of other log programs. But perhaps one should wait first, until appropriate inquiries come.

[dl2ki]

Thanks for pointing out the CQRLog commit. I couldn't remember where I had read about it.
But if so, the problem will affect many who port their data from CQRLog to QLog.

I have re-imported my data in the meantime. Here I have sorted the CQRLog ADI file before accordingly.
As a result, I now have a consistently sorted database and adx-backup files. Is not essential for the use of QLog, but still useful for me.

[dl2ki]

*** 4. ***

After importing ADIF data from CQRLog, many records had 'I' in the QLog data field 'qsl_sent'.

This has the following cause:

When 'QSL_S' = 'N' is selected in the DropDownMenu in the CQRLog 'New QSO' window, CQRLog stores an 'I' in the ADIF field '<QSL_SENT:1>'. CQRLog stores the selected value 'N' in the ADIF field '<APP_CQRLOG_QSLS:1>N'.

Therefore, after importing the ADIF data from CQRLog, there are incorrect values in the QLog data field 'qsl_sent'.

In this forum post I documented the behavior once.
https://www.cqrlog.com/comment/9899#comment-9899

In my case there were also entries, '<APP_CQRLOG_QSLS:2>MB' present.

I therefore transferred the value 'N' from the CQRLog data field '<APP_CQRLOG_QSLS:1>' to the QLog data field 'qsl_sent' if an 'I' was set there.

For the cases '<APP_CQRLOG_QSLS:2>MB' present here, 'M' was entered in the QLog data field 'qsl_sent_via'.

The correction was also done with a small Python script directly in the QLog database.