On 28/06/2020 00:53, Dave AA6YQ wrote:

+ AA6YQ comments below

The Logged ADIF message only has the de station's class in the RST_SENT field, I'm not even sure that is right.

+ Yes, I see that now that you point it out. In my opinion, that's not appropriate.

Do you know what ADIF field is the right on to include the DE station's ARRL/RAC section, or indeed their FD class? I think that if a FD log is uploaded to the ARRL then the DE stations class and section are only in the header. The "header" to which you refer appears in a Cabrillo log, not an ADIF file.

+ The ARRL does not process submitted Field Day logs; it just wants evidence that the user made an effort to prevent duplicate QSOs.

The UDP message QSO Logged does include the "Exchange sent" and "Exchange received" fields which contain the same as those fields on the Log QSO dialog.

+ Here's what was logged to DXKeeper using WSJT-X 2.2.2:

RST_SENT: my class

RST_RCVD: my QSO partner's class

CONTEST_ID: ARRL-FIELD-DAY

ARRL-SECT: my QSO partner's ARRL section

STX: <blank> (DXKeeper labels this item "tx #")

SRX: <blank> (DXKeeper labels this item "rx #")

STX_STRING: my QSO partner's class and ARRL section (DXKeeper labels this item "tx info")

SRX_STRING: <blank> (DXKeeper labels this item "rx info")


+ My advice (See #8 below)

1. don't misuse RST_SENT; use it to record the SNR sent

2. don't misuse of RST_RCVD; use it to record the SNR rcvd

3. continue to record the transmitted exchange (class and section) in STX_STRING

4. record the received exchange (class and section) in SRX_STRING

5. continue to record ARRL-FIELD-DAY in CONTEST_ID

6. continue to record the received ARRL Section in ARRL_SECT

7. continue to leave STX and SRX blank (since they are of integer data type; they can be used to record serial numbers in contests that employ them)

8. Confer with Tom N1MM before making changes.

73,

Dave, AA6YQ

Hi Dave,

thanks for the useful comments and suggestions. I wonder why you do not recommend using the CLASS ADIF field for the DX station's FD class, it seems specifically for that purpose. For FD no report is received, so I assume your recommendation is to leave that ADIF field blank. Given that the ADIF specification says that specific ADIF fields override SRX_STRING and STX_STRING, it would seem unwise to populate SRX_STRING for FD when there are specific fields CLASS and ARRL_SECT that would override.



--
73

Bill

G4WJS.

I use Defender as my anti-malware. I have ensured that it consider DXKeeper, SpotCollector, CI-Vcommander as well as WSJT-X to be safe. Still i have to wait starting the next QSO because the previous has not been logged in DXKeeper.
73 de Knut LA9RY

All,
SpotCollector is an impressive too. But dont forget that you need active stations to have something to spot.
Call CQ, make contacts and have fun.
Good DX
73
OZ7BQ Hans Jørgen (Joe)

Sendt fra min iPhone

+ AA6YQ comments below

I tried this morning. Laptop turned on, starting windows and DXLab (Commander, Keeper, Collector). Call appears in the filter window when i receved response from the called station. I log on prompt from WSJT-X. Then it takes a long time and the call appears in DXKeeper. Time elapsed is so long that i might have had a response from the next station. That was what happened right now. Other times nothing is registered in DXKeeper, and i wonder what is happening. Then, after ended session I inspect the log, and the QSO is in the log more than once. 

I have in excess of 30000 QSOs in my log. Is that a challenge?

+ 30,000 QSOs is not a challenge.

+ Slow communication among applications is typically the result of interference from anti-malware applications. Do you have your anti-malware applications configured to consider DXKeeper, SpotCollector, Commander, and WSJT-X to be "safe"?

             73,

                     Dave, AA6YQ

 

    

 

 

 

DXKeeper ver. 15.6.6.
SpotCollector ver. 8.6.9.
First occurrance. Hard to say. I has happpened now and then for quite a long time. 
Yes, on my laptop I reboot my Windows several times each day.

I tried this morning. Laptop turned on, starting windows and DXLab (Commander, Keeper, Collector). Call appears in the filter window when i receved response from the called station. I log on prompt from WSJT-X. Then it takes a long time and the call appears in DXKeeper. Time elapsed is so long that i might have had a response from the next station. That was what happened right now. Other times nothing is registered in DXKeeper, and i wonder what is happening. Then, after ended session I inspect the log, and the QSO is in the log more than once. 

I have in excess of 30000 QSOs in my log. Is that a challenge?
73 de Knut LA9RY

+ AA6YQ comments below

On Sat, Jun 27, 2020 at 10:34 PM, Derek Chauran wrote:

Thanks Dave - My point about updating QSOs was that I was seeing neither mine nor the other stations section logged, but that is working now, thanks to Laurie's suggestion, so I only need to hand edit a few to add the other station's info.

 

I did have optimize for real-time entry enabled, but not run mode. After disabling that it no longer automatically creates a new log. I do see where this is desirable for being the target of a pileup.

 

I also have tried using capture mode, but even with contest mode enabled, it doesn't present me with the tx info and rx info boxes that are part of the contest section in the main window.

+ The "tx info" and "rx info" items are typically not used. As is described in

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

 

+ The "rx #" and "tx #" items are used to capture the exchanges in each logged QSO. Both of these items are accessible in the Capture window.

        73,

 

              Dave, AA6YQ

+ AA6YQ comments below

The Logged ADIF message only has the de station's class in the RST_SENT field, I'm not even sure that is right.

+ Yes, I see that now that you point it out. In my opinion, that's not appropriate.

Do you know what ADIF field is the right on to include the DE station's ARRL/RAC section, or indeed their FD class? I think that if a FD log is uploaded to the ARRL then the DE stations class and section are only in the header. The "header" to which you refer appears in a Cabrillo log, not an ADIF file.

+ The ARRL does not process submitted Field Day logs; it just wants evidence that the user made an effort to prevent duplicate QSOs.

The UDP message QSO Logged does include the "Exchange sent" and "Exchange received" fields which contain the same as those fields on the Log QSO dialog.

+ Here's what was logged to DXKeeper using WSJT-X 2.2.2:

RST_SENT: my class

RST_RCVD: my QSO partner's class

CONTEST_ID: ARRL-FIELD-DAY

ARRL-SECT: my QSO partner's ARRL section

STX: <blank> (DXKeeper labels this item "tx #")

SRX: <blank> (DXKeeper labels this item "rx #")

STX_STRING: my QSO partner's class and ARRL section (DXKeeper labels this item "tx info")

SRX_STRING: <blank> (DXKeeper labels this item "rx info")


+ My advice (See #8 below)

1. don't misuse RST_SENT; use it to record the SNR sent

2. don't misuse of RST_RCVD; use it to record the SNR rcvd

3. continue to record the transmitted exchange (class and section) in STX_STRING

4. record the received exchange (class and section) in SRX_STRING

5. continue to record ARRL-FIELD-DAY in CONTEST_ID

6. continue to record the received ARRL Section in ARRL_SECT

7. continue to leave STX and SRX blank (since they are of integer data type; they can be used to record serial numbers in contests that employ them)

8. Confer with Tom N1MM before making changes.

73,

Dave, AA6YQ

+ AA6YQ comments below

I occasionally have problems with logging from WSJT-X (FT8/FT4) into DXKeeper.
Usually the call I just worked remains in the filter (lower line in DXKeeper Log window.) When e new call comes up in WSJT-X, it replaces the old call in the filter. That is normal. But now it refuses to do so. The old call still is in the filter.
Trying to erase the old call does not help.
When I log in WSJT-X, the QSO does not appear in DXKeeper.
Then I manually log the QSO using Capture window.
This results in double or triple entries in DXKeeper.
I feel that I have lost control with this logging procedure.
I have not made any changes in my seup.
Commander, DXKeeper and Sport Collector are all updated an latest version.
Windows 10 latest update.

+ What version number is shown in the title bar of DXKeeper's Main window?

+ What version number is shown in the title bar of SpotCollector's Main window?

+ You report a change in behavior in your description above. When did this change first occur? What changes to you hardware or software had you made around that time?

+ Have you rebooted Windows since this change in behavior occurred?

73,

Dave, AA6YQ

Regarding the manual logging, if I log in DXKeeper, I get the contest mode issue, where as soon as I hit tab from the call sign it saves the log and starts a new log.

+ That's correct behavior for logging from the Main window's "Log QSOs" tab with the "Run-mode" option enabled on the Configuration window's General tab:

<https://www.dxlabsuite.com/dxkeeper/Help/Configuration.htm#Run-mode%20checkbox>;

+ You can disable "Run-mode" after enabling "Contest mode".

+ You might also consider logging from DXKeeper's Capture window:

Even more problematic, is that it defaults to the last info logged , so if I switch from FT-8 20m to FM 2m, I enter a call sign, hit tab, it then auto populates with the FT-80 20m info, saves the log, and starts a new log

+ Sounds like you have "Optimize for realtime QSO entry" disabled on the Configuration window's General tab:

<https://www.dxlabsuite.com/dxkeeper/Help/Configuration.htm#Automatically%20set%20QSO%20date%20&;%20time>


I do have callbook lookup enabled, and it does the callbook lookup. Does that trigger the save?

+ No, enabling "Run-mode" is what causes DXKeeper to record the QSO and automatically create an empty new QSO. It's quite handy when you're on the pointy end of a pileup.

+ You might consider using DXKeeper's Capture window to record new QSOs:

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

<https://www.dxlabsuite.com/dxlabwiki/Logging>;

<https://www.dxlabsuite.com/dxlabwiki/QSOCapture>;

73,

Dave, AA6YQ

On 28/06/2020 00:04, Dave AA6YQ wrote:

+ AA6YQ comments below

do you use the QSO Logged UDP message or the Logged ADIF UDP message to capture logged QSOs?

+ "Logged ADIF" (MessageType 12)

Do you have Tab 1 messages enabled in WSJT-X?

+ I am using the TX messages on Tab 1, which do include my class and section.

+ If there's a "Tab 1 messages enabled" checkbox, I'm not aware of its location in the application, and see no reference to it in the "2.2 User's Guide".

73,

Dave, AA6YQ

Hi Dave,

there's no enable other than having the Tab 1 messages selected.

The Logged ADIF message only has the de station's class in the RST_SENT field, I'm not even sure that is right. Do you know what ADIF field is the right on to include the DE station's ARRL/RAC section, or indeed their FD class? I think that if a FD log is uploaded to the ARRL then the DE stations class and section are only in the header.

The UDP message QSO Logged does include the "Exchange sent" and "Exchange received" fields which contain the same as those fields on the Log QSO dialog.

73
Bill
G4WJS.



--
73

Bill

G4WJS.

+ AA6YQ comments below

do you use the QSO Logged UDP message or the Logged ADIF UDP message to capture logged QSOs?

+ "Logged ADIF" (MessageType 12)

Do you have Tab 1 messages enabled in WSJT-X?

+ I am using the TX messages on Tab 1, which do include my class and section.

+ If there's a "Tab 1 messages enabled" checkbox, I'm not aware of its location in the application, and see no reference to it in the "2.2 User's Guide".

73,

Dave, AA6YQ

Hi Dave - Laurie's suggestion did the trick with WSJT-X and JTAlert. 

Regarding the manual logging, if I log in DXKeeper, I get the contest mode issue, where as soon as I hit tab from the call sign it saves the log and starts a new log. Even more problematic, is that it defaults to the last info logged, so if I switch from FT-8 20m to FM 2m, I enter a call sign, hit tab, it then auto populates with the FT-80 20m info, saves the log, and starts a new log. I do have callbook lookup enabled, and it does the callbook lookup. Does that trigger the save?

On 27/06/2020 23:13, Dave AA6YQ wrote:

+ AA6YQ comments below

this allowed in contest modes. "Settings->Reporting->Log automatically (contesting only)". The Log QSO dialog will only pop up if there is a problem with the log entry.

+ Thanks, Bill; I did have that setting enabled, but had forgotten about it.

+ Why was my side of the exchange not logged with each QSO?

73,

Dave, AA6YQ

Hi Dave,

do you use the QSO Logged UDP message or the Logged ADIF UDP message to capture logged QSOs? Do you have Tab 1 messages enabled in WSJT-X?

73
Bill
G4WJS.



--
73

Bill

G4WJS.

+ AA6YQ comments below

this allowed in contest modes. "Settings->Reporting->Log automatically (contesting only)". The Log QSO dialog will only pop up if there is a problem with the log entry.

+ Thanks, Bill; I did have that setting enabled, but had forgotten about it.

+ Why was my side of the exchange not logged with each QSO?

73,

Dave, AA6YQ

+ AA6YQ comments below

Thanks, I have seen the info on modifying QSOs, but each QSO for FD has a different combination of class and section, so I can't really bulk edit them, I have to go 1 at a time.

+ Your class and section don't change from one QSOs to the next.

+ Laurie VK3AMA responded with an explanation of how JT-Alert should be configured.

I have also read the info on logging for FD which doesn't have a suggestion as to where to store the FD specific info (again, I like my logs to be accurate and consistent.

+ As noted in

<https://www.dxlabsuite.com/dxlabwiki/ARRLFieldDay>;

+ the ARRL doesn't actual read the log files you submit, so you can log the information however you wish.

When I enable contest mode, the second I enter the call and hit tab it auto populates everything, without the info I need for the contest (my tx entered in the contest info doesn't seem to go anywhere) saves the QSO, and starts a new log. I then have to delete the new log, unlock the QSO for editing and enter the data I was trying to capture, or remember that the workflow is different, don't hit tab. Except if i want the time logged accurately (I'm anal about my logs) I have to note that time, enter the call, enter the exchange, then go back to the call, hit tab or it won't let me enter the time, go back and delete the new log it auto creates, and then edit the old log time to the correct time.

+ To which application does the description above apply?

+ DXKeeper's support for logging contest QSOs is described here:

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

+ WinWarbler's is here:

<https://www.dxlabsuite.com/winwarbler/Help/ContestSettings.htm>;

+ I just posted my experience using WSJT-X to log Field Day QSOS:

<https://groups.io/g/DXLab/message/194716>;


As far as I can tell, WSJT-X and JTAlert are sending the info 3 times, and 1 of those 3 contains the full info, and that doesn't get logged anywhere:

+ Try configuring JT-Alert as Laurie VK3AMA suggested.

73,

Dave, AA6YQ

On 27/06/2020 23:01, Dave AA6YQ wrote:

The surprise: WSJT-X automatically logged each QSO without my having to click OK in its Log window.

73,

Dave, AA6YQ

Hi Dave,

this allowed in contest modes. "Settings->Reporting->Log automatically (contesting only)". The Log QSO dialog will only pop up if there is a problem with the log entry.



--
73

Bill

G4WJS.

Thanks Laurie! That did the trick!

After configuring WSJT-X as described in step 3 of

<https://www.dxlabsuite.com/dxlabwiki/ARRLFieldDay>;

I just made a few FT8 QSOs. These QSOs were logged with a Contest ID items set to

ARRL-FIELD-DAY

and their "rx info" items set to my QSO partner's exchange (e.g. 1D WCF). Though my exchange is specified in the "FD Exch" section
of the WSJT-X "Special operating activity" panel, it was not logged with each QSO.; after Field Day, this could quickly be rectified
"en masse" using the "Advanced Sorts, Filters, and Modifiers" window's "Modify QSOs" tab.

The surprise: WSJT-X automatically logged each QSO without my having to click OK in its Log window.

73,

Dave, AA6YQ

I occasionally have problems with logging from WSJT-X (FT8/FT4) into DXKeeper.
Usually the call I just worked remains in the filter (lower line in DXKeeper Log window.) When e new call comes up in WSJT-X, it replaces the old call in the filter. That is normal. But now it refuses to do so. The old call still is in the filter.
Trying to erase the old call does not help. 
When I log in WSJT-X, the QSO does not appear in DXKeeper.
Then I manually log the QSO using Capture window.
This results in double or triple entries in DXKeeper.
I feel that I have lost control with this logging procedure.
I have not made any changes in my seup.
Commander, DXKeeper and Sport Collector are all updated an latest version.
Windows 10 latest update.
73 de Knut LA9RY