Date   

Re: DXKeeper LoTW Setup/Handling for Portable Station Callsign

Jim N7US
 

I don't get into the BARTG contests for the same reason.

Jim N7US

-----Original Message-----



It comes about because the ten US call areas are used as geographic
multipliers in their contests.
If that's the case, make all stations provide their state in the exchange. Don't make *some* stations use a call sign other than the one assigned by the regulator. It would be like CQWW saying all stations must use the primary callsign of their license holder
(trustee) effectively banning all of the special contest calls so popular in Europe.

BARTG has had their heads "where the sun don't shine" for 20+ years.
I dealt with the same issue when I moved from WV to Florida before I gave up on BARTG contests (and eventually got a 4-land callsign).
Getting a 1 x 2 callsign in the 4th call area is nearly impossible -I was not about to give up a 1 x 2 call that I had waited for years to get to just to satisfy a bunch of Brits who think their rules are more important that our regulations.

73,

... Joe, W4TV


On 2020-08-19 1:22 PM, ve3ki wrote:
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


Re: MSK144 logging and time keeping

Joe Subich, W4TV
 

LotW does not recognize "end time". There is only one time involved in
the QSO entry and by the LotW specification that is the start time.

*ANY ONE OR ANY LOGGING PROGRAM* that uses "end time" is violating the
LotW documentation. Note: this can be a significant problem with
meteor scatter (MSK144, ISCAT-A, ISCAT-B) and EME QSOs as they are
generally schedules that can last up to an hour with the stations
receiving their reports at widely spaced times.

73,

... Joe, W4TV

On 2020-08-19 5:10 PM, Dave AA6YQ wrote:
+ 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


Re: DX Keeper tx band not showing regular bands

w6de
 

Is this possibly a problem with K7TP placing his DXLab files in the protected X86 program directory instead of the recommended C:DXLab folder?

And/or what user permissions he is logged in with?

 

Dave, w6de

 

From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Dave AA6YQ
Sent: 19 August, 2020 22:11
To: DXLab@groups.io
Subject: Re: [DXLab] DX Keeper tx band not showing regular bands

 

+ 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


WinWarbler Setup

Stuart - VK6MK
 

Hi all
I am trying to set up WinWarbler on a Yaesu FTDX101MP. MMTY is working well as a stand alone and I am making RTTY contacts. Commander is working fine with both TX and RX Mode and freq all interacting with the transceiver.   In WinWarbler RTTY config I get to MMTY SETUP button works.

When I transmit RTTY in WinWarbler with macros or typed in text I transmit a solid carrier wave and the text goes into the top screen in white but is obviously not transmitting. The freq and Modes in WinWarbler also interact with the transceiver. The tune box is unticked and ticking it makes no difference.

Any assistance greatly appreciated.  I feel I am close and have tried endless combinations of ports PTT etc and just cant work it out.

Thanks 
Stuart VK6MK


Re: DXKeeper LoTW Setup/Handling for Portable Station Callsign

Joe Subich, W4TV
 

It comes about because the ten US call areas are used as geographic
multipliers in their contests.
If that's the case, make all stations provide their state in the
exchange. Don't make *some* stations use a call sign other than
the one assigned by the regulator. It would be like CQWW saying
all stations must use the primary callsign of their license holder
(trustee) effectively banning all of the special contest calls
so popular in Europe.

BARTG has had their heads "where the sun don't shine" for 20+ years.
I dealt with the same issue when I moved from WV to Florida before
I gave up on BARTG contests (and eventually got a 4-land callsign).
Getting a 1 x 2 callsign in the 4th call area is nearly impossible
-I was not about to give up a 1 x 2 call that I had waited for years
to get to just to satisfy a bunch of Brits who think their rules are
more important that our regulations.

73,

... Joe, W4TV


On 2020-08-19 1:22 PM, ve3ki wrote:
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
On Wed, Aug 19, 2020 at 01:09 PM, Joe Subich, W4TV wrote:



Which contests are these?
BARTG sponsors contests in particular. Those Brits still think they
have the right to override US rules. After almost 250 years they still
have not learned!

73,

... Joe, W4TV


On 2020-08-19 11:30 AM, Carl - WC4H via groups.io wrote:

Which contests are these?

If your address with the FCC is in Texas and you are operating from that
QTH, the /5 is not required by FCC and not for major contests.

Just curious.

73.
Carl - WC4H


Re: Spotcollector takes long time to come up (motherboard changed)

Dave AA6YQ
 

+ AA6YQ comments below
Thanks, Dave.  I checked my anti-malware app (Malwarebytes) and found that I'd previously added C:\DXLab and C\DXLab\Commander to the "Allow List.":  Malwarebytes says it will skip everything in the folder you list and everything under that folder.

Just to see, I added C:\DXLab\SpotCollector\SpotCollector.exe to the Allow List and rebooted the computer and started DXLab from the Launcher. Same result - delay of about 7 minutes to start up Spot Collector.

I know there are new versions of SpotCollector with different filenames so I added the SpotCollector folder to the Allow List, but no change in SpotCollector boot time.

+ The Launcher starts SpotCollector.exe 

+ You results from booting Windows into "safe mode with networking" indicate that one of the applications being automatically started by Windows when booted "normally" is responsible for SpotCollector's slow startup. Typically, a misconfigured anti-malware application is the culprit, but you should review each of the applications that Windows is configured to start automatically.

      73,

                  Dave, AA6YQ

 


Re: Spotcollector takes long time to come up (motherboard changed)

Randy Powell
 

Thanks, Dave.  I checked my anti-malware app (Malwarebytes) and found that I'd previously added C:\DXLab and C\DXLab\Commander to the "Allow List.":  Malwarebytes says it will skip everything in the folder you list and everything under that folder.

Just to see, I added C:\DXLab\SpotCollector\SpotCollector.exe to the Allow List and rebooted the computer and started DXLab from the Launcher. Same result - delay of about 7 minutes to start up Spot Collector.

I know there are new versions of SpotCollector with different filenames so I added the SpotCollector folder to the Allow List, but no change in SpotCollector boot time.

73,
Randy W6SW


Re: MSK144 logging and time keeping

Peter Laws / N5UWY
 

On Wed, Aug 19, 2020 at 5:08 PM Dave AA6YQ <aa6yq@ambersoft.com> wrote:



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

Look, I've *watched* the news - this IS the end times!!!

*rimshot*




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


Re: DX Keeper tx band not showing regular bands

Dave AA6YQ
 

+ 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


Re: MSK144 logging and time keeping

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

 


Re: DX Keeper tx band not showing regular bands

Grover Cleveland <k7tp@...>
 

Following the above the Errorlog.txt is empty


Re: MSK144 logging and time keeping

Bill Pence
 

yes, no easy answer for this.
MSK144 qso can potentially take super long times....
I think the QSO end time might still have certain flexing as well based on when I get messages vs when the partner sent them?


I certainly get the concept to avoid inaccurate info in your log, but in this narrow case,
I'm not sure I agree that tweaking (yes, that makes it inaccurate) your QSO start time to be within the
30 minute window of the partner logged time (the QSO end time in the case of the original poster) is "bad" 
it seems a a minor infraction.


On Wed, Aug 19, 2020 at 5:48 PM iain macdonnell - N6ML <ar@...> wrote:
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




Re: MSK144 logging and time keeping

iain macdonnell - N6ML
 

On Wed, Aug 19, 2020 at 2:12 PM Dave AA6YQ <aa6yq@ambersoft.com> 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


Re: MSK144 logging and time keeping

Dave AA6YQ
 

+ 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


Re: MSK144 logging and time keeping

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


Re: MSK144 logging and time keeping

Bill Pence
 

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...


Re: MSK144 logging and time keeping

Bill Pence
 

I thought you said the qso partner used qso end time....



On Wed, Aug 19, 2020, 4:31 PM Peter Laws / N5UWY <plaws0@...> wrote:
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!




Re: MSK144 logging and time keeping

Peter Laws / N5UWY
 

On Wed, Aug 19, 2020 at 3:26 PM Bill Pence <pence.bill@gmail.com> 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!


Re: MSK144 logging and time keeping

Bill Pence
 

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. 


Re: MSK144 logging and time keeping

Sidney Shusterman
 

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

On 8/19/2020 2:57 PM, Dave AA6YQ wrote:
+ 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

3201 - 3220 of 199034