+ AA6YQ comments below

On Wed, Aug 19, 2020 at 03:04 PM, Grover Cleveland wrote:

Following the above the Errorlog.txt is empty

+ If that's the case, your PC or Windows or both are not working correctly. With "log debugging enabled" when starting up, DXKeeper always adds entries to its errorlog.txt file.

     73,

         Dave, AA6YQ

+ AA6YQ comments below

On Wed, Aug 19, 2020 at 02:48 PM, iain macdonnell - N6ML wrote:

When, exactly, does a QSO start? This may seem like a stupid question
to those who have not tried meteor scatter. I may double-click on your
CQ to start calling you at 11:00. You may hear me calling at 11:20,
and start sending a signal report to me. I may not receive your signal
report until 11:40. When did the QSO start? 11:00? 11:20? 11:40? As
far as WSJT-X is concerned (IIRC), it starts for me when I
double-click on your CQ. (11:00), but for you, it doesn't start until
you receive my call at 11:20. I have no way of knowing when you
started answering my call, so do I assume that the QSO starts at 11:40
when I first received a report from you?

It seems the error rate might be lower (but still not zero) if LoTW
used the QSO end time instead of the start. A possible way to
accomplish this would be to make WSJT-X (and variants) use the time at
which the QSOs is logged as both the start and end time, but this
would have to be applied unanimously.

+ Since MSK144 QSOs are made with WSJT-X, I would think that user community - perhaps with orchestration by the WSJX-X team - would articulate (and possibly automate) a policy that reliably produces LoTW confirmations.

+ I'd be very surprised if the ARRL could be convinced to switch LoTW from considering "start times" to considering "end times".

      73,

               Dave, AA6YQ

 

Following the above the Errorlog.txt is empty

On Wed, Aug 19, 2020 at 2:12 PM Dave AA6YQ <aa6yq@...> wrote:

+ AA6YQ comments below

On Wed, Aug 19, 2020 at 01:44 PM, Bill Pence wrote:

So, I asked if he changed his qso start time to be within 30 mins of partners end time.

The logic was this would get an lotw match...

+ I recommend against putting incorrect information in your log. Contact your QSO partner, point out the error, and ask them to resubmit the QSO with the correct start time.

When, exactly, does a QSO start? This may seem like a stupid question
to those who have not tried meteor scatter. I may double-click on your
CQ to start calling you at 11:00. You may hear me calling at 11:20,
and start sending a signal report to me. I may not receive your signal
report until 11:40. When did the QSO start? 11:00? 11:20? 11:40? As
far as WSJT-X is concerned (IIRC), it starts for me when I
double-click on your CQ. (11:00), but for you, it doesn't start until
you receive my call at 11:20. I have no way of knowing when you
started answering my call, so do I assume that the QSO starts at 11:40
when I first received a report from you?

It seems the error rate might be lower (but still not zero) if LoTW
used the QSO end time instead of the start. A possible way to
accomplish this would be to make WSJT-X (and variants) use the time at
which the QSOs is logged as both the start and end time, but this
would have to be applied unanimously.

73,

~iain / N6ML

+ AA6YQ comments below

On Wed, Aug 19, 2020 at 01:44 PM, Bill Pence wrote:

So, I asked if he changed his qso start time to be within 30 mins of partners end time.

The logic was this would get an lotw match...

+ I recommend against putting incorrect information in your log. Contact your QSO partner, point out the error, and ask them to resubmit the QSO with the correct start time.

            73,

                 Dave, AA6YQ

+ AA6YQ comments below

On Wed, Aug 19, 2020 at 01:14 PM, Sidney Shusterman wrote:

Thanks for this information. The QSO in question was 42 minutes from start to finish.

+ That would explain the lack of a confirmation. I suggest that you contact your QSO partner and ask him or her to resubmit the QSO with the correct start time; that will result in a confirmation.

        73,

              Dave, AA6YQ

Sorry. Wrong person. In the original message, it was noted:
Qso was over 20 minutes long.
Qso partner logged wso end time.

Result us wso partner's wso time and poster wso time was greater than 30 minutes [42 minutes]
So lotw does not match.

So, I asked if he changed his qso start time to be within 30 mins of partners end time.

The logic was this would get an lotw match...

On Wed, Aug 19, 2020 at 3:26 PM Bill Pence <pence.bill@...> wrote:

Did you solve the mismatch by changing your qso start time in your log to be within 30 minutes of qso partner end time and resubmit to lotw?

I too find msk qso's can take a VERY long time.

I'm sure that's true but why would that affect the two stations' QSO
start times being greater than 30 minutes apart?




--
Peter Laws | N5UWY | plaws plaws net | Travel by Train!

Did you solve the mismatch by changing your qso start time in your log to be within 30 minutes of qso partner end time and resubmit to lotw?

I too find msk qso's can take a VERY long time. 

Thanks for this information. The QSO in question was 42 minutes from start to finish.

+ AA6YQ comments below

On Wed, Aug 19, 2020 at 01:01 PM, Grover Cleveland wrote:

No. I deleted the old and put the new one in place.

C:\Program Files (x86)\DXKeeper\Databases\DefaultBands.txt

+ Please do the following:

1. on the Configuration window's General tab, check the "log debugging info" box

2. terminate DXKeeper

3. start DXKeeper

4. wait 1 minute

5. on the Configuration window's General tab, uncheck the "log debugging info" box

6. attach the errorlog.txt file from your DXKeeper folder to an email message, and send the message to me via

aa6yq (at) ambersoft.com

      73,

             Dave, AA6YQ

No. I deleted the old and put the new one in place.

C:\Program Files (x86)\DXKeeper\Databases\DefaultBands.txt

This is in the txt file:

2190M, 0.1357,0.1378
630m, 0.472, 0.479
560M, 0.501, 0.504
160M, 1.800, 2.000
80M, 3.500,4.000
60M, 5.06,5.45
40M, 7.000,7.350
30M, 10.100, 10.150
20M, 14.000, 14.350
17M, 18.068, 18.168
15M, 21.000, 21.450
12M, 24.890, 24.990
10M, 28.000, 29.900
6M, 50.000, 54.000
4M, 70.0, 71.0
2M, 144.000, 148.000
1.25M,222.0,225.0
70CM, 420.0, 450.0
33CM, 902.0, 928.0
23CM, 1240, 1300
13CM,2300,2450
9CM, 3300, 3500
6CM, 5650, 5925
3CM, 10000, 10500
1.25CM,24000,24250
6MM, 47000, 47200
4MM, 75500, 81000
2.5MM, 119980,120020
2MM, 142000, 149000

+ AA6YQ comments below

Recently I worked a station on MSK144. The QSO took more than 20 minutes to complete. When I uploaded from DX Lab to LOTW the start time was the time used by LOTW. When I did not receive a confirmation within a reasonable time I looked into the situation and found the END time was what my QSO partner had used.

+ LoTW allows for up to 30 minutes of difference between the "start time" you submit and the "start time" your QSO" partner submits; a ~20 minute discrepancy should not have preventing confirmation.

<https://lotw.arrl.org/lotw-help/key-concepts#confirmation>

Since it is not uncommon to have an MSK144 QSO take longer than a few minutes is there a way to direct LOTW to use the end time

+ No.

or set up DX Lab to use the end time?

+ No. For reliable LoTW confirmations, all QSO participants should submit the QSO's "start time". Providing an option to submit the QSO's "end time" would reduce  confirmations.

    73,

         Dave, AA6YQ

+ AA6YQ comments below

My guess is that the sensitivity of some mouse scroll wheels is such that barely touching it causes the frequency to shift. 

+ A mouse that does that is defective, and should be replaced.

I use the scroll feature constantly and have the mouse set so as not to scroll when hovering over an inactive window.  So probably happens if I haven't minimized the Commander window or haven't activated another window.

Some software such as HDSRD provides the feature so apparently it is considered useful for some of us.

Show stopper, not really -- but would be a nice feature.

+ Yours is the first request for this functionality in the ~20 years since Commander became publicly available.

+ Inevitably, users would inadvertently activate the requested lock, adding another variable to the "Commander stopped controlling my radio" equation.

+ If the defective hardware was unique or expensive, I would consider providing a work-around, but adding potentially troublesome functionality to compensate for a defect in hardware that is  inexpensive and widely available would be inappropriate.

        73,

              Dave, AA6YQ

 

 

 

Recently I worked a station on MSK144. The QSO took more than 20 minutes to complete. When I uploaded from DX Lab to LOTW the start time was the time used by LOTW. When I did not receive a confirmation within a reasonable time I looked into the situation and found the END time was what my QSO partner had used. Since it is not uncommon to have an MSK144 QSO take longer than a few minutes is there a way to direct LOTW to use the end time or set up DX Lab to use the end time?

Thanks,

Sid K3SX

+ AA6YQ comments below

Copied the DefaultBands from the web and pasted it into a new text file "DefaultBands.text" then placed that into the DXKeeper/Database -
C:\Program Files (x86)\DXKeeper\Databases
DxKeeper still shows the old numbers (incorrect) after a reboot

+ My instructions were to download the file DefaultBands.txt, replacing the existing file in DXKeeper's Databases folder with that name.

+ If I correctly understand your report above, you created a new file named DefaultBands.text, leaving the corrupted DefaultBands.txt in place.

+ Delete DefaultBands.txt, then rename DefaultBands.text to DefaultBands.txt, and then restart DXKeeper.

       73,

             Dave, AA6YQ

 

 

 

Dave,

Copied the DefaultBands from the web and pasted it into a new text file "DefaultBands.text" then placed that into the DXKeeper/Database -
C:\Program Files (x86)\DXKeeper\Databases
DxKeeper still shows the old numbers (incorrect) after a reboot.

Grover

The logic has nothing to do with licensing rules. It comes about because the ten US call areas are used as geographic multipliers in their contests. If they did not have such a rule in effect, someone could get multiplier credit for all ten US call areas by working stations all located in the same small geographical area.

73,
Rich VE3KI