Date   

Re: OT - Pseudo Batch Processing

Richard B Drake
 

You can still create and run .bat files. Yes, pathnames can get long but you only have to type them in once.

73, Rich - W3ZJ

Art wrote:

In the "good old days" one could emulate keystrokes in a simple batch (.bat) file. With today's long - sometimes very complex - file names, the old-style batch processing is very often not practical.

What can one use these days to simulate batch processing in a windows environment? I would like to have something free, but I'm not against paying for what might be needed.

I have some data files (unrelated to DXLab programs) I need to edit in a similar manner and the keystroke sequences are quite repetitive. And boring!

Art - N4PJ




Re: questions about DXV's accumalated files

bill <bill@...>
 

thanks Rich
I was pretty sure but figured better ask than weep!

On 7/27/12 6:49 AM, Rich - W3ZJ wrote:
Yes, it is safe to delete old versions of programs and data bases. You
might want to keep the last one or two just in case you need to revert
back for some reason. But, there is no reason to keep them for months.
You may want to check your DXKeeper log backups also. If you have
configured DXKeeper to automatically create a backup when you shut down
you may have a great many of those. However, as long as you are not
tight on space they don't hurt anything. If you configure your scheduled
backup to only copy new files (an incremental backup), those old files
will not be copied over again on every backup, thus will have little or
no impact on your backup time.

73, Rich - W3ZJ

bill wrote:
Reading the thread about DXView, I looked in my DXV directory.
I find numerous sequentially name files.
DXCC-2.3.4.htm to DXCC-2.4.2.htm

Similar situations for
DXCC234.mdb to DXCC242.mdb

many many sequential dated eQSLAG (date) files

many many sequential dated LoTW (date).mdb files

Similar with USAP (date) .mdb

I read through the DXV help files and did not see anything about
deleting these older versions.

While they don't take up 'all that much space', they do add to my
nightly backup time.
(I do multiple location backups each night)

Is is safe to delete older versions?

as always
Pse and TU

------------------------------------

Yahoo! Groups Links



--

A pack rat is hard to live with, but makes a fine ancestor.
---------------------------
W9OL-Bill H. in Chicagoland
webcams at http://w9ol-towercam.webhop.org:8080
My weatherpage at http://home.comcast.net/~w9ol/WX/HH.htm


Re: SC Origin Filter

Richard B Drake
 

Yes. Click the Band Filter, Enable Start/End & Max Origin DX Filtering, enable each band and fill in the information as desired. See the help file for information on filling in the start and end times with things like "SS-XXX and SR+XXX", offsets to sunset and sunrise.

73, Rich - W3ZJ

Gregg W6IZT wrote:

Is it possible to set up the origin filter by band?



73

Gregg

W6IZT


Re: questions about DXV's accumalated files

Richard B Drake
 

Yes, it is safe to delete old versions of programs and data bases. You might want to keep the last one or two just in case you need to revert back for some reason. But, there is no reason to keep them for months. You may want to check your DXKeeper log backups also. If you have configured DXKeeper to automatically create a backup when you shut down you may have a great many of those. However, as long as you are not tight on space they don't hurt anything. If you configure your scheduled backup to only copy new files (an incremental backup), those old files will not be copied over again on every backup, thus will have little or no impact on your backup time.

73, Rich - W3ZJ

bill wrote:

Reading the thread about DXView, I looked in my DXV directory.
I find numerous sequentially name files.
DXCC-2.3.4.htm to DXCC-2.4.2.htm

Similar situations for
DXCC234.mdb to DXCC242.mdb

many many sequential dated eQSLAG (date) files

many many sequential dated LoTW (date).mdb files

Similar with USAP (date) .mdb

I read through the DXV help files and did not see anything about
deleting these older versions.

While they don't take up 'all that much space', they do add to my
nightly backup time.
(I do multiple location backups each night)

Is is safe to delete older versions?

as always
Pse and TU


OT - Pseudo Batch Processing

aburkefl
 

In the "good old days" one could emulate keystrokes in a simple batch (.bat) file. With today's long - sometimes very complex - file names, the old-style batch processing is very often not practical.

What can one use these days to simulate batch processing in a windows environment? I would like to have something free, but I'm not against paying for what might be needed.

I have some data files (unrelated to DXLab programs) I need to edit in a similar manner and the keystroke sequences are quite repetitive. And boring!

Art - N4PJ


SC Origin Filter

Gregg W6IZT <w6izt1@...>
 

Is it possible to set up the origin filter by band?



73

Gregg

W6IZT


Re: WPX & LoTW - Reconciling Differences

David <david_yahoo@...>
 

Were your 3V8 QSOs with a WPX prefix of 3V originally logged in DXKeeper, or imported from another application?
Very few of my contacts are logged directly in DXKeeper. Many were imported originally from HRD and even after I switched to DXKeeper most contacts are imported via N1MM from contesting.

When I look at all 3V8* contacts, I see they are all tagged with a contest so they are all imported from HRD or N1MM. The Recompute function on the Check Progress tab has been run many, many times and definitely after any 3V8 contact was in DXKeeper's log. I just ran Recompute again and then clicked the Progress button for WPX and didn't notice any change.

Here's the top snippet of the DXKeeper WPX Progress Report followed by the LoTW info:

DXKeeper:
1 2I confirmed
2 3G confirmed
3 3V confirmed
4 3V8 confirmed
5 3XY confirmed
6 4A confirmed
7 4B confirmed


LoTW:
Entity WPX Mixed
2I0 2I0SAI
3G3 3G3V
3V8 3V8SS
3XY1 3XY1D
4A1 4A1DXXE
4A2 4A2S
4A4 4A4A
4B1 4B1GZU
4B2 4B2S

Am I not comparing apples to apples?

David - K2DSL

--- In dxlab@yahoogroups.com, "Dave AA6YQ" <aa6yq@...> wrote:

AA6YQ comments below
-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com] On Behalf Of
David
Sent: Thursday, July 26, 2012 7:32 PM
To: dxlab@yahoogroups.com
Subject: [dxlab] WPX & LoTW - Reconciling Differences

LoTW's Award tab shows 1451 WPX prefixes DXKeeper WPX progress report shows
1434 LoTW confirmed prefixes

I'm trying to reconcile the difference. I did a DXK filter where
APP_DXKeeper_LotW_QSL_RCVD<>'R' and re-ran the WPX report so everything
shown in the report must be associated with a LoTW confirmation. Some might
also be QSL or eQSL confirmations, but the list is all LoTW based on the
filter.

I didn't get far and I see LoTW's award report showing just 3V8 and DXK
shows 3V and 3V8. I then filtered my log just on calls starting with 3V* and
though I have more prefixes then 3V8, only 3V8 is actually confirmed in
LoTW. Why would both 3V and 3V8 showing in the DXK WPX report?

If you log a test QSO with 3V8DX, you'll see that DXKeeper computes the
WPX prefix as 3V8.

Were your 3V8 QSOs with a WPX prefix of 3V originally logged in DXKeeper,
or imported from another application?

73,

Dave, AA6YQ


questions about DXV's accumalated files

bill <bill@...>
 

Reading the thread about DXView, I looked in my DXV directory.
I find numerous sequentially name files.
DXCC-2.3.4.htm to DXCC-2.4.2.htm

Similar situations for
DXCC234.mdb to DXCC242.mdb

many many sequential dated eQSLAG (date) files

many many sequential dated LoTW (date).mdb files

Similar with USAP (date) .mdb

I read through the DXV help files and did not see anything about
deleting these older versions.

While they don't take up 'all that much space', they do add to my
nightly backup time.
(I do multiple location backups each night)

Is is safe to delete older versions?

as always
Pse and TU

--

A sleeping bag is a tortilla for a human. -Mitch Hedberg
---------------------------
W9OL-Bill H. in Chicagoland
webcams at http://w9ol-towercam.webhop.org:8080
My weatherpage at http://home.comcast.net/~w9ol/WX/HH.htm


Re: CY9M -- error in database entry

Dave AA6YQ
 

### more AA6YQ comments below

-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com] On Behalf Of iain
macdonnell - N6ML
Sent: Thursday, July 26, 2012 10:43 PM
To: dxlab@yahoogroups.com
Subject: Re: [dxlab] CY9M -- error in database entry

snip<
BTW, what's the rationale for trimming the last two "digits" from
the grid when you consider it "not accurate enough for award tracking"?
DXKeeper won't log a 4-character grid square provided by DXView
or
SpotCollector. DXKeeper will log a 6-character grid square provided
by SpotCollector -- e.g. one extracted from spot notes (if enabled).

Why, though? I don't see the benefit of dropping extra information
that might be helpful if it's accurate, yet is harmless if it's not
accurate...

*** It's not harmless to mislead a user into thinking that he or she
has a confirmed QSO with CM87 when that grid square is in fact an
approximate location that might actually be CM88, CM78, or CM77.

OK, I must have misunderstood. I thought you said that FN97we was trimmed to
FN97 because it was considered "not accurate enough", which I couldn't make
sense of.

### When SpotCollector computes a grid square from a latitude and longitude
supplied by the DXCC database, only the first four characters of that
computed grid square are stored in the Spot Database Entry's "DX Grid"
column. If the user double-clicks a Spot Database Entry whose "DX Grid"
contains a four character grid square, DXKeeper's Capture window (or
WinWarbler's "QSO Info" panel) is not populated with a grid square --
because one of sufficient accuracy is not available.

So, I still don't know how we ended up with FN97 in the Spot Database... ???

### FN97 are the first four characters of FN97we, the grid square computed
from the latitude and longitude specified in the DXCC Database entry for St.
Paul Island.

73,

Dave, AA6YQ


Re: CY9M -- error in database entry

iain macdonnell - N6ML
 

On Thu, Jul 26, 2012 at 10:10 PM, Dave AA6YQ <aa6yq@ambersoft.com> wrote:



*** AA6YQ comments below



-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com] On Behalf Of
iain
macdonnell - N6ML
Sent: Thursday, July 26, 2012 10:01 PM
To: dxlab@yahoogroups.com
Subject: Re: [dxlab] CY9M -- error in database entry

On Thu, Jul 26, 2012 at 9:51 PM, Dave AA6YQ <aa6yq@ambersoft.com> wrote:



AA6YQ comments below
-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com] On Behalf
Of iain macdonnell - N6ML
Sent: Thursday, July 26, 2012 9:41 PM
To: dxlab@yahoogroups.com
Subject: Re: [dxlab] CY9M -- error in database entry

On Thu, Jul 26, 2012 at 9:25 PM, Dave AA6YQ <aa6yq@ambersoft.com> wrote:



+++ AA6YQ comments below



-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com] On Behalf
Of iain macdonnell - N6ML
Sent: Thursday, July 26, 2012 7:07 PM
To: dxlab@yahoogroups.com
Subject: Re: [dxlab] CY9M -- error in database entry

On Thu, Jul 26, 2012 at 6:55 PM, Dave AA6YQ <aa6yq@ambersoft.com>
wrote:



My response below is incorrect.

If SpotCollector is configured to "lookup missing location info",
it performs a DXCC Database lookup of CY9M, which produces a grid
square of FN97we. However, since this is a DXCC database lookup,
the grid square is trimmed to 4 characters to convey "not accurate
enough for award tracking".
Spot Database Entry's "DX Grid" column is set to FN97, and the
azimuth is computed based on that grid square.
... and then it passes that back to DXView, which replaces its
initial location with the center of the grid? So we start with
"accurate"
FN97we, trim to FN97, and approximate to FN97mm. Hmmm. Maybe
SpotCollector should refrain from sending the grid info (back) to
DXView when it's considered "not accurate enough", and let DXView
figure
it out by its own means...
but
I suppose there's nothing in a Spot DB entry that denotes where the
grid square data came from.....

+++ As a DXCC entity, St. Paul Island is so small that a "center of
+++ the
entity" location is likely accurate. This is not typical.
Yeah, but still, we're starting with accurate information (in this
case) and throwing it away for a less accurate approximation.

It's unusually accurate. There are not enough tiny DXCC
entities/regions
to warrant adding a "this lat/lon is accurate enough for award tracking"
flag to each location entry in the DXCC Database.


BTW, what's the rationale for trimming the last two "digits" from the
grid when you consider it "not accurate enough for award tracking"?

DXKeeper won't log a 4-character grid square provided by DXView or
SpotCollector. DXKeeper will log a 6-character grid square provided by
SpotCollector -- e.g. one extracted from spot notes (if enabled).
Why, though? I don't see the benefit of dropping extra information that
might be helpful if it's accurate, yet is harmless if it's not accurate...

*** It's not harmless to mislead a user into thinking that he or she has a
confirmed QSO with CM87 when that grid square is in fact an approximate
location that might actually be CM88, CM78, or CM77.
OK, I must have misunderstood. I thought you said that FN97we was
trimmed to FN97 because it was considered "not accurate enough", which
I couldn't make sense of.

So, I still don't know how we ended up with FN97 in the Spot Database... ???

73,

~iain / N6ML



*** There are only three sources of location information that are accurate
enough for award tracking:

1. what your QSO partner tells you over the air

2. the results of a callbook lookup where the callbook information was
populated by your QSO partner

3. a grid square included in spot notes (presumably obtained over the air)

#3 is questionable, which is why SpotCollector provides an option to
enable/disable its usage.

*** A grid square should not be logged with a QSO unless it was sourced
via
one of these three ways.

73,

Dave, AA6YQ


Re: CY9M -- error in database entry

Dave AA6YQ
 

*** AA6YQ comments below

-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com] On Behalf Of iain
macdonnell - N6ML
Sent: Thursday, July 26, 2012 10:01 PM
To: dxlab@yahoogroups.com
Subject: Re: [dxlab] CY9M -- error in database entry

On Thu, Jul 26, 2012 at 9:51 PM, Dave AA6YQ <aa6yq@ambersoft.com> wrote:



AA6YQ comments below
-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com] On Behalf
Of iain macdonnell - N6ML
Sent: Thursday, July 26, 2012 9:41 PM
To: dxlab@yahoogroups.com
Subject: Re: [dxlab] CY9M -- error in database entry

On Thu, Jul 26, 2012 at 9:25 PM, Dave AA6YQ <aa6yq@ambersoft.com> wrote:



+++ AA6YQ comments below



-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com] On Behalf
Of iain macdonnell - N6ML
Sent: Thursday, July 26, 2012 7:07 PM
To: dxlab@yahoogroups.com
Subject: Re: [dxlab] CY9M -- error in database entry

On Thu, Jul 26, 2012 at 6:55 PM, Dave AA6YQ <aa6yq@ambersoft.com> wrote:



My response below is incorrect.

If SpotCollector is configured to "lookup missing location info",
it performs a DXCC Database lookup of CY9M, which produces a grid
square of FN97we. However, since this is a DXCC database lookup,
the grid square is trimmed to 4 characters to convey "not accurate
enough for award tracking".
Spot Database Entry's "DX Grid" column is set to FN97, and the
azimuth is computed based on that grid square.
... and then it passes that back to DXView, which replaces its
initial location with the center of the grid? So we start with
"accurate"
FN97we, trim to FN97, and approximate to FN97mm. Hmmm. Maybe
SpotCollector should refrain from sending the grid info (back) to
DXView when it's considered "not accurate enough", and let DXView
figure
it out by its own means...
but
I suppose there's nothing in a Spot DB entry that denotes where the
grid square data came from.....

+++ As a DXCC entity, St. Paul Island is so small that a "center of
+++ the
entity" location is likely accurate. This is not typical.
Yeah, but still, we're starting with accurate information (in this
case) and throwing it away for a less accurate approximation.

It's unusually accurate. There are not enough tiny DXCC
entities/regions
to warrant adding a "this lat/lon is accurate enough for award tracking"
flag to each location entry in the DXCC Database.


BTW, what's the rationale for trimming the last two "digits" from the
grid when you consider it "not accurate enough for award tracking"?

DXKeeper won't log a 4-character grid square provided by DXView or
SpotCollector. DXKeeper will log a 6-character grid square provided by
SpotCollector -- e.g. one extracted from spot notes (if enabled).
Why, though? I don't see the benefit of dropping extra information that
might be helpful if it's accurate, yet is harmless if it's not accurate...

*** It's not harmless to mislead a user into thinking that he or she has a
confirmed QSO with CM87 when that grid square is in fact an approximate
location that might actually be CM88, CM78, or CM77.

*** There are only three sources of location information that are accurate
enough for award tracking:

1. what your QSO partner tells you over the air

2. the results of a callbook lookup where the callbook information was
populated by your QSO partner

3. a grid square included in spot notes (presumably obtained over the air)

#3 is questionable, which is why SpotCollector provides an option to
enable/disable its usage.

*** A grid square should not be logged with a QSO unless it was sourced via
one of these three ways.

73,

Dave, AA6YQ


Re: CY9M -- error in database entry

iain macdonnell - N6ML
 

On Thu, Jul 26, 2012 at 9:51 PM, Dave AA6YQ <aa6yq@ambersoft.com> wrote:



AA6YQ comments below
-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com] On Behalf Of
iain
macdonnell - N6ML
Sent: Thursday, July 26, 2012 9:41 PM
To: dxlab@yahoogroups.com
Subject: Re: [dxlab] CY9M -- error in database entry

On Thu, Jul 26, 2012 at 9:25 PM, Dave AA6YQ <aa6yq@ambersoft.com> wrote:



+++ AA6YQ comments below



-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com] On Behalf
Of iain macdonnell - N6ML
Sent: Thursday, July 26, 2012 7:07 PM
To: dxlab@yahoogroups.com
Subject: Re: [dxlab] CY9M -- error in database entry

On Thu, Jul 26, 2012 at 6:55 PM, Dave AA6YQ <aa6yq@ambersoft.com> wrote:



My response below is incorrect.

If SpotCollector is configured to "lookup missing location info", it
performs a DXCC Database lookup of CY9M, which produces a grid
square of FN97we. However, since this is a DXCC database lookup, the
grid square is trimmed to 4 characters to convey "not accurate
enough for award tracking".
Spot Database Entry's "DX Grid" column is set to FN97, and the
azimuth is computed based on that grid square.
... and then it passes that back to DXView, which replaces its initial
location with the center of the grid? So we start with "accurate"
FN97we, trim to FN97, and approximate to FN97mm. Hmmm. Maybe
SpotCollector should refrain from sending the grid info (back) to
DXView when it's considered "not accurate enough", and let DXView figure
it out by its own means...
but
I suppose there's nothing in a Spot DB entry that denotes where the
grid square data came from.....

+++ As a DXCC entity, St. Paul Island is so small that a "center of
+++ the
entity" location is likely accurate. This is not typical.
Yeah, but still, we're starting with accurate information (in this case)
and
throwing it away for a less accurate approximation.

It's unusually accurate. There are not enough tiny DXCC
entities/regions
to warrant adding a "this lat/lon is accurate enough for award tracking"
flag to each location entry in the DXCC Database.


BTW, what's the rationale for trimming the last two "digits" from the grid
when you consider it "not accurate enough for award tracking"?

DXKeeper won't log a 4-character grid square provided by DXView or
SpotCollector. DXKeeper will log a 6-character grid square provided by
SpotCollector -- e.g. one extracted from spot notes (if enabled).
Why, though? I don't see the benefit of dropping extra information
that might be helpful if it's accurate, yet is harmless if it's not
accurate...

73,

~iain / N6ML


Re: CY9M -- error in database entry

Dave AA6YQ
 

AA6YQ comments below
-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com] On Behalf Of iain
macdonnell - N6ML
Sent: Thursday, July 26, 2012 9:41 PM
To: dxlab@yahoogroups.com
Subject: Re: [dxlab] CY9M -- error in database entry

On Thu, Jul 26, 2012 at 9:25 PM, Dave AA6YQ <aa6yq@ambersoft.com> wrote:



+++ AA6YQ comments below



-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com] On Behalf
Of iain macdonnell - N6ML
Sent: Thursday, July 26, 2012 7:07 PM
To: dxlab@yahoogroups.com
Subject: Re: [dxlab] CY9M -- error in database entry

On Thu, Jul 26, 2012 at 6:55 PM, Dave AA6YQ <aa6yq@ambersoft.com> wrote:



My response below is incorrect.

If SpotCollector is configured to "lookup missing location info", it
performs a DXCC Database lookup of CY9M, which produces a grid
square of FN97we. However, since this is a DXCC database lookup, the
grid square is trimmed to 4 characters to convey "not accurate
enough for award tracking".
Spot Database Entry's "DX Grid" column is set to FN97, and the
azimuth is computed based on that grid square.
... and then it passes that back to DXView, which replaces its initial
location with the center of the grid? So we start with "accurate"
FN97we, trim to FN97, and approximate to FN97mm. Hmmm. Maybe
SpotCollector should refrain from sending the grid info (back) to
DXView when it's considered "not accurate enough", and let DXView figure
it out by its own means...
but
I suppose there's nothing in a Spot DB entry that denotes where the
grid square data came from.....

+++ As a DXCC entity, St. Paul Island is so small that a "center of
+++ the
entity" location is likely accurate. This is not typical.
Yeah, but still, we're starting with accurate information (in this case) and
throwing it away for a less accurate approximation.

It's unusually accurate. There are not enough tiny DXCC entities/regions
to warrant adding a "this lat/lon is accurate enough for award tracking"
flag to each location entry in the DXCC Database.

BTW, what's the rationale for trimming the last two "digits" from the grid
when you consider it "not accurate enough for award tracking"?

DXKeeper won't log a 4-character grid square provided by DXView or
SpotCollector. DXKeeper will log a 6-character grid square provided by
SpotCollector -- e.g. one extracted from spot notes (if enabled).

73,

Dave, AA6YQ


Re: CY9M -- error in database entry

iain macdonnell - N6ML
 

On Thu, Jul 26, 2012 at 9:25 PM, Dave AA6YQ <aa6yq@ambersoft.com> wrote:



+++ AA6YQ comments below



-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com] On Behalf Of
iain
macdonnell - N6ML
Sent: Thursday, July 26, 2012 7:07 PM
To: dxlab@yahoogroups.com
Subject: Re: [dxlab] CY9M -- error in database entry

On Thu, Jul 26, 2012 at 6:55 PM, Dave AA6YQ <aa6yq@ambersoft.com> wrote:



My response below is incorrect.

If SpotCollector is configured to "lookup missing location info", it
performs a DXCC Database lookup of CY9M, which produces a grid square
of FN97we. However, since this is a DXCC database lookup, the grid
square is trimmed to 4 characters to convey "not accurate enough for
award tracking".
Spot Database Entry's "DX Grid" column is set to FN97, and the azimuth
is computed based on that grid square.
... and then it passes that back to DXView, which replaces its initial
location with the center of the grid? So we start with "accurate" FN97we,
trim to FN97, and approximate to FN97mm. Hmmm. Maybe SpotCollector should
refrain from sending the grid info (back) to DXView when it's considered
"not accurate enough", and let DXView figure it out by its own means...
but
I suppose there's nothing in a Spot DB entry that denotes where the grid
square data came from.....

+++ As a DXCC entity, St. Paul Island is so small that a "center of the
entity" location is likely accurate. This is not typical.
Yeah, but still, we're starting with accurate information (in this
case) and throwing it away for a less accurate approximation.

BTW, what's the rationale for trimming the last two "digits" from the
grid when you consider it "not accurate enough for award tracking"? It
seems that the trimming is unlikely to make it any less inaccurate.
Are there any (important) awards that consider the 6-digit grid?

73,

~iain / N6ML


Re: WPX & LoTW - Reconciling Differences

Dave AA6YQ
 

AA6YQ comments below
-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com] On Behalf Of
David
Sent: Thursday, July 26, 2012 7:32 PM
To: dxlab@yahoogroups.com
Subject: [dxlab] WPX & LoTW - Reconciling Differences

LoTW's Award tab shows 1451 WPX prefixes DXKeeper WPX progress report shows
1434 LoTW confirmed prefixes

I'm trying to reconcile the difference. I did a DXK filter where
APP_DXKeeper_LotW_QSL_RCVD<>'R' and re-ran the WPX report so everything
shown in the report must be associated with a LoTW confirmation. Some might
also be QSL or eQSL confirmations, but the list is all LoTW based on the
filter.

I didn't get far and I see LoTW's award report showing just 3V8 and DXK
shows 3V and 3V8. I then filtered my log just on calls starting with 3V* and
though I have more prefixes then 3V8, only 3V8 is actually confirmed in
LoTW. Why would both 3V and 3V8 showing in the DXK WPX report?

If you log a test QSO with 3V8DX, you'll see that DXKeeper computes the
WPX prefix as 3V8.

Were your 3V8 QSOs with a WPX prefix of 3V originally logged in DXKeeper,
or imported from another application?

73,

Dave, AA6YQ


Re: CY9M -- error in database entry

Dave AA6YQ
 

+++ AA6YQ comments below

-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com] On Behalf Of iain
macdonnell - N6ML
Sent: Thursday, July 26, 2012 7:07 PM
To: dxlab@yahoogroups.com
Subject: Re: [dxlab] CY9M -- error in database entry

On Thu, Jul 26, 2012 at 6:55 PM, Dave AA6YQ <aa6yq@ambersoft.com> wrote:



My response below is incorrect.

If SpotCollector is configured to "lookup missing location info", it
performs a DXCC Database lookup of CY9M, which produces a grid square
of FN97we. However, since this is a DXCC database lookup, the grid
square is trimmed to 4 characters to convey "not accurate enough for
award tracking".
Spot Database Entry's "DX Grid" column is set to FN97, and the azimuth
is computed based on that grid square.
... and then it passes that back to DXView, which replaces its initial
location with the center of the grid? So we start with "accurate" FN97we,
trim to FN97, and approximate to FN97mm. Hmmm. Maybe SpotCollector should
refrain from sending the grid info (back) to DXView when it's considered
"not accurate enough", and let DXView figure it out by its own means... but
I suppose there's nothing in a Spot DB entry that denotes where the grid
square data came from.....

+++ As a DXCC entity, St. Paul Island is so small that a "center of the
entity" location is likely accurate. This is not typical.

73,

Dave, AA6YQ


Re: QS

Dave AA6YQ
 

AA6YQ comments below
-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com] On Behalf Of
Chuck Chandler
Sent: Thursday, July 26, 2012 7:06 PM
To: dxlab@yahoogroups.com
Subject: [dxlab] QS

I read the recent thread about over-writing QSO-entered data with callbook
data with interest... in th epast, if I mis-copied a call, then I woul dhave
to clear the capture window and start over, since I was set to
"Automatically use callbook data to initialize new QSOs."

By clearing that checkbox I now can enter data from my QSO partner, even
change a mis-copied call, then at the end of the QSO click the Lookup button
to fill in the missing pieces and ensure I have an address on file if
needed. That part works as expected, and is, for me a better way to work.

With that, though, I wanted to be able to lookup prior QSOs as well as QSO
data, so I checked the box "Display Previous QSOs on Lookup." The tooltip
says "when checked, the clicking the Lookup button displays previous QSOs
and the information found in previous QSOs is used to initialize the new
QSO's items"

What I find is that double-clicking a SC spot populates the Capture window
and filters the log to display prior QSOs, without my clicking the Lookup
button. It also shows prior QSOs in the Capture window, if any.

Is there a way to make the Capture window only Lookup when the Lookup button
is clicked under these conditions?

There's not, Chuck.
73,

Dave, AA6YQ


WPX & LoTW - Reconciling Differences

David <david_yahoo@...>
 

LoTW's Award tab shows 1451 WPX prefixes
DXKeeper WPX progress report shows 1434 LoTW confirmed prefixes

I'm trying to reconcile the difference. I did a DXK filter where APP_DXKeeper_LotW_QSL_RCVD<>'R' and re-ran the WPX report so everything shown in the report must be associated with a LoTW confirmation. Some might also be QSL or eQSL confirmations, but the list is all LoTW based on the filter.

I didn't get far and I see LoTW's award report showing just 3V8 and DXK shows 3V and 3V8. I then filtered my log just on calls starting with 3V* and though I have more prefixes then 3V8, only 3V8 is actually confirmed in LoTW. Why would both 3V and 3V8 showing in the DXK WPX report?

Next, LoTW lists 4A1, 4A2 & 4A4 while DXK lists just 4A in its report. 4A1, 4A2 & 4A4 show in DXK as confirmed on LoTW.

There are many more examples of differences I see between what LoTW's Award tab shows and what the DXK WPX Progress list shows when the log is filtered on APP_DXKeeper_LotW_QSL_RCVD<>'R'. The above 2 differences represent where LoTW shows less prefixes than DXK and the other is where LoTW shows more prefixes than DXK.

Is this some configuration option I need to adjust? An issue with either in how they calculate? I'm just not comparing things correctly?

Any guidance is appreciated.

73 - K2DSL - David


Re: CY9M -- error in database entry

iain macdonnell - N6ML
 

On Thu, Jul 26, 2012 at 6:55 PM, Dave AA6YQ <aa6yq@ambersoft.com> wrote:



My response below is incorrect.

If SpotCollector is configured to "lookup missing location info", it
performs a DXCC Database lookup of CY9M, which produces a grid square of
FN97we. However, since this is a DXCC database lookup, the grid square is
trimmed to 4 characters to convey "not accurate enough for award
tracking".
Spot Database Entry's "DX Grid" column is set to FN97, and the azimuth is
computed based on that grid square.
... and then it passes that back to DXView, which replaces its initial
location with the center of the grid? So we start with "accurate"
FN97we, trim to FN97, and approximate to FN97mm. Hmmm. Maybe
SpotCollector should refrain from sending the grid info (back) to
DXView when it's considered "not accurate enough", and let DXView
figure it out by its own means... but I suppose there's nothing in a
Spot DB entry that denotes where the grid square data came from.....

~iain / N6ML





-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com] On Behalf Of
Dave
AA6YQ
Sent: Thursday, July 26, 2012 6:34 PM
To: dxlab@yahoogroups.com
Subject: RE: [dxlab] CY9M -- error in database entry

AA6YQ comments below
-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com] On Behalf Of
Joe
Subich, W4TV
Sent: Thursday, July 26, 2012 6:21 PM
To: dxlab@yahoogroups.com
Subject: Re: [dxlab] CY9M -- error in database entry

DXV has to be getting the incorrect lat & long from somewhere, but >
where???

SpotCollector is sending it only FK97 which DXV interprets as the Center
of
the 2 x 1 box (e.g., FK97mm) rather than the more accurate data in the
DXCC
database.

Fortunately, the inaccuracy is only a problem for those relatively close
and
north or south of CY9 (e.g., eastern VE1, eastern VE2 and VO2)

and can be eliminated by unchecking "Capture location info from
notes" on
the Configuration window's General tab.

73,

Dave, AA6YQ

------------------------------------

Yahoo! Groups Links


QS

Chuck, WS1L
 

I read the recent thread about over-writing QSO-entered data with callbook
data with interest... in th epast, if I mis-copied a call, then I woul
dhave to clear the capture window and start over, since I was set to
"Automatically use callbook data to initialize new QSOs."

By clearing that checkbox I now can enter data from my QSO partner, even
change a mis-copied call, then at the end of the QSO click the Lookup
button to fill in the missing pieces and ensure I have an address on file
if needed. That part works as expected, and is, for me a better way to
work.

With that, though, I wanted to be able to lookup prior QSOs as well as QSO
data, so I checked the box "Display Previous QSOs on Lookup." The tooltip
says "when checked, the clicking the Lookup button displays previous QSOs
and the information found in previous QSOs is used to initialize the new
QSO's items"

What I find is that double-clicking a SC spot populates the Capture window
and filters the log to display prior QSOs, without my clicking the Lookup
button. It also shows prior QSOs in the Capture window, if any.

Is there a way to make the Capture window only Lookup when the Lookup
button is clicked under these conditions?

73 de Chuck, WS1L

--


===================
Chuck Chandler
chandlerusm@gmail.com
===================

99341 - 99360 of 208168