¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
Date

Re: DXView's ""Populate override content from entity"

 

+ AA6YQ comments below

Although I understand what you are saying I struggle with the logic.

If I enter a random Swedish call in DXView, I get the grid locator of central Stockholm which of course is very wrong for e.g. my call. But close enough for all practical purposes (beam heading, sun info, spot plot) except of course VUCC. I believe everyone prefers this before getting an empty grid.

+ Correct.

If I enter a callsign which is in the override list and the override lacks a grid. I get an empty grid.
What is wrong with using the DXCC database lookup grid when the override lacks a grid, just as with random calls? Why is this a bad idea?

+ The long-standing description of an override's Grid field, dating back to the days of 16 fixed overrides, is

"the Maidenhead Grid Square from which the station is operating"

<>


+ Each Spot Database Entry contains a DXGridSource field that contains one of the following values

L - the gridsquare associated with the Latitude and Longitude specified in the Operator location panel
O - the gridsquare specified by an Override
S - a gridsquare extracted from a spot note or information appended to the spot by a Spot Source
U - the gridsquare determined by a USAP Database lookup
D - the gridsquare determined by a DXCC Database lookup

<>

+ Originally, a Spot Database Entry's "Grid Square" field was only considered valid for VUCC if the Entry's DXGridSource contained the letters L, O, or S.

+ At some point in the past, discussion here led me provide user control of this by adding the "Grid Sources for VUCC" panel to the General tab of SpotCollector's Configuration window. This panel provides you with the ability to determine whether Spot Database Entries whose DXGridSource fields contain O, S, or U should be considered reliable enough for VUCC need determination.

+ Note that these options are "all or nothing": if you uncheck the L box in the "Grid Sources for VUCC" panel because some of your overrides specify inaccurate grid squares, then all grid squares specified in Overrides will be ignored for VUCC need determination.

+ If you're pursuing VUCC, then each override of a station QRV on VHF or UHF should specify an accurate grid square so you can keep the "Grid Sources for VUCC" panel's Override box checked.

+ If you're not pursuing VUCC then you can uncheck the "Grid Sources for VUCC" panel's Override box; in this case, there's no reason to not populate an Override's grid square with an approximate location.

73,

Dave, AA6YQ


Re: -@ in spot collector

 

+ AA6YQ comments below

Can you do a global exclusion for all -@ calls like you do for -#?

+ What's the rationale for ignoring spots from DX Summit?

+ Skimmers generate spots in high volume; that's why the option to ignore them was provided.

73,

Dave, AA6YQ


Re: -@ in spot collector

 

* more AA6YQ comments below

The question was about the '-@' suffix, not '-#', though. The former is appended by DX Summit, on spots submitted through their web interface, from what I understand.

* Thanks for the correction, Iain!

73,

Dave, AA6YQ


Re: DXView's ""Populate override content from entity"

 

On 2020-02-26 6:52 PM, Bj?rn Ekelund, SM7IUN wrote:

I'm not so well versed in the CTY terminology.
There are no grids in AD1C's CTY files and DXKeeper does not use
them unless one chooses to import the Big CTY file to populate the
override list.

With the "default grid" I mean the reference grid that pops up when
you enter a random call in DXView.
AA6YQ and/or I supplied a reference grid for each list entry (DXCC
entity, state, oblast, certain call areas, etc,.) specifically for
DXView to use in calculating *BEAM HEADINGS* and nothing else.

If one is entering an override, the "reference" in the DXCC database
is obviously invalid. It logically follows that anyone who creates
an override is expected to provide their own grid square information
along with any other information (e.g., IOTA reference) that is
important to them.

73,

... Joe, W4TV


On 2020-02-26 6:52 PM, Bj?rn Ekelund, SM7IUN wrote:
Joe,
I'm not so well versed in the CTY terminology. With the "default grid" I
mean the reference
grid that pops up when you enter a random call in DXView. All DXCC entities
seem to have at least one.
Bj?rn SM7IUN
Den ons 26 feb. 2020 kl 20:06 skrev Joe Subich, W4TV <lists@...>:


> Is there a reason to not populate the grid with the entity's default
> locator?

There is no "default locator" for any entity other than HC1, 1A, 3A
which are smaller than a four character grid.

If I simply select VP8-O from the drop down menu, the grid box is
populated.
The grid that is populated when selecting any entity is the one that
either Dave or I selected as a reference (typically geographical center
with some modifications to "center of largest city") when creating or
updating the DXCC database.

73,

... Joe, W4TV


On 2020-02-26 11:35 AM, Bj?rn Ekelund, SM7IUN wrote:
I love the possibility to keep an up-to-date database for exceptions to
the
"standard" callsign rules
in DXView but recently I have found a limitation that I find a bit
frustrating.

If I, for instance, enter VP8PJ in the callsign box and hit ENTER, the
grid
box ends up empty.
The distance (13931km) shows, however. Since the grid and geographical
coordinates are
undefined, clicking the Sun button yields an empty array.

When I open the Config's Override List panel and right-click the VP8PJ
entry and chose
"Populate override content from entity" I get the message "all override
components are already populated".
No grid.

Is there a reason to not populate the grid with the entity's default
locator?
If I simply select VP8-O from the drop down menu, the grid box is
populated.

Bj?rn SM7IUN


Re: -@ in spot collector

 

Hi Dave,
Can you do a global exclusion for all -@ calls like you do for -#?
73, George
W2GS

On 2/26/2020 6:38 PM, iain macdonnell - N6ML wrote:
On Wed, Feb 26, 2020 at 6:24 AM Dave AA6YQ <aa6yq@...> wrote:
+ AA6YQ comments below

I sometimes see this after a spot source callsign. Couldn't find it in the documentation.

+ It's mentioned in the description of the "Discard spots from spotting stations callsigns ending in - #" option in

<>

+ When generating spots, Skimmers like "CW Skimmer" append -# to the callsign of the spotting station.

+ This above-cited option gives you the ability to have SpotCollector ignore such spots.
The question was about the '-@' suffix, not '-#', though. The former
is appended by DX Summit, on spots submitted through their web
interface, from what I understand.

73,

~iain / N6ML


Re: -@ in spot collector

 

On Wed, Feb 26, 2020 at 6:24 AM Dave AA6YQ <aa6yq@...> wrote:

+ AA6YQ comments below

I sometimes see this after a spot source callsign. Couldn't find it in the documentation.

+ It's mentioned in the description of the "Discard spots from spotting stations callsigns ending in - #" option in

<>

+ When generating spots, Skimmers like "CW Skimmer" append -# to the callsign of the spotting station.

+ This above-cited option gives you the ability to have SpotCollector ignore such spots.
The question was about the '-@' suffix, not '-#', though. The former
is appended by DX Summit, on spots submitted through their web
interface, from what I understand.

73,

~iain / N6ML


Re: DXView's ""Populate override content from entity"

 

Joe,

I'm not so well versed in the CTY?terminology. With the "default grid" I mean the reference?
grid that pops up when you enter a random call in DXView. All DXCC entities seem to have at least one.?

Bj?rn SM7IUN

Den ons 26 feb. 2020 kl 20:06 skrev Joe Subich, W4TV <lists@...>:


?> Is there a reason to not populate the grid with the entity's default
?> locator?

There is no "default locator" for any entity other than HC1, 1A, 3A
which are smaller than a four character grid.

> If I simply select VP8-O from the drop down menu, the grid box is
> populated.

The grid that is populated when selecting any entity is the one that
either Dave or I selected as a reference (typically geographical center
with some modifications to "center of largest city") when creating or
updating the DXCC database.

73,

? ? ... Joe, W4TV


On 2020-02-26 11:35 AM, Bj?rn Ekelund, SM7IUN wrote:
> I love the possibility to keep an up-to-date database for exceptions to the
> "standard" callsign rules
> in DXView but recently I have found a limitation that I find a bit
> frustrating.
>
> If I, for instance, enter VP8PJ in the callsign box and hit ENTER, the grid
> box ends up empty.
> The distance (13931km) shows, however. Since the grid and geographical
> coordinates are
> undefined, clicking the Sun button yields an empty array.
>
> When I open the Config's Override List panel and right-click the VP8PJ
> entry and chose
> "Populate override content from entity" I get the message "all override
> components are already populated".
> No grid.
>
> Is there a reason to not populate the grid with the entity's default
> locator?
> If I simply select VP8-O from the drop down menu, the grid box is populated.
>
> Bj?rn SM7IUN
>






Re: DXView's ""Populate override content from entity"

 

Although I understand what you are saying I struggle with the logic.

If I enter a random Swedish call in DXView, I get the grid locator of central Stockholm which of course is?
very wrong for e.g. my call. But close enough for all practical purposes (beam heading, sun info, spot plot)?
except of course VUCC. I believe everyone prefers this before getting an empty?grid.

If I enter a callsign which is in the override list and the override?lacks a grid. I get an empty grid.
What is wrong with using the DXCC database lookup grid when the override lacks a grid, just as?
with?random calls? Why is this a bad idea??

If random calls actually generate the default grid for its DXCC entity, I assume SpotCollector can tell the?
difference between reliable and unreliable grids?

Bj?rn SM7IUN

Den ons 26 feb. 2020 kl 21:17 skrev Dave AA6YQ <aa6yq@...>:

+ AA6YQ comments below

I love the possibility to keep an up-to-date database for exceptions to the "standard" callsign rules in DXView but recently I have found a limitation that I find a bit frustrating.

If I, for instance, enter VP8PJ in the callsign box and hit ENTER, the grid box ends up empty.
The distance (13931km) shows, however. Since the grid and geographical coordinates are undefined, clicking the Sun button yields an empty array.

When I open the Config's Override List panel and right-click the VP8PJ entry and chose "Populate override content from entity" I get the message "all override components are already populated".
No grid.

Is there a reason to not populate the grid with the entity's default locator?

+ Yes: DXLab treats the grid square specified in an override as accurate enough to count for awards that involve pursuing grid squares, like VUCC. As Joe W4TV explained, the grid square produced by a DXCC Database lookup does not meet that accuracy criterion.

If I simply select VP8-O from the drop down menu, the grid box is populated.

+ I assume that you're referring to the DXCC prefix selector on DXView's Main window. Using the grid square produced by a DXCC Database lookup is accurate enough for the purpose of displaying a great circle path and computing a beam heading.

? ? ? ? 73,

? ? ? ? ? ? ? ?Dave, AA6YQ






Re: 60M Stats

 

Thanks, Dave! ?

That works!!!!!!!!!!!!!!

73
Glenn W0GJ


Re: Commander <-> Acom 2000S

 

+ AA6YQ comments below

Very appreciate to help me to connect Commander to Acom 2000S remote antenna switch via serial port.
First question: it¡¯s possible?

+ No. As described in

<>

+ Commander supports two standard serial port protocols for transceiver selection and auxiliary device control: microHam, and OTRSP. The command set described on page 16 of

<>

+ is not compatible with either of the protocols that Commander supports.

+ Given the poor quality of the Acom 2000S remote antenna documentation, I will not attempt to extend Commander to support it without having physical access to one for rapid resolution of documentation ambiguities.

73,

Dave, AA6YQ


Re: 60M Stats

 

I use this to check DXCC Progess on 60 meters:

QSO_Begin BETWEEN #2020-01-01 00:00# and #2020-12-31 23:59# AND BAND='60M'

Tom NQ7R


Re: DXKeeper + callbook issue

 

+ AA6YQ comments below

I am using Commander / DXKeeper / WSJT-X / JT Alert for FT-8 and all seems to work well, including automatic logging to LoTW and DXKeeper. However in DXK I notice that the name and town of my QSO partner is not shown. When I press the DXK "CBA" button, I get the following error message:

"This QSO has not been unlocked for modification. Perform a call book look up Yes or No?"
When I press yes, it does put in the name and town.

+ You have the "Require Edit to modify logged QSO" box check in the "Main Log QSOs options" panel on the General tab of DXKeeper's Configuration window, which protects against inadvertent modifications to logged QSOs. To avoid message reported above, click Edit button before clicking the CBA button; the Edit button is located to the left of the CBA button just above the Log Page Display on the "Log QSOs" tab of DXKeeper's Main window.

In DXK, I am using HomeQTH.com, having posted my user name and password in DXK config.

+ JTAlert is responsible for the content of the QSOs it logs to DXKeeper. If you want such QSOs to include the results of a callbook lookup, appropriately configure the "Online XML Callbooks" sub-section in the "Web Services" section on the left panel of the JTAlertX Settings window. This is step 2.d in the JTAlert section of

<>

73,

Dave, AA6YQ


Re: DXKeeper SFI, A, K logging and JTAlert issue

 

+ AA6YQ comments below

Hello all. I use WSJT-X 2.1.2 and JTAlert 2.15.10 for FT8. I have the box checked in JTAlert, Logging to fill the SFI, A, and K boxes in DXKeeper 15.4.3. When I first started this a couple years ago, it would fill in automatically. With one of the upgrades of JTAlert, it quit doing so. I have the latest updates for WSJT-X, JTAlert, the current Netframe edition 4.7.2, and am running Win7 Professional 32 bit, all updates. Does this feature not work anymore, or what am I missing?

+ Unless someone more familiar with JTAlert than me responds here, I suggest that you post your question on the JTAlert Support group:

<>

73,

Dave, AA6YQ


Re: use f1 to f4 in winwarbler?

 

+ AA6QY comments below

Anyway to use the "standard" Fkeys in Winwarbler, F1, CQ, F4 my call, etc, to be consistent with other logger programs?

+ No. In all modes, F2 is used to start transmission, and F4 is used to terminate transmission after all characters have been transmitted. When operating PSK, F1 is used to set the transmit frequency to the receive frequency associated with the currently-selected display pane, and F3 initiates a CW ID.

73,

Dave, AA6YQ


Re: DXView's ""Populate override content from entity"

 

+ AA6YQ comments below

I love the possibility to keep an up-to-date database for exceptions to the "standard" callsign rules in DXView but recently I have found a limitation that I find a bit frustrating.

If I, for instance, enter VP8PJ in the callsign box and hit ENTER, the grid box ends up empty.
The distance (13931km) shows, however. Since the grid and geographical coordinates are undefined, clicking the Sun button yields an empty array.

When I open the Config's Override List panel and right-click the VP8PJ entry and chose "Populate override content from entity" I get the message "all override components are already populated".
No grid.

Is there a reason to not populate the grid with the entity's default locator?

+ Yes: DXLab treats the grid square specified in an override as accurate enough to count for awards that involve pursuing grid squares, like VUCC. As Joe W4TV explained, the grid square produced by a DXCC Database lookup does not meet that accuracy criterion.

If I simply select VP8-O from the drop down menu, the grid box is populated.

+ I assume that you're referring to the DXCC prefix selector on DXView's Main window. Using the grid square produced by a DXCC Database lookup is accurate enough for the purpose of displaying a great circle path and computing a beam heading.

73,

Dave, AA6YQ


DXKeeper + callbook issue

 

I am using Commander / DXKeeper / WSJT-X / JT Alert for FT-8 and all seems to work well, including automatic logging to LoTW and DXKeeper. However in DXK I notice that the name and town of my QSO partner is not shown. When I press the DXK "CBA" button, I get the following error message:

"This QSO has not been unlocked for modification. Perform a call book look up Yes or No?"
When I press yes, it does put in the name and town.

In DXK, I am using HomeQTH.com, having posted my user name and password in DXK config.

What am I doing wrong?

Thanks in advance for any help and 73,
Carter?? K8VT


Re: 60M Stats

 

SpotCollector's add on SpotSpy provides support for 60M

For more information about SpotSpy visit
Full release is available at

73
Volker, DL9HO


Re: DXView's ""Populate override content from entity"

 

Is there a reason to not populate the grid with the entity's default
locator?
There is no "default locator" for any entity other than HC1, 1A, 3A
which are smaller than a four character grid.

If I simply select VP8-O from the drop down menu, the grid box is
populated.
The grid that is populated when selecting any entity is the one that
either Dave or I selected as a reference (typically geographical center
with some modifications to "center of largest city") when creating or
updating the DXCC database.

73,

... Joe, W4TV


On 2020-02-26 11:35 AM, Bj?rn Ekelund, SM7IUN wrote:
I love the possibility to keep an up-to-date database for exceptions to the
"standard" callsign rules
in DXView but recently I have found a limitation that I find a bit
frustrating.
If I, for instance, enter VP8PJ in the callsign box and hit ENTER, the grid
box ends up empty.
The distance (13931km) shows, however. Since the grid and geographical
coordinates are
undefined, clicking the Sun button yields an empty array.
When I open the Config's Override List panel and right-click the VP8PJ
entry and chose
"Populate override content from entity" I get the message "all override
components are already populated".
No grid.
Is there a reason to not populate the grid with the entity's default
locator?
If I simply select VP8-O from the drop down menu, the grid box is populated.
Bj?rn SM7IUN


DXKeeper SFI, A, K logging and JTAlert issue

 

Hello all.? I use WSJT-X 2.1.2 and JTAlert 2.15.10 for FT8.? I have the box checked in JTAlert, Logging?to fill the SFI, A, and K boxes in DXKeeper 15.4.3.? When I first started this a couple years ago, it would fill in automatically.? With one of the upgrades of JTAlert, it quit doing so.? I have the latest updates for WSJT-X, JTAlert, the current Netframe edition 4.7.2, and am running Win7 Professional 32 bit, all updates.? Does this feature not work anymore, or what am I missing?


use f1 to f4 in winwarbler?

 

Anyway to use the "standard" Fkeys in Winwarbler, F1, CQ, F4 my call, etc, to be consistent with other logger programs?