|
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.
toggle quoted messageShow quoted text
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.
|
|
|
|
Re: questions about DXV's accumalated files
bill <bill@...>
thanks Rich
toggle quoted messageShow quoted text
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 --
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.
toggle quoted messageShow quoted text
73, Rich - W3ZJ Gregg W6IZT wrote:
Is it possible to set up the origin filter by band?
|
|
|
|
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.
toggle quoted messageShow quoted text
73, Rich - W3ZJ bill wrote:
Reading the thread about DXView, I looked in my DXV directory.
|
|
|
|
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@...>
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.Were your 3V8 QSOs with a WPX prefix of 3V originally logged in DXKeeper, or imported from another application? 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: -----Original Message-----AA6YQ comments below
|
|
|
|
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
toggle quoted messageShow quoted text
-----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 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
On Thu, Jul 26, 2012 at 10:10 PM, Dave AA6YQ <aa6yq@ambersoft.com> wrote:
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
|
|
|
|
Re: CY9M -- error in database entry
Dave AA6YQ
*** AA6YQ comments below
toggle quoted messageShow quoted text
-----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: "accurate"-----Original Message-----AA6YQ comments below Why, though? I don't see the benefit of dropping extra information thatFN97we, trim to FN97, and approximate to FN97mm. Hmmm. Maybeit out by its own means... 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
On Thu, Jul 26, 2012 at 9:51 PM, Dave AA6YQ <aa6yq@ambersoft.com> wrote:
Why, though? I don't see the benefit of dropping extra information-----Original Message-----AA6YQ comments below 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
-----Original Message-----AA6YQ comments below 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: it out by its own means... butYeah, but still, we're starting with accurate information (in this case) and throwing it away for a less accurate approximation. to warrant adding a "this lat/lon is accurate enough for award tracking"It's unusually accurate. There are not enough tiny DXCC entities/regions 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"? SpotCollector. DXKeeper will log a 6-character grid square provided byDXKeeper won't log a 4-character grid square provided by DXView or SpotCollector -- e.g. one extracted from spot notes (if enabled). 73, Dave, AA6YQ
|
|
|
|
Re: CY9M -- error in database entry
On Thu, Jul 26, 2012 at 9:25 PM, Dave AA6YQ <aa6yq@ambersoft.com> wrote:
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
-----Original Message-----AA6YQ comments below 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? WPX prefix as 3V8.If you log a test QSO with 3V8DX, you'll see that DXKeeper computes the or imported from another application?Were your 3V8 QSOs with a WPX prefix of 3V originally logged in DXKeeper, 73, Dave, AA6YQ
|
|
|
|
Re: CY9M -- error in database entry
Dave AA6YQ
+++ AA6YQ comments below
toggle quoted messageShow quoted text
-----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: ... 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
-----Original Message-----AA6YQ comments below 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? 73,There's not, Chuck. 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
On Thu, Jul 26, 2012 at 6:55 PM, Dave AA6YQ <aa6yq@ambersoft.com> wrote:
... 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-----
|
|
|
|
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? 73 de Chuck, WS1L -- =================== Chuck Chandler chandlerusm@gmail.com ===================
|
|
|