Club membership lists (Issue renamed)

[dl2ki]

Note on Issue https://github.com/foldynl/QLog/issues/49

An additional feature of CW functionality could be CW club membership lists.

Hints about the implementation in CQRLog can be found here: https://www.cqrlog.com/node/2224

Many lists are only accessible for members. They would have to manage the lists and updates themselves. Other lists are publicly accessible, so updates could be automated.

Here are some accessible sources of member lists:

A1 CLUB since 1998 https://a1club.org/roster/index.htm

Activity Group CW-DL https://www.agcw.de/wp-content/persist/Mitglieder.csv

International Independent CW Club https://cqcw.ru/list.html

The CW Operators Club https://cwops.org/membership/member-roster-2/

Radio Telegraphy High Speed Clubs https://hsc.lima-city.de/de/mliste.html ASCII-Format: HSC only CSV-/XLS-Format: HSC, VHSC, SHSC, EHSC

First Class CW Operators' Club https://www.g4foc.org/members

LIDS CW Club http://lidscw.org/members

North American QRP CW Club http://naqcc.info/memberlist_complete.php

A-1 Operators Club http://www.arrl.org/a-1-operator-club-roster

Diplom interests group https://diplom-interessen-gruppe.info/downloads/

The club membership information could be displayed in an additional tab after 'My Notes', for example. In case of multiple club memberships, the information would also be multiline.

Whether the information is stored in the ADIF record would have to be checked.

[dl2ki]

For example, in the ADIF record of CQRLog, you can find the HSC membership of the QSO partner after the QSO in the field '<AWARD:9>HSC #xxxx'. Here it is to be considered that I am a HSC member myself.

The AGCW membership is not taken over in the AWARD field, although I am also a member there.

It would be therefore still to consider, how the program-internal processing of the club memberships and Awards takes place.

In CQRLog under 'Show QSO list -> Statistics' you will find a menu 'Membership tracking -> Rebuild membership statistics'. The data records can apparently be updated there manually.

However, I have not investigated this in more detail.

[foldynl]

Wolfgang,

may I kindly ask you?

What is the next use of information about club membership? Do you export log to ADIF and send it to individual clubs when you should get a diploma? Can you tell me more details about how you work with membership information? Do you search it, do you prepare statistic from the information?

[dl2ki]

Hi,

the main purpose of this informaion is to collect the confirmed QSO's for club internal awards and for general information if the QSO partner is a member of a certain club.

For this the information about a club membership must be stored in the QSO record in a suitable (AWARD) field, in order to be able to evaluate these later in a club member statistics.

It is not necessary to consider all clubs. The number of 5 member lists provided in CQRLOG is sufficient from my point of view. Herewith each user can define in free selection max. 5 clubs, which are evaluated for this.

It is necessary to display the membership in the "New QSO" area directly (Membership Field / Award Field), in order to be able to determine whether the QSO partner is a club member. With confirmed QSO's this is indicated in QCRLog in the "Detail window". Here the info window could be used if necessary, or a marking in the "Membership Field".

Example:

Already confirmed HSC member! (DL2xx #xxxx)
Already confirmed VHSC member! (DL2xx #xxx)

The evaluation could take place e.g. in a "club member statistics", by export of the QSO's over an export filter, in order to submit these then with the club, or in other way.

Whether and how one realizes the whole in detail, must be considered. Also here one should include other users with their opinion.

At the moment I do this alternatively by running a Python script over the database and adding the information about the memberships in the "My Notes" field. Of course, this is then only possible afterwards with the existing QSO's. A direct display after entering the call is missing in this case.

For additional info please just ask.

[dl2ki]

Hi,

the membership function is not limited to CW clubs, but applies to all clubs with internal awards.

The often used programs "UCXlog", "Logger32" or "SwissLog" and others lift this functionality integrated. Maybe you can get some suggestions there.

UCXlog: http://www.ucxlog.org/ The ZIP file contains more information.

Logger32: https://www.logger32.net/ More information in the manual. https://www.g4ifb.com/Logger32_v4_User_Manual_DRAFT.pdf

Swisslog: https://www.swisslogforwindows.com/ More information https://www.swisslogforwindows.com/english/Help/QSO%20Entry/QSO%20Entry%20Window%20Buttons.htm#Membership

All programs can be tested under Windows.

The activation of the used lists could be done according to the settings to "Bands", "Modes".

[foldynl]

I asked the question wrongly. What I'm talking about is whether you export data in ADIF format and then send this data to get a diploma.

I studied how the issue of the club membership is solved in the ADIF format and unfortunately, it is not precisely defined.

Unfortunately, the current implementation in CQRLog does not meet the ADIF standard. As you said, CQRLog exports the information in the AWARD tag. Unfortunately, this tag is not defined in ADIF. It is possible, and this is how other programs do it, to define a so-called User-defined tag and save the information to the tag. Maybe it was Peter's (ok2cqr) intention to do it this way. Unfortunately, the User-defined tag format must be defined in the header of each ADIF file. And CQRLog doesn't do that.

I also read the ADIF developer mailing list and there is no clear opinion on how to store the information about club membership. There are some specific ADIF fields (Ten-Ten, UKSMG etc) dedicated to club membership but it is only limited set - allow my personal opinion: ADIF seems to succumb to lobbying more than to standardize transmission - there are many things directly connected with the given software and they do not try to generalize - and that's a pity

That's why I'm a little confused about how to implemented it in QLog and I'm asking you if you export the ADIF file somewhere and do they need to have a specific ADIF tag with club information or do you just want to do some statistics on the data in QLog and clubs accept a standard ADIF without any specific tag.

[foldynl]

Just to illustrate how confused the situation is, for example Log4OM uses the so-called ADIF's Application-defined field "APP_L4ONG_ASSOCIATIONS" to store the membership.

[dl2ki]

Hi,

yes, this is apparently the same problem with other log programmes. I had to think about it and do some research first.

It seems to me that the "Application-defined Fields" are a possibility, as these fields can be assigned to a specific application, in this case QLog.

Example:

<APP PROGRAMID="QLOG" FIELDNAME="CLUBAWARD" TYPE="S">HSC #1234, AGCW #6789</APP>

resp.

<APP_QLOG_CLUBAWARD:21:s>HSC #1234, AGCW #6789

These fields would also comply with the ADIF standard.

When transferring data to another logbook programme, these fields always have to be adapted separately. Therefore, I do not necessarily see a disadvantage here. If you change from 'Logger32' to 'UCXlog' or from 'CQRLog' to 'QLog', you will have the same problem.

In the case of field data, the entry of a confirmed QSO may include one or more Clubawards, depending on which have been activated.

I do not know the procedures for submitting QSOs to the various clubs. Probably an export (ADI/ADIF/CSV ...) with a filter will be the most universal solution. The user must then prepare the data sets according to the requirements of the clubs.

In CQRLog, you can filter the records according to the content of the "Award" field and then export them in different formats for further processing.

In one case, I extracted the relevant records from the CQRLog adi backup file using a Python script and created a suitable Excel file from it using "xlsxwriter". But this is not a universally valid solution!

It must also be taken into account that there must be an update option for the lists. For some lists this is possible automatically, but for others the user has to update them manually.

However, it is up to you to decide whether you want to implement this feature.

[foldynl]

Many thanks for your comments.

I previously thought that the mentioned solution in the ADIF's mailing list (use the User-defined fields) would be good, but I think that your proposal to use the Application-defined field will be safer - we will avoid a conflict in the event that someone uses a tag with the same name in different application and with a different format. The application tag eliminates this.

I needs to think about it more.

[dl2ki]

For the live display, the memberships would have to be displayed directly in the NewQSO area, when a callsign is entered in the "Callsign" field. Therefore, a restriction to [n] club memberships is certainly useful here.

Example:

or

In the database the information would have to be stored only when the QSO is confirmed ("qsl_rcvd = 'Y'" or "eqsl_qsl_rcvd = 'Y'").

<APP PROGRAMID="QLOG" FIELDNAME="CLUBAWARD" TYPE="S">HSC #1234, VHSC #567</APP>

Updating the "qsl_rcvd" or "eqsl_qsl_rcvd" fields should then trigger the data transfer to this field.

[dl2ki]

I needs to think about it more.

Yes, when I think about it, there are a lot of questions.

• In the example above, it must be marked when one or more memberships have been confirmed. Perhaps by changing the colour of the text/subtext from white to green or in another way. The marking (confirmed) must be done both in the live preview after entering a callsign, after editing the field "qsl_rcvd" manually and after updating all other online confirmations (eqsl_rcvd, lotw_qsl_rcvd, ...). The type of confirmation (qsl, eqsl, lotw, ...) should be recognisable later in the export of the data records.

• Are standard lists supplied with the installation of QLog? Are these included in the installation package, or are they downloaded during the installation or after activation?

• In which data format (csv/txt, xml, json, ...) are the lists stored?

• When is an update check / update carried out? With every start of the program? For all saved lists or only for the activated lists?

• What happens (update check / update) when a new list is activated while the software is running?

• Are the lists completely replaced during the update, or are only new or changed data processed?

• How is the distinction made between the "official" lists of QLog (which are probably only those for which automatic updates are possible) and the lists created and maintained by the user himself?

• Are all saved lists read in when the programme starts, or only the activated ones? What are the delays in starting the software? Here, too, the restriction to a maximum number of activated lists could be useful.

• Does it make sense to save the lists in the database or in an additional list database after reading them in and only read them in again if the list has changed (checksum verification)?

• ...

Yes, I think you have to think carefully about the whole procedure beforehand. It doesn't seem to be as simple as it looks, hi. But since you have found good solutions for all extensions so far, that will certainly also be the case here.

[dl2ki]

A good place could also be the "Detail" tab. Here is an example of a confirmed connection. This is probably better than the "Info" window.

But this is supposed to be the last design suggestion now, hi.

[foldynl]

I would add next questions, which needs to be answered.

1) Is a membership number required? Or you need just to have a statement that you already have a (confirmed) QSO with the given club. 2) Coloring according to the Worked/Unconfirmed report is difficult, because some clubs may have rules that it is necessary to have QSOs with, for example, 10 members. These rules may differ from club to club

Currently, I think Club-Membership field should not be exported because it is not "standard" ADIF field - each software implements this in a different way, therefore, interoperability is not guaranteed. Membership is only information for the operator that DX is a member of club.

Another thing is to generate some statistics. I think the membership "recalculation" should be carried out when a membership report is generated (this means only if you click on "create membership report/statistic"). It means that it is not needed to save the information about the membership to database - membership will be used in case it is needed

To be honest, I does not collect QSOs with specific "member" of the club that's why my thoughts can be quite naive. At the moment I have no idea how exactly it should behave.

[dl2ki]

Is a membership number required? Or you need just to have a statement that you already have a (confirmed) QSO with the given club.

With UCXLog, there are some member lists that come with it. In CQRLog you can download many member lists in "Preferences, Membership" and assign them to the 5 selection fields. https://www.cqrlog.com/help/h3.html#ah33

When I look at the membership lists of the two programs, there are those with membership numbers and those without.

Therefore I think that the membership number is not necessary in all cases. If necessary, you would have to ask some clubs how this is handled.

My own experiences refer only to some CW clubs, where membership numbers are usual. This also allows a clear assignment to the callsign. The lists HSC, VHSC, SHSC, EHSC, FOC, FISTS, CWOPS, AGCW all contain the membership numbers.

With HSC #1970 or AGCW #3944 DL2KI is directly verifiable as a member.

When submitting the records, the clubs can then quickly verify this themselves. As a rule, the membership numbers are retained even after leaving the club and are not assigned again.

Coloring according to the Worked/Unconfirmed report is difficult, because some clubs may have rules that it is necessary to have QSOs with, for example, 10 members. These rules may differ from club to club

This is a matter for the user to ensure himself, in consultation with his club. A logbook program cannot do all this itself.

QLog can only determine if a call is included in a member list and if at least one QSO is confirmed. The user must then check and comply with the criteria set by the club before submitting the records.

Therefore, I think it is sufficient to be able to export the relevant records from QLog via a filter. Exporting without this information does not make sense, because you have to submit the records in a verifiable way.

In my view, interoperability is not necessary here either, since the data sets are only used for a specific purpose. It is also not necessary to export the complete data set.

To be honest, I does not collect QSOs with specific "member" of the club that's why my thoughts can be quite naive. At the moment I have no idea how exactly it should behave.

I can well understand that.

The functionality of the member lists is included in many logbook programs. I suspect that this is either the author himself has built, or this is based on the wishes of users.

In this respect there seems to have been a basic need in the past.

It would be necessary to determine this need independently and then decide on it. This could be done, for example, by asking users of the programs directly, or via forum inquiries. From my point of view, you should take the time to do that. There is no hurry to implement it.

I will post in the CQRLog forum once a corresponding question. Let's see what answers come.

Another argument for putting the discussion about QLog on a broader basis.

[foldynl]

Release 0.21 implements this issue