Replies: 3 comments
-
|
Hi Wolfgang, I would start from the end of your message. I have the same approach - help as you can but work must continue. Unfortunately, I am quite busy at work, therefore work on QLog is not going so fast as I planned. I'm glad you made these comparisons. I also verified exports/imports many times, but you know - man makes mistakes. That's why I'm glad that another person will look into it.
I can confirm that it is NOT issue. It is a wanted behaviour. CQRLog and many others log applications generate so called "Application-defined" ADIF fields. I decided that these Application-defined fields would be imported to QLog - they are save to "Additional Fields" column as JSON string. If QLog exports ADIF file then the Application-defined fields are exported too - I do not want to lost any information.
It is a new feature for the release 0.5.0. Some of the ADIF fields have two variants. Let me explain it for example for NAME field. ADIF defines NAME and NAME_INTL field. Both fields have the same meaning with one exception. NAME must contain only ASCII characters. NAME_INTL can contain UTF-8 characters. But the real work uses UTF-8 character and many applications (for example WSJT-X or FLDigi) send incorrectly UTF-8 characters in "NAME" fields. Therefore I decides to implement following algorithm.
Just for information - ADI must not contain UTF-8 characters, ADX format can contain UTF-8 characters.
Import/Export from/to ADI or ADX is stable from my point of view now. I do not rule out that it is without error, but I do not plan any major changes in this yet.
I am planning for release 0.7 or 0.8 one new feature that could help you. QLog will emit UDP packets when QSO is logged. Unfortunately, I do not have detailed specification now but I am planning to send UDP messages with ADIF fields (maybe in JSON format) to selected IP addresses. Just for the purpose of connecting to external applications such as various weblogs (Cloudlog etc.). I planned it for this release, but unfortunately, I wasn't very ready and I need to think about it more to make sense - Something like N1MM and others have. I want to implement messages like new / updated / deleted QSO etc. Regards |
Beta Was this translation helpful? Give feedback.
-
|
Hi Ladislav, Thank you very much for the detailed explanations. I can now better understand your considerations. For my Python application, I have so far simply used the current adi-file that CQRLOG creates as a backup on exit. I have already replaced the ADIF parser in my script with a version that imports the current adx-file from QLog backup. Only minor adjustments are then required for the rest of the script, so that I am already prepared for a later switch to QLog. The fact that the work on QLog does not progress as quickly as planned is not a problem, but probably rather the rule with such projects, hi. After all, it's a lot of work that has to be done in addition to work and other commitments. So respect for your work and Petr's work on CQRLOG. 73, Wolfgang |
Beta Was this translation helpful? Give feedback.
-
|
For testing purposes I wrote a small Python script to edit the QLog database directly. The purpose was to try out possibilities to post-process the data import from CQRLog. I found out that I can transfer the element 'QTH' from the '<APP_CQRLOG_PROFILE ...' into the QLog fields 'my_city, my_city_intl' and the element 'RIG' into the fields 'my_rig, my_rig_intl'. This is only in case the import is done from CQRLog and the QTH profiles were used there. With the element 'Locator' a data transfer is here unclear, since I entered the Locator with QSO's from the vacation mostly into the 'comment' field. Further one could convert with the adif import not only the fields 'name, name_intl' and 'qth, qth_intl', but also the fields 'notes, notes_intl' and 'comment, comment_intl', as well as also other '_intl' fields, if available. There is certainly a variety of different adif log formats that need to be considered here. But I think that a number of CQRLog users will switch to QLog. |
Beta Was this translation helpful? Give feedback.
-
Hi Ladislav,
after comparing the ADIF files from CQRLog and QLog (after importing the ADIF file), I saw that in the QLog adx-file there are some data fields from CQRLog.
For example <APP_CQRLOG_DXCC>,<APP_CQRLOG_PROFILE>, <APP_CQRLOG_QSLR> or </APP_CQRLOG_QSLS>.
On the other hand, there are new data fields that are not included in CQRLog's ADIF data.
Furthermore, I have seen that some headers in the QSO window, for example, distinguish between "Name" and "Name (ASCII)".
After importing the ADIF data from CQRLog, the names are mostly displayed in the "Name (ASCII)" column. But some also in the column "Name". I think that these data fields could be combined during import. Likewise the "<APP_CQRLOG" data fields.
My question therefore: Is there already a defined strategy when importing ADIF data from other programs, or will this section of QLog be further developed in the future to have a uniform internal ADIF data structure.
I'm using the ADIF files here to generate a static online log for my website with a Python script and have already started to change the parts for importing the ADIF data into the script here. Also to distract me a bit from the current situation in Europe. That's why this came to my attention.
That's why I noticed this.
73, Wolfgang
DL2KI
Beta Was this translation helpful? Give feedback.
All reactions