Date   
Re: Create SQL Filter From Current Button Selections

Hasan Schiers N0AN
 

Hi Mike,
For the upcoming E season, this combo filter will do the job nicely, assuming I understand how it works. You can see my other rather long post  explaining it.

((Band='10M') or (Band='6M'))  AND ((NAE='Y') or (NAM='Y') or (NAW='Y'))

This seems to say: 

Show me EVERY station anyone heard from ANYWHERE on 6m or 10m as long as they heard them from North America.

...but I'm very new to this and could have it all wrong.

I could further restrict it to MSK144 and FT8.  I may do that just to play, but lots of people monitor 50.125 SSB and that would also get my attention. Also beacons will show with the existing setting, which is also informative.

Thanks so much for your help.
73, N0AN
Hasan


On Tue, Mar 24, 2020 at 12:34 PM ND9G Mike <mike.nd9g@...> wrote:
I see you worked out a query to possibly get what you want. In your previous email you mentioned that these spots were all being submitted via your instance of WSJT-X.

You can look at your SpotCollector fields and look for the Network field to see where the spot is coming from and set your SQL to filter on the network.

Example:
Band='6M' AND Mode='MSK144' AND Network='WSJT'

Substitute WSJT with whatever the actual value.

73,
Mike ND9G


On Tue, Mar 24, 2020 at 8:21 AM Hasan Schiers N0AN <hbasri.schiers6@...> wrote:
Excellent instructions. While not automatically generated, the examples are great and worked perfectly.

For what I was trying to do: Show me only spots from NA-E/M/S, on MSK144

BAnd='6M' AND Mode='MSK144' AND ((NAE='Y') or (NAM='Y') or (NAW='Y'))

That worked. Now I should look how I could refine it to include Mexico and (if not considered part of NA, Canada) and I could  put in a Band filter of 6 meters, because I don't have a setup for 2m MSK144.

Thanks for the pointer.
73, N0AN
Hasan


On Tue, Mar 24, 2020 at 7:53 AM Hasan Schiers N0AN via Groups.Io <hbasri.schiers6=gmail.com@groups.io> wrote:
Thanks, Scott! That was just what I was looking for.
73, N0AN
Hasan


On Tue, Mar 24, 2020 at 6:50 AM Scott Stembaugh <radio.n9ljx@...> wrote:
Hasan,

There are 4 banks of 8 SQL filter buttons available.  CTRL-Click on the bottom row of buttons brings up the editor.  See https://www.dxlabsuite.com/spotcollector/Help/SpotDatabase.htm#Filtering%20with%20SQL%20expressions
on how to combine standard filters with custom SQL.

73,
--scott


On Tue, Mar 24, 2020 at 6:57 AM Hasan Schiers N0AN <hbasri.schiers6@...> wrote:
It might be interesting to have a way to automatically generate a compound SQL Filter from Current Filter Settings.

I am currently using Band and Mode and Origin

To show Spots from North America, 6 meters, MSK144 only. (with the Buttons already provided)

It would be nice to combine any currently existing set of button filters into a single SQL expression and save it for use as a Button.

...just an idea, and not very important, but it struck me as useful.

73, N0AN

Hasan

Re: Compound Spot Filter

iain macdonnell - N6ML
 

If you see a spot database entry that you believe was incorrectly
included by your origin filter, right-click on it, and select "Display
spots of ... near ... in ...". That should show you all of the spots
that are included in that database entry. You will likely find that at
least one of them matches your origin criterion, but it may not be the
most recent one.

73,

~iain / N6ML


On Tue, Mar 24, 2020 at 12:25 PM Hasan Schiers N0AN
<@Hasan> wrote:

Dave,

I must be thick.

What I was looking for and finally settled on is this:

Band='6M' AND Mode='MSK144' AND ((NAE='Y') or (NAM='Y') or (NAW='Y'))

I wanted to see only spots from 6 meters and mode MSK144, and I only wanted to see them if they were heard (and subsequently spotted) in North America.

I have no interest in someone in the UK telling me they are seeing active stations in Germany on 6 meters.

If a station is not being heard anywhere in the USA, I'm not going to hear them, so why do I want them cluttering up my screen?

Am I somehow misinterpreting what the above filter does?

After a little more playing, I came up with the following Filter that eliminates mode, but collapses two bands which tend to show similar Es openings.

((Band='10M') or (Band='6M')) AND ((NAE='Y') or (NAM='Y') or (NAW='Y'))

Again, I'm interpreting this to say,

On either band, if someone from North America has heard any station, any mode, show it to me. If you are not from North America, leave me alone.

This appears to answer the question: Is 6 meters open from anywhere in the world to North America? .

Is the filter, as I have defined it doing what I asked it to do, or do I have a syntax error of some sort?
=======================================

With respect to your other point:

+ For Es propagation on 6 meters, specifying a maximum distance between your QTH and the closest spotting station works best. I've never experienced an F2 opening on 6 meter.

This doesn't reflect what band conditions are actually like on 6 meters nearly every summer, at least in Missouri, Iowa, Texas, Colorado, etc:

Multi-Hop Es to Japan via FT8 is very common on 6 meters in the summer. Two years in a row, I have worked more than 30 JA stations on 6 meter multi-hop Es in a single day. (2018 and 2019)

I also worked EU and Africa both years on FT8, 6 meters.,..and it was clearly multi-hop sporadic E. The keys are mode, power and antennas. (in other words, EIRP)

All were on FT8, all involved a minimum of 500w out and all were using antennas with no less than 10 dBd gain.

Many USA operators experienced the same openings and while they were highly focused, they included Missouri to Japan and Texas to Japan as well.

And...all were spotted on PSKRreporter by stations from Ohio to Arizona. There was no F2 at the time, but there were E clouds all over the place.

It looks to me like SC can do the same thing with the filter example I used above:

((Band='10M') or (Band='6M')) AND ((NAE='Y') or (NAM='Y') or (NAW='Y'))

If those JAs show up this summer, this filter will spot them, unless I'm completely confused. When I ran this filter this morning it showed:

All the 6m MSK144 spots from my local WSJT-X
All the 6m MSK144 spots from N6WS
All the 6m FT8 Spots from N6WS
and a single 10m FT8 from N6WS

All those spots originated from North America.

Do I still have it wrong?

73, N0AN
Hasan


On Tue, Mar 24, 2020 at 1:17 PM Dave AA6YQ <@AA6YQ> wrote:

+ AA6YQ comments below

I have an SQL filter set for Mode='MSK144'

and it works fine, but it is showing Spots from EU which are not useful on 6 meters.


I tried: Mode='MSK144' AND Origin="NA-M"

...and that didn't work, spots were found.

How do I create an SQL Filter that shows only spots for MSK144 and Spots originating from USA, Canada and Mexico? (for example)

Or, I could filter by spot source, since my spots for 6m MSK144 are generated by my copy of WSJT-X.

I know I could use the Origin and Mode buttons, but I wanted a one click solution.


+ SpotCollector displays entries for active DX stations, not spots. An active DX station can be spotted from many different locations. When you filter the Spot Database Display with

Origin="NA-M"

+ you are saying "show me all active DX stations that have been spotted from the middle of North America". You are not saying "show me all active DX stations that have been spotted from the middle of North America and have not been spotted from anywhere else on the planet"; there is an SQL expression that would accomplish this, but it would not be useful for DXing.

+ There are several good techniques for hiding the entries of active DX stations that you probably can't hear. These techniques are described here:

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

+ For Es propagation on 6 meters, specifying a maximum distance between your QTH and the closest spotting station works best. I've never experienced an F2 opening on 6 meters, and have never used a meteor scatter mode on 6 meters, so I can't recommend a specific technique for those; the above article presents the available techniques.

+ If you want to "roll your own" SQL filters for this purpose, study the following Spot Database Fields in

<https://www.dxlabsuite.com/spotcollector/Help/SpotDatabase.htm#Spot%20Database%20Field%20Table>

- UN, NAE, NAM, NAW, SA, EU, AF, AS, OC

- Distance

- ODX

- OMDX

- SPSNR, LPSNR, ReqSNR

- SPProb, LPProb

- ActualSNR, ActualSNRMin, ActualSNRMax

+ If you discover one or more useful new techniques, please share them here!

73,

Dave, AA6YQ





Re: Compound Spot Filter

Hasan Schiers N0AN
 

Dave,

I must be thick.

What I was looking for and finally settled on is this:

Band='6M' AND Mode='MSK144' AND ((NAE='Y') or (NAM='Y') or (NAW='Y'))

I wanted to see only spots from 6 meters and mode MSK144, and I only wanted to see them if they were heard (and subsequently spotted) in North America.

I have no interest in someone in the UK telling me they are seeing active stations in Germany on 6 meters.

If a station is not being heard anywhere in the USA, I'm not going to hear them, so why do I want them cluttering up my screen?

Am I somehow misinterpreting what the above filter does?

After a little more playing, I came up with the following Filter that eliminates mode, but collapses two bands which tend to show similar Es openings.

((Band='10M') or (Band='6M'))  AND ((NAE='Y') or (NAM='Y') or (NAW='Y'))

Again, I'm interpreting this to say,

On either band, if someone from North America has heard any station, any mode, show it to me. If you are not from North America, leave me alone.

This appears to answer the question: Is 6 meters open from anywhere in the world to North America? .

Is the filter, as I have defined it doing what I asked it to do, or do I have a syntax error of some sort?
=======================================

With respect to your other point:

+ For Es propagation on 6 meters, specifying a maximum distance between your QTH and the closest spotting station works best. I've never experienced an F2 opening on 6 meter.

This doesn't reflect what band conditions are actually like on 6 meters nearly every summer,  at least in Missouri, Iowa, Texas, Colorado, etc:

Multi-Hop Es to Japan via FT8 is very common on 6 meters in the summer. Two years in a row, I have worked more than 30 JA stations on 6 meter multi-hop Es in a single day. (2018 and 2019)

I also worked EU and Africa both years on FT8, 6 meters.,..and it was clearly multi-hop sporadic E. The keys are mode, power and antennas. (in other words, EIRP)

All were on FT8, all involved a minimum of 500w  out and all were using antennas with no less than 10 dBd gain.

Many USA operators experienced the same openings and while they were highly focused, they included Missouri to Japan and Texas to Japan as well.

And...all were spotted on PSKRreporter by stations from Ohio to Arizona. There was no F2 at the time, but there were E clouds all over the place.

It looks to me like SC can do the same thing with the filter example I used above:

((Band='10M') or (Band='6M'))  AND ((NAE='Y') or (NAM='Y') or (NAW='Y'))

If those JAs show up this summer, this filter will spot them, unless I'm completely confused. When I ran this filter this morning it showed:

All the 6m MSK144 spots from my local WSJT-X
All the 6m MSK144 spots from N6WS
All the 6m FT8 Spots from N6WS
and a single 10m FT8 from N6WS

All those spots originated from North America.

Do I still have it wrong?

73, N0AN
Hasan


On Tue, Mar 24, 2020 at 1:17 PM Dave AA6YQ <aa6yq@...> wrote:
+ AA6YQ comments below

I have an SQL filter set for Mode='MSK144'

and it works fine, but it is showing Spots from EU which are not useful on 6 meters.


I tried: Mode='MSK144' AND Origin="NA-M"

...and that didn't work, spots were found.

How do I create an SQL Filter that shows only spots for MSK144 and Spots originating from USA, Canada and Mexico?  (for example)

Or, I could filter by spot source, since my spots for 6m MSK144 are generated by my copy of WSJT-X.

I know I could use the Origin and Mode buttons, but I wanted a one click solution.


+ SpotCollector displays entries for active DX stations, not spots. An active DX station can be spotted from many different locations. When you filter the Spot Database Display with

Origin="NA-M"

+ you are saying "show me all active DX stations that have been spotted from the middle of North America".  You are not saying "show me all active DX stations that have been spotted from the middle of North America and have not been spotted from anywhere else on the planet"; there is an SQL expression that would accomplish this, but it would not be useful for DXing.

+ There are several good techniques for hiding the entries of active DX stations that you probably can't hear. These techniques are described here:

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

+ For Es propagation on 6 meters, specifying a maximum distance between your QTH and the closest spotting station works best. I've never experienced an F2 opening on 6 meters, and have never used a meteor scatter mode on 6 meters, so I can't recommend a specific technique for those; the above article presents the available techniques.

+ If you want to "roll your own" SQL filters for this purpose, study the following Spot Database Fields in

<https://www.dxlabsuite.com/spotcollector/Help/SpotDatabase.htm#Spot%20Database%20Field%20Table>

 - UN, NAE, NAM, NAW, SA, EU, AF, AS, OC

 - Distance

 - ODX

 - OMDX

 - SPSNR, LPSNR, ReqSNR

 - SPProb, LPProb

 - ActualSNR, ActualSNRMin, ActualSNRMax

+ If you discover one or more useful new techniques, please share them here!

        73,

               Dave, AA6YQ






Re: DXCC Compare of DXpedition log uses home call LOTW account

Dave AA6YQ
 

+ AA6YQ comments below

Years ago I went on a DXpedition to WH0/K0BBC I try to do a DXCC Compare and the program compares my WH0/K0BBC log to my home call K0BBC LOTW account.

+ You should not be comparing your WH0/K0BBC log to your K0BBC DXCC Record; you should be comparing your WH0/K0BBC log to your WH0/K0BBC DXCC Record.

+ This article explains how to determine the "DXCC Account Number" for each of your DXCC Records:

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

+ Then before invoking the "DXCC Compare" function, specify the appropriate "DXCC account #" in the "Log Settings" panel on the Configuration window's Log tab.

73,

Dave, AA6YQ

Re: Compound Spot Filter

Dave AA6YQ
 

+ AA6YQ comments below

I have an SQL filter set for Mode='MSK144'

and it works fine, but it is showing Spots from EU which are not useful on 6 meters.


I tried: Mode='MSK144' AND Origin="NA-M"

...and that didn't work, spots were found.

How do I create an SQL Filter that shows only spots for MSK144 and Spots originating from USA, Canada and Mexico? (for example)

Or, I could filter by spot source, since my spots for 6m MSK144 are generated by my copy of WSJT-X.

I know I could use the Origin and Mode buttons, but I wanted a one click solution.


+ SpotCollector displays entries for active DX stations, not spots. An active DX station can be spotted from many different locations. When you filter the Spot Database Display with

Origin="NA-M"

+ you are saying "show me all active DX stations that have been spotted from the middle of North America". You are not saying "show me all active DX stations that have been spotted from the middle of North America and have not been spotted from anywhere else on the planet"; there is an SQL expression that would accomplish this, but it would not be useful for DXing.

+ There are several good techniques for hiding the entries of active DX stations that you probably can't hear. These techniques are described here:

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

+ For Es propagation on 6 meters, specifying a maximum distance between your QTH and the closest spotting station works best. I've never experienced an F2 opening on 6 meters, and have never used a meteor scatter mode on 6 meters, so I can't recommend a specific technique for those; the above article presents the available techniques.

+ If you want to "roll your own" SQL filters for this purpose, study the following Spot Database Fields in

<https://www.dxlabsuite.com/spotcollector/Help/SpotDatabase.htm#Spot%20Database%20Field%20Table>

- UN, NAE, NAM, NAW, SA, EU, AF, AS, OC

- Distance

- ODX

- OMDX

- SPSNR, LPSNR, ReqSNR

- SPProb, LPProb

- ActualSNR, ActualSNRMin, ActualSNRMax

+ If you discover one or more useful new techniques, please share them here!

73,

Dave, AA6YQ

Re: A QSO in limbo ...

Dave AA6YQ
 

+ AA6YQ comments below

I believe I ran into the same problem last night, with one minor difference.

I uploaded about 25 FT8 contacts, all 12m/10m. LOTW said upload complete.

But when I went to Sync the logs an hour later, only ~7 completed the Log Sync (Y,R) and the others remained in the (U,R) state.

Fresh contacts this morning loaded fine, but it did not Sync those that failed to SYNC last night. They seem to be in limbo of some kind.

Reset one QSO to (R,_) and no joy there, says it is a duplicate. Will look for that duplicate box mentioned here somewhere.

Still reading the threads here. Thanks to the group.

+ See

<https://www.dxlabsuite.com/dxlabwiki/ReuploadUnacceptedLotW.

73,

Dave, AA6YQ

Re: A QSO in limbo ...

Dave AA6YQ
 

+ AA6YQ comments below

TQSL reported this QSO as having been previously uploaded. However, it gave me the option to upload again if there had been a server error which is what I expected had happened. I did upload my ZD8SC QSO again and in due course it appeared in my LotW list Most Recent QSOs and was properly sync d by DXKeeper.
It was good to learn that direct TQSL upload gives you the option of overriding the previously uploaded notification and allows the upload.
The DXKeeper way to do this is: QSL Config -> LotW -> Permit uploading of QSOs already uploaded to LotW.

+ Because some ops were re-submitting every QSO in their log each time they had a few new QSOs to submit to LoTW, TQSL was equipped with a database that keeps track of which QSOs you've submitted to LoTW. If any QSO in a batch was already submitted -- what older versions of TQSL refers to as "a dupe" -- then all of the QSOs in the batch are rejected.

+ There are circumstances in which a QSO submitted to LoTW either never arrives at LoTW or arrives, but isn't accepted - either due to a network failure or an LoTW failure. Mike K6MKF, it looks like that's what happened to your ZD8SC QSO.

+ Iain N6ML's recommendation above is the correct way to recover from a situation where one or more QSOs was submitted to LoTW by TQSL, but not accepted by LoTW. Step-by-step instructions are here:

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

73,

Dave, AA6YQ

Re: A QSO in limbo ...

K9MK
 

I believe I ran into the same problem last night, with one minor difference.

 

I uploaded about 25 FT8 contacts, all 12m/10m.   LOTW said upload complete.

But when I went to Sync the logs an hour later, only ~7 completed the Log Sync (Y,R) and the others remained in the (U,R) state.

 

Fresh contacts this morning loaded fine, but it did not Sync those that failed to SYNC last night.  They seem to be in limbo of some kind.

 

Reset one QSO to (R,_) and no joy there, says it is a duplicate.  Will look for that duplicate box mentioned here somewhere.

 

Still reading the threads here.  Thanks to the group.

 

Mike K9MK

 

 

 

From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of BILL KENNAMER
Sent: Tuesday, March 24, 2020 10:07 AM
To: DXLab@groups.io
Subject: Re: [DXLab] A QSO in limbo ...

 

Export the QSO the a file. Then use TQSL to upload to LOTW. TQSL will tell you if it’s a dupe or not.

K5FUV 


Sent from Yahoo Mail for iPad

On Tuesday, March 24, 2020, 10:01 AM, Mike Flowers <mike.flowers@...> wrote:

Thanks, Dave.  I think the ARRL staff are all working from home at this
point so the help tickets are likely pilling up.

If there isn't a way to 'reset' this log entry, I'll simply create a new QSO
entry and upload that.

I'm interested in learning what state my current QSO record is in and how it
might be set so that it can be uploaded in LotW again.

- 73 and good DX de Mike, K6MKF, NCDXC Secretary

> -----Original Message-----
> From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Dave / NR1DX
> Sent: Tuesday, March 24, 2020 07:57
> To: DXLab@groups.io
> Subject: Re: [DXLab] A QSO in limbo ..
>
> I think I would start by making a "Help Ticket" to the  LOTW desk at ARRL
>
> http://www.arrl.org/lotw-help-ticket
>
> Tell them you uploaded a    QSO that is not in the LOTW log ( give them
the QSO
> details) and that your logging software wont let you do it again because
it thinks
> it went up. They may be able to manually load it?
>
> Dave
> NR1DX
>
>
>
> On 3/24/2020 9:48 AM, Mike Flowers wrote:
> >
> > Hi All,
> >
> > I have created a puzzlement for myself, and I’d like so guidance on
> > how to solve it.
> >
> > I logged ZD8SC last night on 20M FT8 and uploaded that log record to
> > LotW as the last one in a batch of logged QSOs.  I like to keep
> > current with LotW.  All processed normally.
> >
> > After a few minutes I checked to see if the latest batch of logged
> > QSOs had been updated in LotW and they appeared to have been. In
> > DXKeeper I performed ‘Sync LotW QSOs’, then ‘Sync LotW QSLs’.  All
> > seemed to go well.
> >
> > When I revisited LotW and looked at the results of the ‘Most Recent
> > QSOs’ I discovered that the ZD8SC QSO was not in the list. In DXKeeper
> > that log entry’s LotW Send = U, so DXKeeper marked it as uploaded.
> >
> > I thought I could fix this be simply editing the ZD8SC log entry to
> > LotW Send = R and uploading to LotW again.  But DXKeeper reports that
> > QSO is a dupe.
> >
> > LotW has been having some problems lately, so perhaps my ZD8SC QSO is
> > in some sort of processing limbo.
> >
> > I would appreciate some guidance on how to resolve my dilemma.
> >
> > Thanks!
> >
> > *- 73 and good DX de Mike, K6MKF <http://www.qrz.com/db/k6mkf/>, NCDXC
> > <https://www.ncdxc.org/> Secretary*
> >
> >
>
> --
> Dave
> Manuals@...
> www.ArtekManuals.com
>
>
> --
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
>



Re: Icom IC-R30 control

Dave AA6YQ
 

+ AA6YQ comments below

Many thanks Dave. I got the connection with the Icom IC-R30 running.
Now I have yet to master DXLab as I never used it before. The DXLab website seems very informative.
Seems that the R30 frequency is not tracking automaticly with SatPC32 wich is connected to DXLab commander as seen on the commander window.

+ To interoperate with SatPC32,

1. configure SatPC32 to control your R30

2. set Commander's "Radio Model" to SatPC32

+ The details are here:

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

+ To learn DXLab, start here:

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

+ It's especially important to go slowly!

73,

Dave, AA6YQ

Re: Create SQL Filter From Current Button Selections

ND9G Mike
 

I see you worked out a query to possibly get what you want. In your previous email you mentioned that these spots were all being submitted via your instance of WSJT-X.

You can look at your SpotCollector fields and look for the Network field to see where the spot is coming from and set your SQL to filter on the network.

Example:
Band='6M' AND Mode='MSK144' AND Network='WSJT'

Substitute WSJT with whatever the actual value.

73,
Mike ND9G


On Tue, Mar 24, 2020 at 8:21 AM Hasan Schiers N0AN <hbasri.schiers6@...> wrote:
Excellent instructions. While not automatically generated, the examples are great and worked perfectly.

For what I was trying to do: Show me only spots from NA-E/M/S, on MSK144

BAnd='6M' AND Mode='MSK144' AND ((NAE='Y') or (NAM='Y') or (NAW='Y'))

That worked. Now I should look how I could refine it to include Mexico and (if not considered part of NA, Canada) and I could  put in a Band filter of 6 meters, because I don't have a setup for 2m MSK144.

Thanks for the pointer.
73, N0AN
Hasan


On Tue, Mar 24, 2020 at 7:53 AM Hasan Schiers N0AN via Groups.Io <hbasri.schiers6=gmail.com@groups.io> wrote:
Thanks, Scott! That was just what I was looking for.
73, N0AN
Hasan


On Tue, Mar 24, 2020 at 6:50 AM Scott Stembaugh <radio.n9ljx@...> wrote:
Hasan,

There are 4 banks of 8 SQL filter buttons available.  CTRL-Click on the bottom row of buttons brings up the editor.  See https://www.dxlabsuite.com/spotcollector/Help/SpotDatabase.htm#Filtering%20with%20SQL%20expressions
on how to combine standard filters with custom SQL.

73,
--scott


On Tue, Mar 24, 2020 at 6:57 AM Hasan Schiers N0AN <hbasri.schiers6@...> wrote:
It might be interesting to have a way to automatically generate a compound SQL Filter from Current Filter Settings.

I am currently using Band and Mode and Origin

To show Spots from North America, 6 meters, MSK144 only. (with the Buttons already provided)

It would be nice to combine any currently existing set of button filters into a single SQL expression and save it for use as a Button.

...just an idea, and not very important, but it struck me as useful.

73, N0AN

Hasan

Re: Joe KC2TN

Dave AA6YQ
 

+ AA6YQ comments below

I'm here and doing fine!
Just been preoccupied.

Got your SC release and it's installed.
No negative issues yet.

+ I'm relieved that you're ok, Joe; in these times, I'm following up on "unexpected silences".

+ Thanks for installing the new version of SpotCollector. If you encounter any adverse behavior, please

1. enable "log debugging info" on the Configuration window's General tab

2. repeat the actions that lead to the adverse behavior until you replicate it

3. disable "log debugging info" on the Configuration window's General tab

4. attach the errorlog.txt file from your SpotCollector folder to an email message, and send it to me via

aa6yq (at) ambersoft.com

+ Thanks!

73,

Dave, AA6YQ

Re: A QSO in limbo ...

Mike Flowers
 

Thanks, Al.  

This has never happened to any of my uploads before, so I’ll leave that feature disabled.   

-- 73 de Mike Flowers, K6MKF, NCDXC - "It's about DX!"

On Mar 24, 2020, at 8:45 AM, Al Groff via Groups.Io <al.k0vm@...> wrote:

 In DXKeeper >QSL Config>LoTW .. you can enable 'Permit uploading of QSO's already uploaded' ..
It will be un-enabled after each upload attempt.

AL, K0VM

On 3/24/2020 10:15 AM, iain macdonnell - N6ML wrote:
I just checked my upload from last night (web interface -> Your
Account -> Your Activity -> Details). It shows:

2020-03-24 03:39:04 LOTW_QSO: Processing file: 20200324033837.2347
2020-03-24 03:39:04 LOTW_QSO: User file:  LotWUpload.tq8
2020-03-24 03:39:04 LOTW_QSO: Certificate found for N6ML - UNITED
STATES OF AMERICA (291)
2020-03-24 03:39:04 LOTW_QSO: Processing terminated with an unexpected
failure. System administrator has been notified.

Something is (or at least was) broken.

73,

    ~iain / N6ML




On Tue, Mar 24, 2020 at 6:48 AM Mike Flowers <mike.flowers@...> wrote:
Hi All,



I have created a puzzlement for myself, and I’d like so guidance on how to solve it.



I logged ZD8SC last night on 20M FT8 and uploaded that log record to LotW as the last one in a batch of logged QSOs.  I like to keep current with LotW.  All processed normally.



After a few minutes I checked to see if the latest batch of logged QSOs had been updated in LotW and they appeared to have been.   In DXKeeper I performed ‘Sync LotW QSOs’, then ‘Sync LotW QSLs’.  All seemed to go well.



When I revisited LotW and looked at the results of the ‘Most Recent QSOs’ I discovered that the ZD8SC QSO was not in the list.   In DXKeeper that log entry’s LotW Send = U, so DXKeeper marked it as uploaded.



I thought I could fix this be simply editing the ZD8SC log entry to LotW Send = R and uploading to LotW again.  But DXKeeper reports that QSO is a dupe.



LotW has been having some problems lately, so perhaps my ZD8SC QSO is in some sort of processing limbo.



I would appreciate some guidance on how to resolve my dilemma.



Thanks!



- 73 and good DX de Mike, K6MKF, NCDXC Secretary






Re: A QSO in limbo ...

iain macdonnell - N6ML
 

On Tue, Mar 24, 2020 at 8:28 AM Mike Flowers <@K6MKF> wrote:

Thanks, Bill!



TQSL reported this QSO as having been previously uploaded. However, it gave me the option to upload again if there had been a server error – which is what I expected had happened. I did upload my ZD8SC QSO again and in due course it appeared in my LotW list Most Recent QSOs and was properly sync’d by DXKeeper.



It was good to learn that direct TQSL upload gives you the option of overriding the ‘previously uploaded’ notification and allows the upload.
The DXKeeper way to do this is: QSL Config -> LotW -> Permit uploading
of QSOs already uploaded to LotW.

73,

~iain / N6ML



From: Mike Flowers <@K6MKF>
Sent: Tuesday, March 24, 2020 08:10
To: DXLab@groups.io
Subject: RE: [DXLab] A QSO in limbo ...



When using DXKeeper to upload to LotW via TSQL, it is reported as a dupe, so I suspect that a stand-alone effort will produce the same result, but worth a shot.



I’ll see what happens and let you know.



- 73 and good DX de Mike, K6MKF, NCDXC Secretary



From: DXLab@groups.io <DXLab@groups.io> On Behalf Of BILL KENNAMER
Sent: Tuesday, March 24, 2020 08:07
To: DXLab@groups.io
Subject: Re: [DXLab] A QSO in limbo ...



Export the QSO the a file. Then use TQSL to upload to LOTW. TQSL will tell you if it’s a dupe or not.

K5FUV


Sent from Yahoo Mail for iPad

On Tuesday, March 24, 2020, 10:01 AM, Mike Flowers <@K6MKF> wrote:

Thanks, Dave. I think the ARRL staff are all working from home at this
point so the help tickets are likely pilling up.

If there isn't a way to 'reset' this log entry, I'll simply create a new QSO
entry and upload that.

I'm interested in learning what state my current QSO record is in and how it
might be set so that it can be uploaded in LotW again.

- 73 and good DX de Mike, K6MKF, NCDXC Secretary

-----Original Message-----
From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Dave / NR1DX
Sent: Tuesday, March 24, 2020 07:57
To: DXLab@groups.io
Subject: Re: [DXLab] A QSO in limbo ...

I think I would start by making a "Help Ticket" to the LOTW desk at ARRL

http://www.arrl.org/lotw-help-ticket

Tell them you uploaded a QSO that is not in the LOTW log ( give them
the QSO
details) and that your logging software wont let you do it again because
it thinks
it went up. They may be able to manually load it?

Dave
NR1DX



On 3/24/2020 9:48 AM, Mike Flowers wrote:

Hi All,

I have created a puzzlement for myself, and I’d like so guidance on
how to solve it.

I logged ZD8SC last night on 20M FT8 and uploaded that log record to
LotW as the last one in a batch of logged QSOs. I like to keep
current with LotW. All processed normally.

After a few minutes I checked to see if the latest batch of logged
QSOs had been updated in LotW and they appeared to have been. In
DXKeeper I performed ‘Sync LotW QSOs’, then ‘Sync LotW QSLs’. All
seemed to go well.

When I revisited LotW and looked at the results of the ‘Most Recent
QSOs’ I discovered that the ZD8SC QSO was not in the list. In DXKeeper
that log entry’s LotW Send = U, so DXKeeper marked it as uploaded.

I thought I could fix this be simply editing the ZD8SC log entry to
LotW Send = R and uploading to LotW again. But DXKeeper reports that
QSO is a dupe.

LotW has been having some problems lately, so perhaps my ZD8SC QSO is
in some sort of processing limbo.

I would appreciate some guidance on how to resolve my dilemma.

Thanks!

*- 73 and good DX de Mike, K6MKF <http://www.qrz.com/db/k6mkf/>, NCDXC
<https://www.ncdxc.org/> Secretary*

--
Dave
Manuals@...
www.ArtekManuals.com


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



Re: A QSO in limbo ...

Al Groff
 

In DXKeeper >QSL Config>LoTW .. you can enable 'Permit uploading of QSO's already uploaded' ..
It will be un-enabled after each upload attempt.

AL, K0VM

On 3/24/2020 10:15 AM, iain macdonnell - N6ML wrote:
I just checked my upload from last night (web interface -> Your
Account -> Your Activity -> Details). It shows:

2020-03-24 03:39:04 LOTW_QSO: Processing file: 20200324033837.2347
2020-03-24 03:39:04 LOTW_QSO: User file:  LotWUpload.tq8
2020-03-24 03:39:04 LOTW_QSO: Certificate found for N6ML - UNITED
STATES OF AMERICA (291)
2020-03-24 03:39:04 LOTW_QSO: Processing terminated with an unexpected
failure. System administrator has been notified.

Something is (or at least was) broken.

73,

    ~iain / N6ML




On Tue, Mar 24, 2020 at 6:48 AM Mike Flowers <mike.flowers@...> wrote:
Hi All,



I have created a puzzlement for myself, and I’d like so guidance on how to solve it.



I logged ZD8SC last night on 20M FT8 and uploaded that log record to LotW as the last one in a batch of logged QSOs.  I like to keep current with LotW.  All processed normally.



After a few minutes I checked to see if the latest batch of logged QSOs had been updated in LotW and they appeared to have been.   In DXKeeper I performed ‘Sync LotW QSOs’, then ‘Sync LotW QSLs’.  All seemed to go well.



When I revisited LotW and looked at the results of the ‘Most Recent QSOs’ I discovered that the ZD8SC QSO was not in the list.   In DXKeeper that log entry’s LotW Send = U, so DXKeeper marked it as uploaded.



I thought I could fix this be simply editing the ZD8SC log entry to LotW Send = R and uploading to LotW again.  But DXKeeper reports that QSO is a dupe.



LotW has been having some problems lately, so perhaps my ZD8SC QSO is in some sort of processing limbo.



I would appreciate some guidance on how to resolve my dilemma.



Thanks!



- 73 and good DX de Mike, K6MKF, NCDXC Secretary







Re: LOTW upload issues?

K0BBC
 

You can quickly check the health of the LOTW Inbox at the following link
http://www.arrl.org/logbook-queue-status

DXCC Compare of DXpedition log uses home call LOTW account

K0BBC
 

Years ago I went on a DXpedition to WH0/K0BBC
I try to do a DXCC Compare and the program compares my WH0/K0BBC log to my home call K0BBC LOTW account.
Report Output:

WH0/K0BBC DXCC Verification Discrepancies 24-Mar-2020
Log file     = C:\DXLab\DXKeeper\Databases\WH0_K0BBC.mdb
DXCC Account = Matt Holden, K0BBC

In QSL > QSL Config > LotW I think I have the key fields setup correctly:

Username = K0BBC
Limit Sync operations to this callsign WH0/K0BBC
TQSL station location WorldResort
TQSL station callsign WH0/K0BBC

I had this working correctly for many years and it has not worked for about a while now.
I am using a separate registry file for each DXCC entity I visit to keep the above values in sync with the county I visit.
Anyone have a similar experience and a proposed solution?
73 Matt K0BBC

Re: A QSO in limbo ...

Mike Flowers
 

Sure enough ...

Date/Time: 2020-03-23 22:43:25
User: k6mkf
File: LotWUpload.tq8
Messages:
2020-03-23 22:43:25 LOTW_QSO: Processing file: 20200323220401.21680
2020-03-23 22:43:25 LOTW_QSO: User file: LotWUpload.tq8
2020-03-23 22:43:25 LOTW_QSO: Certificate found for K6MKF - UNITED STATES OF AMERICA (291)
2020-03-23 22:43:25 LOTW_QSO: Processing terminated with an unexpected failure. System administrator has been notified.

- 73 and good DX de Mike, K6MKF, NCDXC Secretary

-----Original Message-----
From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Mike Flowers via
Groups.Io
Sent: Tuesday, March 24, 2020 08:31
To: DXLab@groups.io
Subject: Re: [DXLab] A QSO in limbo ...

Thanks, Joe. I used TSQL to correct the issue, but I have noted your method and
will check out what happened with the initial upload.

- 73 and good DX de Mike, K6MKF, NCDXC Secretary

-----Original Message-----
From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Joe Subich, W4TV
Sent: Tuesday, March 24, 2020 08:10
To: DXLab@groups.io
Subject: Re: [DXLab] A QSO in limbo ...


Log into LotW on the web ... click "Your Account" in the top menu then
select "Your Activity" in the left hand menu. You can then select
"Result" for your last upload which will tell you how many QSOs were
uploaded, processed, etc. It will also tell you if there were any
errors. You can compare that with your last upload.

73,

... Joe, W4TV


On 2020-03-24 9:48 AM, Mike Flowers wrote:
Hi All,



I have created a puzzlement for myself, and I'd like so guidance on
how to solve it.



I logged ZD8SC last night on 20M FT8 and uploaded that log record to
LotW as the last one in a batch of logged QSOs. I like to keep
current with
LotW.
All processed normally.



After a few minutes I checked to see if the latest batch of logged QSOs had
been updated in LotW and they appeared to have been. In DXKeeper I
performed 'Sync LotW QSOs', then 'Sync LotW QSLs'. All seemed to go well.



When I revisited LotW and looked at the results of the 'Most Recent QSOs' I
discovered that the ZD8SC QSO was not in the list. In DXKeeper that log
entry's LotW Send = U, so DXKeeper marked it as uploaded.



I thought I could fix this be simply editing the ZD8SC log entry to
LotW Send = R and uploading to LotW again. But DXKeeper reports
that QSO is a dupe.



LotW has been having some problems lately, so perhaps my ZD8SC QSO
is in some sort of processing limbo.



I would appreciate some guidance on how to resolve my dilemma.



Thanks!



- 73 and good DX de Mike, <http://www.qrz.com/db/k6mkf/> K6MKF,
NCDXC <https://www.ncdxc.org/> Secretary








Re: A QSO in limbo ...

Mike Flowers
 

Thanks, Joe. I used TSQL to correct the issue, but I have noted your method and will check out what happened with the initial upload.

- 73 and good DX de Mike, K6MKF, NCDXC Secretary

-----Original Message-----
From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Joe Subich, W4TV
Sent: Tuesday, March 24, 2020 08:10
To: DXLab@groups.io
Subject: Re: [DXLab] A QSO in limbo ...


Log into LotW on the web ... click "Your Account" in the top menu then select
"Your Activity" in the left hand menu. You can then select "Result" for your last
upload which will tell you how many QSOs were uploaded, processed, etc. It will
also tell you if there were any errors. You can compare that with your last
upload.

73,

... Joe, W4TV


On 2020-03-24 9:48 AM, Mike Flowers wrote:
Hi All,



I have created a puzzlement for myself, and I'd like so guidance on
how to solve it.



I logged ZD8SC last night on 20M FT8 and uploaded that log record to
LotW as the last one in a batch of logged QSOs. I like to keep current with
LotW.
All processed normally.



After a few minutes I checked to see if the latest batch of logged QSOs had
been updated in LotW and they appeared to have been. In DXKeeper I
performed 'Sync LotW QSOs', then 'Sync LotW QSLs'. All seemed to go well.



When I revisited LotW and looked at the results of the 'Most Recent QSOs' I
discovered that the ZD8SC QSO was not in the list. In DXKeeper that log
entry's LotW Send = U, so DXKeeper marked it as uploaded.



I thought I could fix this be simply editing the ZD8SC log entry to
LotW Send = R and uploading to LotW again. But DXKeeper reports that
QSO is a dupe.



LotW has been having some problems lately, so perhaps my ZD8SC QSO is
in some sort of processing limbo.



I would appreciate some guidance on how to resolve my dilemma.



Thanks!



- 73 and good DX de Mike, <http://www.qrz.com/db/k6mkf/> K6MKF, NCDXC
<https://www.ncdxc.org/> Secretary






Re: Icom IC-R30 control

Ron Liekens
 

Many thanks Dave. I got the connection with the Icom IC-R30 running.
Now I have yet to master DXLab as I never used it before. The DXLab website seems very informative.
Seems that the R30 frequency is not tracking automaticly with SatPC32 wich is connected to DXLab commander as seen on the commander window.

73' Ron - on2ron

Re: A QSO in limbo ...

Mike Flowers
 

Thanks, Bill!

 

TQSL reported this QSO as having been previously uploaded.  However, it gave me the option to upload again if there had been a server error – which is what I expected had happened.   I did upload my ZD8SC QSO again and in due course it appeared in my LotW list Most Recent QSOs and was properly sync’d by DXKeeper.

 

It was good to learn that direct TQSL upload gives you the option of overriding the ‘previously uploaded’ notification and allows the upload.

 

- 73 and good DX de Mike, K6MKF, NCDXC Secretary

 

From: Mike Flowers <mike.flowers@...>
Sent: Tuesday, March 24, 2020 08:10
To: DXLab@groups.io
Subject: RE: [DXLab] A QSO in limbo ...

 

When using DXKeeper to upload to LotW via TSQL, it is reported as a dupe, so I suspect that a stand-alone effort will produce the same result, but worth a shot.

 

I’ll see what happens and let you know.

 

- 73 and good DX de Mike, K6MKF, NCDXC Secretary

 

From: DXLab@groups.io <DXLab@groups.io> On Behalf Of BILL KENNAMER
Sent: Tuesday, March 24, 2020 08:07
To: DXLab@groups.io
Subject: Re: [DXLab] A QSO in limbo ...

 

Export the QSO the a file. Then use TQSL to upload to LOTW. TQSL will tell you if it’s a dupe or not.

K5FUV 


Sent from Yahoo Mail for iPad

On Tuesday, March 24, 2020, 10:01 AM, Mike Flowers <mike.flowers@...> wrote:

Thanks, Dave.  I think the ARRL staff are all working from home at this
point so the help tickets are likely pilling up.

If there isn't a way to 'reset' this log entry, I'll simply create a new QSO
entry and upload that.

I'm interested in learning what state my current QSO record is in and how it
might be set so that it can be uploaded in LotW again.

- 73 and good DX de Mike, K6MKF, NCDXC Secretary

> -----Original Message-----
> From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Dave / NR1DX
> Sent: Tuesday, March 24, 2020 07:57
> To: DXLab@groups.io
> Subject: Re: [DXLab] A QSO in limbo ...
>
> I think I would start by making a "Help Ticket" to the  LOTW desk at ARRL
>
> http://www.arrl.org/lotw-help-ticket
>
> Tell them you uploaded a    QSO that is not in the LOTW log ( give them
the QSO
> details) and that your logging software wont let you do it again because
it thinks
> it went up. They may be able to manually load it?
>
> Dave
> NR1DX
>
>
>
> On 3/24/2020 9:48 AM, Mike Flowers wrote:
> >
> > Hi All,
> >
> > I have created a puzzlement for myself, and I’d like so guidance on
> > how to solve it.
> >
> > I logged ZD8SC last night on 20M FT8 and uploaded that log record to
> > LotW as the last one in a batch of logged QSOs.  I like to keep
> > current with LotW.  All processed normally.
> >
> > After a few minutes I checked to see if the latest batch of logged
> > QSOs had been updated in LotW and they appeared to have been. In
> > DXKeeper I performed ‘Sync LotW QSOs’, then ‘Sync LotW QSLs’.  All
> > seemed to go well.
> >
> > When I revisited LotW and looked at the results of the ‘Most Recent
> > QSOs’ I discovered that the ZD8SC QSO was not in the list. In DXKeeper
> > that log entry’s LotW Send = U, so DXKeeper marked it as uploaded.
> >
> > I thought I could fix this be simply editing the ZD8SC log entry to
> > LotW Send = R and uploading to LotW again.  But DXKeeper reports that
> > QSO is a dupe.
> >
> > LotW has been having some problems lately, so perhaps my ZD8SC QSO is
> > in some sort of processing limbo.
> >
> > I would appreciate some guidance on how to resolve my dilemma.
> >
> > Thanks!
> >
> > *- 73 and good DX de Mike, K6MKF <http://www.qrz.com/db/k6mkf/>, NCDXC
> > <https://www.ncdxc.org/> Secretary*
> >
> >
>
> --
> Dave
> Manuals@...
> www.ArtekManuals.com
>
>
> --
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
>