There is an ongoing conversation on another reflector about 60 meter communication, including working DX. ? I noticed that 60 meters is absent from most of the band progress charts in DXLab applications. ? A shame that those charts could not be user modified. ?For example, in my case, I have no 2 meter equipment, so having 2 meters on a progress chart is wasted space. ? I would easily swap for a 60 meter space,
Don WB6BEE
|
Re: Commander Bandspread "tolerance"
On Tue, Mar 1, 2016 at 9:49 PM, ' Dave AA6YQ' aa6yq@... [dxlab] <dxlab@...> wrote:
+++ AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Tuesday, March 01, 2016 10:24 PM
To: dxlab
Subject: Re: [dxlab] Commander Bandspread "tolerance"
On Tue, Mar 1, 2016 at 6:30 PM, ' Dave AA6YQ' aa6yq@... [dxlab] <dxlab@...> wrote:
AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Tuesday, March 01, 2016 10:52 AM
To: dxlab@...
Subject: [dxlab] Commander Bandspread "tolerance"
This morning 3XY1T was calling CQ (split) just a hundred (if that) Hz or so below 24,890 for a while. Tuning to him - even when split with the TX VFO in the band - caused Commander to blank the bandspread and switch to the "out of band" color.
How did that impede your ability to work 3XY1T? Presumably you weren't interested in other 17m spots at that moment.
When working split, a considerate operator would try to be aware of other DX "up the band", and try to avoid transmitting over it.
+++ Right, but the considerate operator should do that by tuning up the band and listening, not by relying on cluster spots.
I may not be able to hear the other DX, though - depending on prop to my location. Just because I don't hear it doesn't mean I wouldn't be QRMing by transmitting on/near it. It might also be helpful when determining the spread of the target DX's pile (if there are multiple "clumps", some of them may be calling other DX).
+++ Callers in a pileup generally aren't spotted. No, but if you hear a clump of callers, and there's some juicy DX spotted below it, you can piece the picture together. It's all about being aware of your surroundings - like using your mirrors and your ears when driving. +++ That said, I don't see or recall any reason to hide spots when you tune out of the current band. I've sent you and Joe W4TV a version of Commander that no longer does that; please let me know how it goes... It "works as advertised" (from a quick check). I'll be on the lookout for anomalies... 73, ~iain / N6ML
|
Re: SpotCollector no JH2ZYY reports
AA6YQ comments below
-----Original Message----- From: dxlab@... [mailto:dxlab@...] Sent: Wednesday, March 02, 2016 1:10 AM To: dxlab@... Subject: [dxlab] SpotCollector no JH2ZYY reports Hi all, just wondering I dont ever seem to get any spots from the JH2ZYY site. I am connecting to it and its dialog box indicates a connection but its Spot Source Status light is Yellow. If the Spot Source Status "light" is yellow, that means SpotCollector hasn't seen a
VK4WTN de JH2ZYY prompt, and so does not consider you "connected" to JH2ZYY. Until you are connected, SpotCollector will ignore all spots from JH2ZYY. See the "Managing Spot Sources" section of
<> What host address and port are you using to connect to JH2ZYY?
73, Dave, AA6YQ
|
Re: A difficult request to clean up and old problem
### more AA6YQ comments below
toggle quoted message
Show quoted text
-----Original Message----- From: dxlab@... [mailto:dxlab@...] Sent: Wednesday, March 02, 2016 1:06 AM To: dxlab@... Subject: [dxlab] Re: A difficult request to clean up and old problem ---In dxlab@..., <aa6yq@...> wrote : snip< If you're not interested in the accuracy of logged primary and secondary administrative subdivisions, simply uncheck the "subdivision validity checking"
+++ Well that was easy enough! I don't remember that setting from when I set everything up 3 years ago (and if it was added in the interim I probably never even saw the release notes on it). Problem solved. ### That option has been present since 2008. 73, Dave, AA6YQ
|
Re: "Inbound OQRS" greyed out
AA6YQ comments below
-----Original Message----- From: dxlab@... [mailto:dxlab@...] Sent: Wednesday, March 02, 2016 1:00 AM To: dxlab@... Subject: [dxlab] Re: "Inbound OQRS" greyed out ---In dxlab@..., <aa6yq@...> wrote : DXKeeper cannot be configured to ignore "my QTHs": if you've made QSOs from different locations, they will be printed on separate labels sot that your location can be accurately specified in each case. Pasting multiple labels same card is certainly reasonable.
+++ Makes sense. Now since I use the rig modifier for my current MyQTH, will that work the same way? Yes.
I've got tens of thousands of QSOs from the MyQTH WestCaldwell:Mark V and now a few thousand as West Caldwell:Elecraft K3S. Since the vast majority of these are contest Qs, there's a very good chance I'll get many requests from stations for cards for both of these. Does the entire MyQTH string have to match or just the root portion of the MyQTH? The entire portion.
If I had 5 different radios here instead of one would each require its own label even though the QSOs were made at the same physical location with radios on the same desk and on the same antenna? Yes. Otherwise, you couldn't reliably include <rig> on a QSL card with multiple QSOs.
73, Dave, AA6YQ
|
SpotCollector no JH2ZYY reports
Hi all, just wondering I dont ever seem to get any spots from the JH2ZYY site. I am connecting to it and its dialog box indicates a connection but its Spot Source Status light is Yellow. Any ideas anyone regards Wayne VK4WTN
|
Re: A difficult request to clean up and old problem
---In dxlab@..., <aa6yq@...> wrote :
*** You can't recover split frequencies from the comments of logged QSOs unless you develop an application that does this.
+++ Unfortunate. Oh well, like I said, I'll probably never have to revisit these QSOs again so it's just my little OCD-addled brain that will even know.
>>>If you're not interested in the accuracy of logged primary and secondary administrative subdivisions, simply uncheck the "subdivision validity checking"
+++ Well that was easy enough! I don't remember that setting from when I set everything up 3 years ago (and if it was added in the interim I probably never even saw the release notes on it). Problem solved.
|
Re: "Inbound OQRS" greyed out
---In dxlab@..., <aa6yq@...> wrote : >>>DXKeeper cannot be configured to ignore "my QTHs": if you've made QSOs from different locations, they will be printed on separate labels sot that your location can be accurately specified in each case. Pasting multiple labels same card is certainly reasonable.
+++ Makes sense. Now since I use the rig modifier for my current MyQTH, will that work the same way? I've got tens of thousands of QSOs from the MyQTH WestCaldwell:Mark V and now a few thousand as West Caldwell:Elecraft K3S. Since the vast majority of these are contest Qs, there's a very good chance I'll get many requests from stations for cards for both of these. Does the entire MyQTH string have to match or just the root portion of the MyQTH? If I had 5 different radios here instead of one would each require its own label even though the QSOs were made at the same physical location with radios on the same desk and on the same antenna?
|
Re: Commander Bandspread "tolerance"
+++ AA6YQ comments below
toggle quoted message
Show quoted text
-----Original Message----- From: dxlab@... [mailto:dxlab@...] Sent: Tuesday, March 01, 2016 10:24 PM To: dxlab Subject: Re: [dxlab] Commander Bandspread "tolerance" On Tue, Mar 1, 2016 at 6:30 PM, ' Dave AA6YQ' aa6yq@... [dxlab] <dxlab@...> wrote:
AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Tuesday, March 01, 2016 10:52 AM
To: dxlab@...
Subject: [dxlab] Commander Bandspread "tolerance"
This morning 3XY1T was calling CQ (split) just a hundred (if that) Hz or so below 24,890 for a while. Tuning to him - even when split with the TX VFO in the band - caused Commander to blank the bandspread and switch to the "out of band" color.
How did that impede your ability to work 3XY1T? Presumably you weren't interested in other 17m spots at that moment.
When working split, a considerate operator would try to be aware of other DX "up the band", and try to avoid transmitting over it. +++ Right, but the considerate operator should do that by tuning up the band and listening, not by relying on cluster spots. It might also be helpful when determining the spread of the target DX's pile (if there are multiple "clumps", some of them may be calling other DX). +++ Callers in a pileup generally aren't spotted. +++ That said, I don't see or recall any reason to hide spots when you tune out of the current band. I've sent you and Joe W4TV a version of Commander that no longer does that; please let me know how it goes... 73, Dave, AA6YQ
|
AA6YQ comments below
-----Original Message----- From: dxlab@... [mailto:dxlab@...] Sent: Tuesday, March 01, 2016 10:33 PM To: dxlab@... Subject: [dxlab] Help with DXKeeper I opened a window by accident and now I can not find how to close it. The window consists of an icon (blue circle with white letter "i") followed by the current callsign and the word Progress. The window contains a chart showing the bands and modes that I have worked. Help! How do I turn off this window and keep it from reappearing? In the Options panel at the top of the Configuration window's General tab, uncheck the "Display callsign progress on Lookup" box.
If you have everything setup just the way you want it,
1. terminate all DXLab applications except the Launcher 2. direct the Launcher to create a Workspace 3. direct the Launcher to save all settings to that Workspace Then if you inadvertently change a setting and can't quickly determine how to restore it to your preferred value, you can direct the Launcher to load all settings from the Workspace you created.
<> 73, Dave, AA6YQ
|
Re: ClubLog Inbound OQRS and QSL_Rcvd
*** AA6YQ comments below
toggle quoted message
Show quoted text
-----Original Message----- From: dxlab@... [mailto:dxlab@...] Sent: Tuesday, March 01, 2016 11:22 PM To: dxlab@... Subject: [dxlab] Re: ClubLog Inbound OQRS and QSL_Rcvd ---In dxlab@..., <aa6yq@...> wrote :+++ +++ I thought it inappropriate to automatically consider every OQRS request as "un-needed", but I see now that the "QSL Configuration" window's "Inbound OQRS" panel needs a "never request confirmation" option whose setting is independently stored in each log. #### I agree, this is a needed option. I don't think many garden-variety stations will get many OQRS requests in the first place, so that leaves small and medium sized DXpeditions and 2nd and 3rd tier DX stations to really take adavntage of this addition of OQRS functionality (in addition to major DXpeditions, that is). There's no way someone in ZS or TF will want QSLs back from every single W2 and VE3 they work and who requests their card via OQRS. *** In the current version of DXKeeper, a card sent in response to an OQRS request would only include "please QSL" if confirmation of the QSO were "needed" for an award. A ZS or TF station using the current version of DXKeeper with OQRS enabled would see "please QSL" included on at most one outgoing K card/label and on at most one outgoing VE card/label. The proposed "never request confirmation" option, if enabled, would inhibit the inclusion of "please QSL" on those outgoing cards/labels. 73, Dave, AA6YQ
|
Re: ClubLog Inbound OQRS and QSL_Rcvd
---In dxlab@..., <aa6yq@...> wrote :+++
+++ I thought it inappropriate to automatically consider every OQRS request as "un-needed", but I see now that the "QSL Configuration" window's "Inbound OQRS" panel needs a "never request confirmation" option whose setting is independently stored in each log.
#### I agree, this is a needed option. I don't think many garden-variety stations will get many OQRS requests in the first place, so that leaves small and medium sized DXpeditions and 2nd and 3rd tier DX stations to really take adavntage of this addition of OQRS functionality (in addition to major DXpeditions, that is). There's no way someone in ZS or TF will want QSLs back from every single W2 and VE3 they work and who requests their card via OQRS.
|
I opened a window by accident and now I can not find how to close it. The window consists of an icon? (blue circle with white letter "i") followed by the current callsign and the word Progress.? The window? contains a chart showing the bands and modes that I have worked.
Help! How do I turn off this window and keep it from reappearing?
Thanks John VE1CDD
|
Re: Commander Bandspread "tolerance"
On Tue, Mar 1, 2016 at 6:30 PM, ' Dave AA6YQ' aa6yq@... [dxlab] <dxlab@...> wrote:
AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Tuesday, March 01, 2016 10:52 AM
To: dxlab@...
Subject: [dxlab] Commander Bandspread "tolerance"
This morning 3XY1T was calling CQ (split) just a hundred (if that) Hz or so below 24,890 for a while. Tuning to him - even when split with the TX VFO in the band - caused Commander to blank the bandspread and switch to the "out of band" color.
How did that impede your ability to work 3XY1T? Presumably you weren't interested in other 17m spots at that moment.
When working split, a considerate operator would try to be aware of other DX "up the band", and try to avoid transmitting over it. It might also be helpful when determining the spread of the target DX's pile (if there are multiple "clumps", some of them may be calling other DX). 73, ~iain / N6ML
|
Re: ClubLog Inbound OQRS and QSL_Rcvd
+++ AA6YQ comments below
toggle quoted message
Show quoted text
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Tuesday, March 01, 2016 9:59 PM
To: dxlab@...
Subject: RE: [dxlab] ClubLog Inbound OQRS and QSL_Rcvd
That is probably the case. How do I turn off DXCC tracking for my DXpedtion database without disabling it for my home database? When I turn it off under DXKeeper Configuration Awards tab it applies to everything.
+++ There is no way to disable award tracking for DXCC; unchecking all the boxes in the "DXCC Bands & Modes" panel means you are pursuing Mixed DXCC.
+++ I thought it inappropriate to automatically consider every OQRS request as "un-needed", but I see now that the "QSL Configuration" window's "Inbound OQRS" panel needs a "never request confirmation" option whose setting is independently stored in each log.
+++ Objections? Better ideas?
73,
Dave, AA6YQ
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Tuesday, March 01, 2016 11:25 AM
To: dxlab@...
Subject: RE: [dxlab] ClubLog Inbound OQRS and QSL_Rcvd
I don't have that box checked.
>>>If the "Outgoing QSLs request confirmation unless already confirmed" box is not checked and the QSO's "QSL Rcvd" item is empty, the remaining reason that an outgoing QSL label would be printed with "Pse!" in its QSL column is that a confirmation is needed for one of the awards you've configured DXKeeper to pursue.
>>>If the above explanation doesn't hold water, please place your log file in a zip archive, attach it to an email message that identifies the QSOs whose labels are incorrectly be printed with "Pse!" in the QSL column, and sent it to me via
aa6yq (at) ambersoft.com
73,
Dave, AA6YQ
|
Re: ClubLog Inbound OQRS and QSL_Rcvd
That is probably the case. How do I turn off DXCC tracking for my DXpedtion database without disabling it for my home database? When I turn it off under DXKeeper Configuration Awards tab it applies to everything.
toggle quoted message
Show quoted text
-----Original Message-----
From: dxlab@... [mailto: dxlab@...]
Sent: Tuesday, March 01, 2016 11:25 AM
To: dxlab@...
Subject: RE: [dxlab] ClubLog Inbound OQRS and QSL_Rcvd
I don't have that box checked.
>>>If the "Outgoing QSLs request confirmation unless already
confirmed" box is not checked and the QSO's "QSL Rcvd" item is empty,
the remaining reason that an outgoing QSL label would be printed with
"Pse!" in its QSL column is that a confirmation is needed for one of the
awards you've configured DXKeeper to pursue.
>>>If the above explanation doesn't hold water, please place
your log file in a zip archive, attach it to an email message that
identifies the QSOs whose labels are incorrectly be printed with "Pse!"
in the QSL column, and sent it to me via
aa6yq (at) ambersoft.com
73,
Dave, AA6YQ
|
Re: "Inbound OQRS" greyed out
AA6YQ comments below
-----Original Message----- From: dxlab@... [mailto:dxlab@...] Sent: Tuesday, March 01, 2016 8:20 PM To: dxlab@... Subject: [dxlab] Re: "Inbound OQRS" greyed out Getting there! Everything you mentioned worked well but I still don't have full understanding of how it handles a direct request. How does DX Keeper know whether the people requesting a card via OQRS have paid for a direct mail response or are just asking for a bureau card? Does DXK differentiate that when it downloads requests and imports that data? As is stated in
<> the "Inbound OQRS" function will "set the logged QSO's "QSL Sent Via" item to B (for bureau) or D (for direct) as indicated in the OQRS request". When your QSO partner makes an OQRS request, he or she specifies whether a direct or "free, via the buro" response is desired. And still one other very small problem. I have the "confirm multiple QSOs per QSL" set but there doesn't seem to be an override for different myQths. I made 3 QSOs with this test OQRS-request station, one from each of 3 different locations. Neither he nor I will really care where the Qs were made from, so long as they're from the same DXCC entity. They're even within the same circle for WAS eligibility. Is there any practical way around this or is it just easier to generate one label per QTH and stick 3 of them on the card instead of one multiple? DXKeeper cannot be configured to ignore "my QTHs": if you've made QSOs from different locations, they will be printed on separate labels sot that your location can be accurately specified in each case. Pasting multiple labels same card is certainly reasonable.
73, Dave, AA6YQ
|
Re: A difficult request to clean up and old problem
*** AA6YQ comments below
toggle quoted message
Show quoted text
-----Original Message----- From: dxlab@... [mailto:dxlab@...] Sent: Tuesday, March 01, 2016 8:00 PM To: dxlab@... Subject: RE: [dxlab] A difficult request to clean up and old problem ---In dxlab@..., <aa6yq@...> wrote : AA6YQ comments below
Try filtering the "Log Page Display" with the SQL expression
(Comment like '18*') or (Comment like '35*')or (Comment like '70*') or (Comment like '71*') or (Comment like '101*') or (Comment like '14*') or (Comment like '21*') or (Comment like '24*') or (Comment like '28*') >>>Does the Log Page Display contain all of your split QSOs and only your split QSOs? ++++It has identified about 2200 of them, but whether that's all or not, I'm not sure. But every single one of them appears to be an actual split QSO. Some of the comments contain comments in addition to the QSX, most do not. ("18090.87" or "28029.41 LongPath w/QRM", for example). >>>If so, you can use the "Modify QSOs" panel to copy each QSO's TX frequency to its RX frequency en masse. ++++ How would I do this? This would have to be a multi-step operation: 1. Convert each frequency from kHz to MHz. 3523.67 to 3.52367. Made trickier since some QSXs are 5.2 and others are 4.2 digits (in kHz). 2. Leave any text strings after the QSX in place 3. For all filtered records, move the contents of TX Freq to RX Freq. 4. Move the converted QSX values from comments to the TX Freq field. *** I suggested step 3 only. >>>You could also use the "Modify QSOs" panel to increase the TX frequency by, say, 1 Khz to flag the QSO as "split", but there's no way (short of extending DXKeeper) to extract the actual TX frequency from Comment item. ++++ While this would be possible it defeats the overall purpose of wanting as accurate a log as possible. Will I ever need to know the QSX from QSOs over 3 years ago? Probably not. But what of new convertees from DX Base with a boatload of split QSOs from the past year? Maybe it would help them at some point. *** As I said, I will extend DXKeeper to extract split frequencies from comments when importing a file exported from DXKeeper. If you have an ADIF file with split frequencies in comments, I'd appreciate your attaching it to an email message and sending it to me via aa6yq (at) ambersoft.com Is it even worth considering? >>>I'll extend DXKeeper to look for a TX frequency in the first word of a Comment when importing QSOs with the "ADIF Style Options" panel set to DXBase or DXBase5, but that won't help anyone who has already imported their QSOs into DXKeeper. ++++ That's cool. I don't mind doing a couple of hours of work if it's doable piecemeal with SQL expressions and/or formulae, but not one QSO at a time for 2197 Qs (and maybe more). *** You can't recover split frequencies from the comments of logged QSOs unless you develop an application that does this. <snip> >>>That's why DXKeeper is so anal about identifying and reporting inconsistencies: it is far easier to correct them when they are first created than years later after you've forgotten the context. ++++ I keep getting a bunch of errors, mostly from DX contacts, for invalid primary or secondary locations. Is this easily repairable? These pieces of information I'm not particularly interested in personally and if it would be easier to just remove the info rather than try to correct it that would suit me fine. I'm far more interested in correctly populating the Rig, Antenna, SFI, Ap and Kp fields for each QSO, whether imported or locally-generated, than I am trying to fix counties and oblasts, etc. *** You could filter the Log Page Display to contain only broken QSOs, and then direct DXKeeper to perform a "callbook lookup en masse, replacing existing information with callbook information", but I strongly recommend against doing so: the older the QSO, the less accurate the current callbook information. If you're not interested in the accuracy of logged primary and secondary administrative subdivisions, simply uncheck the "subdivision validity checking" box in the "Other Awards" panel on the Configuration window's Awards tab, and DXKeeper will stop reporting invalid or inconsistent subdivisions. 73, Dave, AA6YQ
|
Re: Commander Bandspread "tolerance"
AA6YQ comments below
-----Original Message----- From: dxlab@... [mailto:dxlab@...] Sent: Tuesday, March 01, 2016 10:52 AM To: dxlab@... Subject: [dxlab] Commander Bandspread "tolerance" This morning 3XY1T was calling CQ (split) just a hundred (if that) Hz or so below 24,890 for a while. Tuning to him - even when split with the TX VFO in the band - caused Commander to blank the bandspread and switch to the "out of band" color. How did that impede your ability to work 3XY1T? Presumably you weren't interested in other 17m spots at that moment.
73, Dave, AA6YQ
|
Re: Help---Flexradio 6700 talking to Commander
AA6YQ comments below
-----Original Message----- From: dxlab@... [mailto:dxlab@...] Sent: Tuesday, March 01, 2016 9:09 PM To: dxlab@... Subject: RE: [dxlab] Help---Flexradio 6700 talking to Commander Dave, thanks--I will try this and advise---I did print this out earlier--but was having difficulties executing. If you have questions about the instructions, don't hesitate to post them here. Besides helping you get going, the result may be improved instructions.
73, Dave, AA6YQ
|
wb6bee
iain macdonnell