Topics

Cabrillo file for the ARRL RTTY contest

Bernd - KB7AK
 

This is for FT8 part of the contest. I used my standard setup (WSJT-X, JTAlerts, DXKeeper) for this contest and QSOs were written to a new database to keep the data clean. When I generate the Cabrillo file, everything looks accurate, except the State/Province information is missing for both my station and the stations I worked. I am sure I overlooked something. The proper exchange information is shown for each record in DXK in the Contest section in the txinfor and rxinfo fields. I am sure I overlooked something else, what is it?

Dave AA6YQ
 

+ AA6YQ comments below

This is for FT8 part of the contest. I used my standard setup (WSJT-X, JTAlerts, DXKeeper) for this contest and QSOs were written to a new database to keep the data clean. When I generate the Cabrillo file, everything looks accurate, except the State/Province information is missing for both my station and the stations I worked. I am sure I overlooked something. The proper exchange information is shown for each record in DXK in the Contest section in the txinfor and rxinfo fields. I am sure I overlooked something else, what is it?

+ Did you log a few test QSOs before the contest and generate a Cabrillo file from them to be sure that you were recording the exchange correctly, as is strongly recommended in the 3rd paragraph of

<https://www.dxlabsuite.com/dxkeeper/Help/Contesting.htm>

?

+ Did you follow the instructions in "Note 16" in the above reference documentation for correctly recording the contest exchange?

73,

Dave, AA6YQ

Bernd - KB7AK
 

No to both to be honest. It was a last minute decision to stick with what I use (and it was a good decision). I understand that I should have entered my state abbreviation into the TX Serial# number field and uncheck Increment TX Serial#. But, what does this mean capture your QSO partner's state abbreviation, province abbreviation or serial number in each QSO's RX# item?" when the data comes automatically from JTAlerts. Do I need to touch each QSO after it has been logged and modify the record by entering the other side's State code?

neil_zampella
 

Were you in TAB1 on the main WSJT-X window?    There is an issue where the exchange is not captured in WSJT-X if you're not on TAB 1.

Neil, KN3ILZ

On 1/9/2019 2:07 PM, Bernd - KB7AK wrote:
No to both to be honest. It was a last minute decision to stick with what I use (and it was a good decision). I understand that I should have entered my state abbreviation into the TX Serial# number field and uncheck Increment TX Serial#. But, what does this mean capture your QSO partner's state abbreviation, province abbreviation or serial number in each QSO's RX# item?" when the data comes automatically from JTAlerts. Do I need to touch each QSO after it has been logged and modify the record by entering the other side's State code?



AVG logo

This email has been checked for viruses by AVG antivirus software.
www.avg.com


Bernd - KB7AK
 

Hi Neil,

I was on Tab 1, and the exchange is captured automatically in TX Info and RX Info fields in the Contest section in the main QSO Tab.

Dave AA6YQ
 

+ AA6YQ comments below

No to both to be honest. It was a last minute decision to stick with what I use (and it was a good decision). I understand that I should have entered my state abbreviation into the TX Serial# number field and uncheck Increment TX Serial#. But, what does this mean capture your QSO partner's state abbreviation, province abbreviation or serial number in each QSO's RX# <https://www.dxlabsuite.com/dxkeeper/Help/Items.htm#rx%20#> item?" when the data comes automatically from JTAlerts.

+ It means that if JTAlert is going to log contest QSOs in a manner that will enable DXKeeper to subsequently generate a Cabrillo file, JTAlert must log those contest QSOs in the manner described in

<https://www.dxlabsuite.com/dxlabwiki/Multi>

Do I need to touch each QSO after it has been logged and modify the record by entering the other side's State code?

+ Yes. For DXKeeper to be able to generate a Cabrillo file from your logged contest QSOs, those QSO must conform to the requirements set forth in

<https://www.dxlabsuite.com/dxlabwiki/Multi>

73,

Dave, AA6YQ

Dave AA6YQ
 

Both of the URLs in the message below should reference

<https://www.dxlabsuite.com/dxkeeper/Help/Contesting.htm>

73,

Dave, AA6YQ


+ AA6YQ comments below

No to both to be honest. It was a last minute decision to stick with what I use (and it was a good decision). I understand that I should have entered my state abbreviation into the TX Serial# number field and uncheck Increment TX Serial#. But, what does this mean capture your QSO partner's state abbreviation, province abbreviation or serial number in each QSO's RX# <https://www.dxlabsuite.com/dxkeeper/Help/Items.htm#rx%20#> item?" when the data comes automatically from JTAlerts.

+ It means that if JTAlert is going to log contest QSOs in a manner that will enable DXKeeper to subsequently generate a Cabrillo file, JTAlert must log those contest QSOs in the manner described in

<https://www.dxlabsuite.com/dxlabwiki/Multi>

Do I need to touch each QSO after it has been logged and modify the record by entering the other side's State code?

+ Yes. For DXKeeper to be able to generate a Cabrillo file from your logged contest QSOs, those QSO must conform to the requirements set forth in

<https://www.dxlabsuite.com/dxlabwiki/Multi>

HamApps Support (VK3AMA)
 

On 10/01/2019 8:25 am, Dave AA6YQ wrote:
It means that if JTAlert is going to log contest QSOs in a manner that will enable DXKeeper to subsequently generate a Cabrillo file, JTAlert must log those contest QSOs in the manner described in
JTAlert is not a Contest Logger. It simply acts as logging bridge between WSJT-X and DXKeeper. There are no attempts to validate the Contest exchange based on different Contest rules or extract data from the Contest exchange. There is no attempt to include missing data within the exchange. JTAlert is a bridge, it simply passes through the WSJT-X Contest exchange.

If DXKeeper is not utilising a valid Contest exchange for the Contest enabled within DXKeeper, eg. WSJT-X and DXKeeper are both set for RTTY Roundup, and a valid Roundup Exchange is passed to DXKeeper, unchanged by JTAlert, there is not point in logging the exchange, IMO.

The next release of JTAlert will no longer automatically log Contest exchanges (valid or invalid) to DXKeeper (whether in Contest mode or not). The JTAlert user will need to enable an option to permit logging of these unused (by DXKeeper) Contest exchanges.

de Laurie VK3AMA

Dave AA6YQ
 

+ AA6YQ comments below


It means that if JTAlert is going to log contest QSOs in a manner that will enable DXKeeper to subsequently generate a
Cabrillo file, JTAlert must log those contest QSOs in the manner described in

JTAlert is not a Contest Logger. It simply acts as logging bridge between WSJT-X and DXKeeper. There are no attempts to validate the
Contest exchange based on different Contest rules or extract data from the Contest exchange. There is no attempt to include missing
data within the exchange. JTAlert is a bridge, it simply passes through the WSJT-X Contest exchange.

If DXKeeper is not utilising a valid Contest exchange for the Contest enabled within DXKeeper, eg. WSJT-X and DXKeeper are both set
for RTTY Roundup, and a valid Roundup Exchange is passed to DXKeeper, unchanged by JTAlert, there is not point in logging the
exchange, IMO.

+ DXKeeper expects the contest exchange to be recorded in the RX# and TX# items. In the case of "RTTY Roundup", that means the QSO
partner's "US State" abbreviation, "Canadian Province" abbreviation, or serial number must be recorded in the QSO's RX# item; this
approach enables RTTY ops to employ the same gestures to capture their QSO partner's exchange independent of their QSO partner's
location. See Note 16 in

<https://www.dxlabsuite.com/dxkeeper/Help/Contesting.htm>

73,

Dave, AA6YQ

HamApps Support (VK3AMA)
 

On 11/01/2019 9:42 am, Dave AA6YQ wrote:
DXKeeper expects the contest exchange to be recorded in the RX# and TX# items.
OK, so the SRX_STRING & STX_STRING are not utilised by DXKeeper even though they contain the RX# and TX# data need by the Contest (assuming the user has recorded correct format data). Why are they included in the log at all? Since here is no point in sending the SRX_STRING & STX_STRING in the adif fields of the DXKeeper log QSO command as they are ignored, this has been turned off starting with the next build of JTAlert.

Sorry that including the data has been inconvenient and troublesome for JTAlert/DXKeeper
users.

de Laurie VK3AMA

Dave AA6YQ
 

+ AA6YQ comments below

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of HamApps Support (VK3AMA)
Sent: Thursday, January 10, 2019 6:14 PM
To: DXLab@groups.io
Subject: Re: [DXLab] Cabrillo file for the ARRL RTTY contest

On 11/01/2019 9:42 am, Dave AA6YQ wrote:


DXKeeper expects the contest exchange to be recorded in the RX# and TX# items.

OK, so the SRX_STRING & STX_STRING are not utilised by DXKeeper even though they contain the RX# and TX# data need by the Contest
(assuming the user has recorded correct format data).

+ The RX# and TX# items are used to convey the exchange.

Why are they included in the log at all?

+ Because they are defined in ADIF; DXKeeper has never provided automation that references their contents. Cabrillo files are
generated from RX# to make it easy for users to capture exchange information in CW or digital-mode contests.

Since here is no point in sending the SRX_STRING & STX_STRING in the adif fields of the DXKeeper log QSO command as they are
ignored, this has been turned off starting with the next build of JTAlert.

+ What has JTAlert been logging in the SRX_STRING & STX_STRING items?

73,

Dave, AA6YQ

g4wjs
 

On 10/01/2019 22:16, HamApps Support (VK3AMA) wrote:
On 10/01/2019 8:25 am, Dave AA6YQ wrote:
It means that if JTAlert is going to log contest QSOs in a manner that will enable DXKeeper to subsequently generate a Cabrillo file, JTAlert must log those contest QSOs in the manner described in
JTAlert is not a Contest Logger. It simply acts as logging bridge between WSJT-X and DXKeeper. There are no attempts to validate the Contest exchange based on different Contest rules or extract data from the Contest exchange. There is no attempt to include missing data within the exchange. JTAlert is a bridge, it simply passes through the WSJT-X Contest exchange.

If DXKeeper is not utilising a valid Contest exchange for the Contest enabled within DXKeeper, eg. WSJT-X and DXKeeper are both set for RTTY Roundup, and a valid Roundup Exchange is passed to DXKeeper, unchanged by JTAlert, there is not point in logging the exchange, IMO.

The next release of JTAlert will no longer automatically log Contest exchanges (valid or invalid) to DXKeeper (whether in Contest mode or not). The JTAlert user will need to enable an option to permit logging of these unused (by DXKeeper) Contest exchanges.

de Laurie VK3AMA

Hi Laurie and Dave,

WSJT-X has support for a four contests using FT8 and MSK144 modes, these have been made possible due to the new 77-bit payload format introduced, in part, for that very facility. WSJT-X tries to be agnostic about logging applications and provide generic data sources that should be acceptable to other applications (ADIF for example) or by providing data that can be used by other applications where ADIF is not suitable (the WSJT-X UDP message protocol).

For contests the logging applications that might interoperate with WSJT-X extend to those that have some level of contest support, but the standards for recording contest exchanges are both very specific and not well standardized.

WSJT-X addresses this in three ways:

  1) it has basic facilities to directly generate contest entry files in Cabrillo format which as near as a standard as we have. Note that Cabrillo is not a one size fits all contest logging format, rather it is a way of recording information according to a template specification which can be different for each contest. So there are different Cabrillo generation routines for each contest type supported by WSJT-X. Cabrillo entry files are not usually used to import log records into another logging application, their intent is to enter a specific contest with just the station and QSO details required to do so.

2) it provides a feed of ADIF records mirroring QSO logging events, this ADIF is exactly what is logged in WSJT-X's own ADIF log file, it is also available via a UDP message enabled specifically for the N1MM Logger+ contest logger (it has also been unilaterally adopted by the Writelog DX and contest logging application), and there is an ADIF logging message sent using the WSJT-X UDP message protocol which also carries the same ADIF record. The field content of this ADIF record, with respect to contest logging, was defined by it being acceptable to N1MM Logger+. This is external application specific but given the lack of a better standard format it seemed the best approach as N1MM is probably the most commonly used contest logging application.

3) the WSJT-X UDP protocol includes contest exchange information, in its logged QSO message, that external applications may do with this as they wish. Two string fields are added which are the contents of the "Exhange Sent" and "Exchange Received" log entry fields in WSJT-X. They contain the whole contest exchange including the report, e.g. for the ARRL RTTY RU format they could be "569 PA" and "539 0010" for a station in PA working a DX station.

I understand Laurie's reluctance to extend JTAlert to support the contest modes of WSJT-X with every logging application JTAlert acts as a bridge for, particularly when each logging application may have differing levels of contest support and different requirements on how they receive the extra QSO data. I know Laurie has added support for N1MM Logger+ and the relay of the ADIF record in (2) above is really all that is needed in that case. For the N3FJP contest logger, again there is some direct support implemented with cooperation from Scott, N3NJP. Both of these have been implemented, as far as I know, because significant numbers of users of those contest applications have requested support. DXKeeper is far from being a dedicated contest logging application and I would surprised if any serious contesters would choose it as the prime logging application for a contest entry, nevertheless supporting it may not be that difficult because there should be very little scope creep given that the four contest modes available in WSJT-X are very unlikely to be extended or changed as they are deeply embedded into the underlying digital protocols (FT8 and MSK144).

It is also worth noting that there is some potential for a new contest focused mode in WSJT-X, this would be very different from FT8 or MSK144 as it would be designed specifically for contest operation and to achieve high QSO rates with some of the message decoding accuracy and sensitivity of modes like MSK144 and FT8. If this does prove feasible and it can be designed to work better than, say, RTTY for contest operation in all attributes then it may make it to public release, perhaps in the form of a plug-in codec that other applications like N1MM Logger+ can incorporate as they do now with MMTTY for RTTY.

73
Bill
G4WJS.


--
73

Bill

G4WJS.

Dave AA6YQ
 

Bill:

The next version of SpotCollector can directly interoperate with WSJTX via UDP. When it receives a "QSO logged" message, this new version of SpotCollector directs DXKeeper to log the QSO. In reviewing the "WSJT-X 2.0 User Guide", I saw the new contest messages described in section 7.4, but the description of Logging in section 11 is limited to " Additional features are provided for Contest and Fox logging. (more to come, here …​)".

Please let me know when the details of logging contest information from WSJTX have been documented. Until then, DXLab's ability to interoperate with WSJTX will be advertised as "not for use if Cabrillo generation is required". While DXKeeper is explicitly not focused on contesting (I recommend N1MM to anyone who asks), it does support exchange management and Cabrillo generation so that DXers participating in a contest while searching for "new ones" can issue accurate exchanges and fulfill their obligations by submitting Cabrillo logs. Thus I will work to make the process of generating Cabrillo from QSOs logged in WSJTX as smooth as is practical, given the Cabrillo deficiencies that you cite below.

73,

Dave, AA6YQ



WSJT-X has support for a four contests using FT8 and MSK144 modes, these have been made possible due to the new 77-bit payload format introduced, in part, for that very facility. WSJT-X tries to be agnostic about logging applications and provide generic data sources that should be acceptable to other applications (ADIF for example) or by providing data that can be used by other applications where ADIF is not suitable (the WSJT-X UDP message protocol).

For contests the logging applications that might interoperate with WSJT-X extend to those that have some level of contest support, but the standards for recording contest exchanges are both very specific and not well standardized.


WSJT-X addresses this in three ways:

1) it has basic facilities to directly generate contest entry files in Cabrillo format which as near as a standard as we have. Note that Cabrillo is not a one size fits all contest logging format, rather it is a way of recording information according to a template specification which can be different for each contest. So there are different Cabrillo generation routines for each contest type supported by WSJT-X. Cabrillo entry files are not usually used to import log records into another logging application, their intent is to enter a specific contest with just the station and QSO details required to do so.


2) it provides a feed of ADIF records mirroring QSO logging events, this ADIF is exactly what is logged in WSJT-X's own ADIF log file, it is also available via a UDP message enabled specifically for the N1MM Logger+ contest logger (it has also been unilaterally adopted by the Writelog DX and contest logging application), and there is an ADIF logging message sent using the WSJT-X UDP message protocol which also carries the same ADIF record. The field content of this ADIF record, with respect to contest logging, was defined by it being acceptable to N1MM Logger+. This is external application specific but given the lack of a better standard format it seemed the best approach as N1MM is probably the most commonly used contest logging application.

3) the WSJT-X UDP protocol includes contest exchange information, in its logged QSO message, that external applications may do with this as they wish. Two string fields are added which are the contents of the "Exhange Sent" and "Exchange Received" log entry fields in WSJT-X. They contain the whole contest exchange including the report, e.g. for the ARRL RTTY RU format they could be "569 PA" and "539 0010" for a station in PA working a DX station.

I understand Laurie's reluctance to extend JTAlert to support the contest modes of WSJT-X with every logging application JTAlert acts as a bridge for, particularly when each logging application may have differing levels of contest support and different requirements on how they receive the extra QSO data. I know Laurie has added support for N1MM Logger+ and the relay of the ADIF record in (2) above is really all that is needed in that case. For the N3FJP contest logger, again there is some direct support implemented with cooperation from Scott, N3NJP. Both of these have been implemented, as far as I know, because significant numbers of users of those contest applications have requested support. DXKeeper is far from being a dedicated contest logging application and I would surprised if any serious contesters would choose it as the prime logging application for a contest entry, nevertheless supporting it may not be that difficult because there should be very little scope creep given that the four contest modes available in WSJT-X are very unlikely to be extended or changed as they are deeply embedded into the underlying digital protocols (FT8 and MSK144).

It is also worth noting that there is some potential for a new contest focused mode in WSJT-X, this would be very different from FT8 or MSK144 as it would be designed specifically for contest operation and to achieve high QSO rates with some of the message decoding accuracy and sensitivity of modes like MSK144 and FT8. If this does prove feasible and it can be designed to work better than, say, RTTY for contest operation in all attributes then it may make it to public release, perhaps in the form of a plug-in codec that other applications like N1MM Logger+ can incorporate as they do now with MMTTY for RTTY.


73
Bill
G4WJS.

neil_zampella
 

FWIW ... during the RTTY contest the required exchanges WERE correctly logged by DXKeeper using JT-Alert.

I'm trying to figure out who is saying it did not, as I had no problems at all.

Neil, KN3ILZ

On 1/10/2019 6:13 PM, HamApps Support (VK3AMA) wrote:
On 11/01/2019 9:42 am, Dave AA6YQ wrote:
DXKeeper expects the contest exchange to be recorded in the RX# and TX# items.
OK, so the SRX_STRING & STX_STRING are not utilised by DXKeeper even though they contain the RX# and TX# data need by the Contest (assuming the user has recorded correct format data). Why are they included in the log at all? Since here is no point in sending the SRX_STRING & STX_STRING in the adif fields of the DXKeeper log QSO command as they are ignored, this has been turned off starting with the next build of JTAlert.

Sorry that including the data has been inconvenient and troublesome for JTAlert/DXKeeper
users.

de Laurie VK3AMA


Virus-free. www.avg.com

Dave AA6YQ
 

+ AA6YQ comments below

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of neil_zampella
Sent: Friday, January 11, 2019 12:18 AM
To: DXLab@groups.io
Subject: Re: [DXLab] Cabrillo file for the ARRL RTTY contest

FWIW ... during the RTTY contest the required exchanges WERE correctly logged by DXKeeper using JT-Alert.

I'm trying to figure out who is saying it did not, as I had no problems at all.

+ Neil, the screenshot you sent me via email shows a receive exchange containing a signal report and a state/province abbreviation
in the logged QSO's "RX Info" item.

+ In order to generate a Cabrillo log, DXKeeper requires the signal report to be recorded in the QSO's "RST rcvd" item and the
state/province abbreviation in the QSO's "RX#" item. You will not be able to generate Cabrillo from your logged QSO.

73,

Dave, AA6YQ

Bernd - KB7AK
 

Hi Laurie,

Could you change the destination fields and send the State/Province portion to those fields, then everything would be perfect.