¿ªÔÆÌåÓý

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

"Bouncing" Filters Group in DX Commander

 

I have observed this behavior while never noticing it before.
?
My transceiver is an IC7300.? I am on FT8 with WSJT.? A CW DX spot comes out, and I double-click in spot collector.? Commander changes to the correct frequency, mode, and filter bandwidth.? (It seem sometimes I have to stop monitoring on WSJT, and sometimes not, or it will grab me back to the FT8 frequency, but that's not what this is about).? When I return to FT8 by re-enabling the monitor in WSJT, I see that the bandwidth is 2.7 kHz.? Before that, it was 3+ kHz on the waterfall.? I then change the Filters Group setting back to Normal (or Wide), and the bandwith goes back to the 3+ kHz.? But now, the Group bandwidth display periodic bounces from normal to narrow, about 1 to 2 times per second.? I can change the filter to wide, same bouncing.? I can change it to narrow (where it was on CW immediately prior to coming back to FT8), and there is no bounce.? There is some kind of polling going on and the state it keeps trying is Narrow. I don't hear any bandwidth changes on the radio while this is going on, and I don't see any change in the WSJT spectrum.
?
Once I shut down commander and restart, this behavior disappears and "normal" is the constant state of the filter group.
?
Any ideas what's going on?
?
73,
Dean W8ZF


Re: Audio Alarm Includies Grid Square

 

+ AA6YQ comments below

When I post to the Cluster (using SpotCollector) the audio alarm readout says "Grid Square FO93" included in the announcement.

First of all:

1. F093 is wrong, and no matter what Call is Spotted, the same Grid Square is announced.
2. Even in Spots announced by other stations, the Grid Square FO93 is announced.

What is the source of this and how can I turn it off?

+ That's the result of a regression. I've sent you a new version of SpotCollector with this defect corrected; please let me know how it goes.

73,

Dave, AA6YQ


support for new radio

 

will dxlab support the new ftx-1?

thanks


Reggie
k6xr


Audio Alarm Includies Grid Square

 

When I post to the Cluster (using SpotCollector) the audio alarm readout says "Grid Square FO93" included in the announcement.?
?
First of all:
?
1. F093 is wrong, and no matter what Call is Spotted, the same Grid Square is announced.
2. Even in Spots announced by other stations, the Grid Square FO93 is announced.
?
What is the source of this and how can I turn it off?
?
SC 9.9.2
?
73, N0AN, Hasan


Re: new POTA and SOTA poll #poll-notice

 

+ AA6YQ comments below.

You'd have to account for the fact that some parks are in multiple counties, states, and even grids.

+ The downloadable POTA park definition file specifies the following for each POTA reference number:

- Park Name, e.g. "Acadia National Park"

- Active

- DXCC entity code, e.g. 291 (continental US)

- DXCC entity abbreviation and primary administrative subdivision, e.g. US-ME

- latitude & longitude

- grid square

+ Double-clicking on a Spot Database Entry with POTA reference NO-1631 - Reinaya Nature Reserve - specifies NO-IN,NO-MR, meaning that it lies in two Norwegian primary subdivisions, could display a small window asking the user to choose the correct primary subdivision or leave it blank.

+ Multiple grid squares could be handled in the same way.

73,

Dave, AA6YQ


Re: new POTA and SOTA poll #poll-notice

 

You'd have to account for the fact that some parks are in multiple counties, states, and even grids.

Earl / KD5XB

Sent from Proton Mail Android

-------- Original Message --------
On 5/23/25 2:09 PM, Dave AA6YQ <aa6yq@...> wrote:

+ AA6YQ comments below

I'll argue that when activators submit logs to LotW and don't create and use appropriate locations it may "hurt" grid or County hunters, and if in a different state or country, it may "hurt" WAS or DXCC hunters.

+ After completion of the proposed "step 3" in POTA/SOTA support, double-clicking a Spot Database Entry that specifies a POTA code would query the local POTA database (generated from ) for that park's U.S. State and Gridsquare. This would prevent the location misinformation caused by callbook location information being tied to a callsign.

73,

Dave, AA6YQ







Re: new POTA and SOTA poll #poll-notice

 

¿ªÔÆÌåÓý

The ability for SpotCollector to lookup a park's location would be very welcomed!? Currently, I plug the POTA designator into the pota.app site so I can see on a map where it is.? If it's in the same area as the callsign owner's location, I use the beam heading from DXView.? If not, I approximate from the map.

73,
Ken, KJ9B


From: [email protected] <[email protected]> on behalf of Dave AA6YQ via groups.io <aa6yq@...>
Sent: Friday, May 23, 2025 4:09 PM
To: [email protected] <[email protected]>
Subject: Re: [DXLab] new POTA and SOTA poll #poll-notice
?
+ AA6YQ comments below

I'll argue that when activators submit logs to LotW? and don't create and use appropriate locations it may "hurt" grid or County hunters, and if in a different state or country, it may "hurt" WAS or DXCC hunters.

+ After completion of the proposed "step 3" in POTA/SOTA support, double-clicking a Spot Database Entry that specifies a POTA code would query the local POTA database (generated from ? for that park's U.S. State and Gridsquare. This would prevent the location misinformation caused by callbook location information being tied to a callsign.

???? 73,

???????????? Dave, AA6YQ







Re: new POTA and SOTA poll #poll-notice

 

+ AA6YQ comments below

Been thinking about this a lot today as I have been chasing POTA on 20m FT8. My overall goal is to work ATNO's first and then whoever else is activating second (who may be activating multiples and no way to tell if the additional parks are ATNO's). How I am doing it now is using GridTracker as it takes spots from pota.app and indicates them on the Call Roster. I also use Chrome with POTAPlus to inform me if they are ATNO's. I would much rather just use SpotCollector because everything would be on one application to include the logging interface between WSJT-X and DXKeeper.

This is what I would wish SpotCollector would do - let me know which ones are ATNO's plus displaying the spots from pota.app as well as those from other sources - I use the IZ2LSC cluster that has a pre-filtered SOTA/POTA feed. When I work and log it, it already takes the POTA info and adds it to the user defined field in DXKeeper already, so I don't think that one needs to even mess with DXKeeper. You would download the CSV file from pota.app under My Stats of all of the unique parks you have credited to you. This database would be checked against the incoming spot data to see if it was an ATNO and then indicate it.

+ Having to download a CSV file to update your POTA status each time you work a new POTA park would frankly be a kludge. Were this to become widespread practice, whatever if serving that CSV file might become a bottleneck.

+ For NPOTA, DXKeeper's NPOTA progress report would generate an SQL query that could be invoked from SpotCollector to identify any active stations in unworked U.S. parks. That too was a kludge, but given NPOTA's one-year lifespan, it was a tolerable compromise.

73,

Dave, AA6YQ


Re: new POTA and SOTA poll #poll-notice

 

+ AA6YQ comments below

I'll argue that when activators submit logs to LotW and don't create and use appropriate locations it may "hurt" grid or County hunters, and if in a different state or country, it may "hurt" WAS or DXCC hunters.

+ After completion of the proposed "step 3" in POTA/SOTA support, double-clicking a Spot Database Entry that specifies a POTA code would query the local POTA database (generated from ) for that park's U.S. State and Gridsquare. This would prevent the location misinformation caused by callbook location information being tied to a callsign.

73,

Dave, AA6YQ


Re: new POTA and SOTA poll #poll-notice

 

Been thinking about this a lot today as I have been chasing POTA on 20m FT8.? My overall goal is to work ATNO's first and then whoever else is activating second (who may be activating multiples and no way to tell if the additional parks are ATNO's).? How I am doing it now is using GridTracker as it takes spots from pota.app and indicates them on the Call Roster.? I also use Chrome with POTAPlus to inform me if they are ATNO's.? I would much rather just use SpotCollector because everything would be on one application to include the logging interface between WSJT-X and DXKeeper.
?
This is what I would wish SpotCollector would do - let me know which ones are ATNO's plus displaying the spots from pota.app as well as those from other sources - I use the IZ2LSC cluster that has a pre-filtered SOTA/POTA feed.? When I work and log it, it already takes the POTA info and adds it to the user defined field in DXKeeper already, so I don't think that one needs to even mess with DXKeeper.??You would download the CSV file from pota.app under My Stats of all of the unique parks you have credited to you.? This database would be checked against the incoming spot data to see if it was an ATNO and then indicate it.
?
73
Dennis WB0WAO
?
?


Re: new POTA and SOTA poll #poll-notice

 

I'll argue that when activators submit logs to LotW? and don't create and use appropriate locations it may "hurt" grid or County hunters, and if in a different state or country, it may "hurt" WAS or DXCC hunters.

If we know someone is not submitting properly, as Elmers we might want to politely inform them of better practice.? They might not know better or need a friendly or informative push.? Their current log might not be multiple location friendly like DXLab, and they may not want separate logs for each activation location.? They may not recognize or understand the problem and think that they are doing a good thing.

NU6T, Rich

Richard Hill

On Fri, May 23, 2025, 10:01?AM Dave AA6YQ via <aa6yq=[email protected]> wrote:
+ AA6YQ comments below
How is all this going to be affected when an activator goes home znd uploads to LotW, eQSL, etc, as if he was at home and not in a park?? This is just about as common as breathing.
+ Neither LoTW nor eQSL provide "POTA credit". What matters is that an activator correctly submit QSOs to POTA so that chasers will get credit.

? ? ? ? ? 73,

? ? ? ? ? ? ? ? Dave, AA6YQ


Re: Spotcollector frozen (well sorta)

 

+ AA6YQ comments below
FYI only: Prune was set to 7 days.? It had been set to that value for years. I learned long ago to manage the size of the spot database.? Task manager did not show anything churning in the background. That's why I am a bit mystified that by selecting a change to "Prune Spot Database" corrected my issue.
+ You reported that the new misbehavior first occurred after a Windows update, so the initial hypothesis is that this update reduced your system's ability to handle the compute/memory load generated by your previous SpotCollector configuration. I suggest that you check Windows' virtual memory configuration, and confirm that your DXLab applications are each considered "safe" by Windows Defender and by any other anti-malware you have installed.
?
? ? ?73,

? ? ? ? ?Dave, AA6YQ
?


Re: Spotcollector frozen (well sorta)

 

Hi Dave,
?
? ? FYI only: Prune was set to 7 days.? It had been set to that value for years. I learned long ago to manage the size of the spot database.? Task manager did not show anything churning in the background. That's why I am a bit mystified that by selecting a change to "Prune Spot Database" corrected my issue.
?
73, Mike K9MK
?
?
? ? ??
?
??


Re: new POTA and SOTA poll #poll-notice

 

+ AA6YQ comments below
How is all this going to be affected when an activator goes home znd uploads to LotW, eQSL, etc, as if he was at home and not in a park?? This is just about as common as breathing.
+ Neither LoTW nor eQSL provide "POTA credit". What matters is that an activator correctly submit QSOs to POTA so that chasers will get credit.

? ? ? ? ? 73,

? ? ? ? ? ? ? ? Dave, AA6YQ


Re: new POTA and SOTA poll #poll-notice

 

¿ªÔÆÌåÓý

Since POTA hunters don't submit logs to the POTA system, any POTA awards are contingent upon the activator submitting their log for any "awards" to be issued.? For that reason, especially when I'm activating at a park, if I work a Park-to-Park station that tells me they have multiple park numbers, I thank them and tell them I don't need all their numbers, since I'll get credit for them when they submit their log.? That saves lots of time on the exchange.? Granted, doing it this way, I don't track on my end all the parks I "hunt", but my POTA "hunting" is done mainly for fun and to give the activators the Qs in their log.? My POTA activations are what I? REALLY keep track of.

73,
Ken, KJ9B



From:[email protected] <[email protected]> on behalf of Dave AA6YQ via groups.io <aa6yq@...>
Sent:?Friday, May 23, 2025 12:02
To:[email protected] <[email protected]>
Subject:?Re: [DXLab] new POTA and SOTA poll #poll-notice

<snip>
+ The fact that one activator can simultaneously activate up to 6 parks with no way to identify all of those parks in spot notes (which are limited to 29 characters) makes realtime award tracking for POTA less valuable to POTA chasers.

? ? ? ? ?73,

? ? ? ? ? ? ? ?Dave, AA6YQ


Re: new POTA and SOTA poll #poll-notice

 

How is all this going to be affected when an activator goes home znd uploads to LotW, eQSL, etc, as if he was at home and not in a park?? This is just about as common as breathing.

Earl / KD5XB

Sent from Proton Mail Android



-------- Original Message --------
On 5/23/25 10:02 AM, Dave AA6YQ wrote:
+ AA6YQ comments below
A bit late to the party but here is my .02 on the matter.? FWIW, I have 5500+ total contacts with POTA activators and ~2200 confirmed parks.
+ Thanks for your comments, Dennis!
The first issue is that the POTA database is very dynamic with new parks being added continuously, sometimes literally daily.? For example, there are about 8 areas that I could submit today within 15 miles of my QTH that would be eligible to be issued a POTA number.? I have on 3 occasions submitted an area and usually within a few hours they have been assigned a POTA number.? I would think that it would be a nightmare to keep such an organic database up to date.? Not sure, but I pretty sure that there are multiple individuals that have the authority and ability to add new POTA entities.? Not to mention that entities get deactivated (deleted) from time to time.? All of this, IMHO, leads me to believe that it would be an exercise in frustration to even be able to utilize such a database much less keep it up to date.
+ My thought was to enable each user to direct DXView to download the current POTA definitions file to generate an up-to-date local POTA database at whatever frequency they desired.?
The second issue it that it is somewhat common for an activation counting for multiple parks.? The operator N2NWK is famous for his five-fer and six-fer activations in the Washington DC area.? If a dedicated POTA field is implemented, you would probably need to have at a minimum 4 of them per QSO like you do with the grid squares (Grid 1 - Grid 4).? Spots on the DXcluster system rarely indicated more than one POTA entity, and if they do there is no set format on how they are indicated.
+ If that's the case, the POTA progress report can be extended to handle a comma-delimited list in the user-defined item whose caption is POTA.
Given all of that, my suggestion is the following:
?
1)? Only deal with whether or not you have worked that entity on any band or mode.? Don't worry about different bands and/or modes - period.
2)? An organic database isn't needed - do what the POTAPlus Chrome extension does - parses the spots on the pota.app as well as you POTA records on their database to determine ATNO status.??
3)? Extract the POTA data from other spots like what DXKeeper does already when you have the USERDEFINED_0 as POTA and like GridTracker does for WSJT modes and check it like #2 above.
+ SpotCollector has for several years been extracting POTA tags from spot notes. Multi-park activations must not be common, as no one has previously mentioned this. So long as a QSO can log all of the park codes in a comma-delimited list and an accurate progress report can be generated, that's sufficient for the first few steps.
Bottom line, I don't think you need to do anything dealing with an organic database within DXLab - just determine if it is an ATNO from your POTA records based on spot data.
+ Realtime award tracking for POTA was the 4th step described in

/g/DXLab/message/229282

+ Given the significant development effort involved, initiating it would be contingent on significant utilization after the first 3 steps were complete. As of today, the poll shows 54 DXLab users pursuing POTA.

+ The fact that one activator can simultaneously activate up to 6 parks with no way to identify all of those parks in spot notes (which are limited to 29 characters) makes realtime award tracking for POTA less valuable to POTA chasers.

? ? ? ? ?73,

? ? ? ? ? ? ? ?Dave, AA6YQ


Re: new POTA and SOTA poll #poll-notice

 

+ AA6YQ comments below
A bit late to the party but here is my .02 on the matter.? FWIW, I have 5500+ total contacts with POTA activators and ~2200 confirmed parks.
+ Thanks for your comments, Dennis!
The first issue is that the POTA database is very dynamic with new parks being added continuously, sometimes literally daily.? For example, there are about 8 areas that I could submit today within 15 miles of my QTH that would be eligible to be issued a POTA number.? I have on 3 occasions submitted an area and usually within a few hours they have been assigned a POTA number.? I would think that it would be a nightmare to keep such an organic database up to date.? Not sure, but I pretty sure that there are multiple individuals that have the authority and ability to add new POTA entities.? Not to mention that entities get deactivated (deleted) from time to time.? All of this, IMHO, leads me to believe that it would be an exercise in frustration to even be able to utilize such a database much less keep it up to date.
+ My thought was to enable each user to direct DXView to download the current POTA definitions file to generate an up-to-date local POTA database at whatever frequency they desired.?
The second issue it that it is somewhat common for an activation counting for multiple parks.? The operator N2NWK is famous for his five-fer and six-fer activations in the Washington DC area.? If a dedicated POTA field is implemented, you would probably need to have at a minimum 4 of them per QSO like you do with the grid squares (Grid 1 - Grid 4).? Spots on the DXcluster system rarely indicated more than one POTA entity, and if they do there is no set format on how they are indicated.
+ If that's the case, the POTA progress report can be extended to handle a comma-delimited list in the user-defined item whose caption is POTA.
Given all of that, my suggestion is the following:
?
1)? Only deal with whether or not you have worked that entity on any band or mode.? Don't worry about different bands and/or modes - period.
2)? An organic database isn't needed - do what the POTAPlus Chrome extension does - parses the spots on the pota.app as well as you POTA records on their database to determine ATNO status.??
3)? Extract the POTA data from other spots like what DXKeeper does already when you have the USERDEFINED_0 as POTA and like GridTracker does for WSJT modes and check it like #2 above.
+ SpotCollector has for several years been extracting POTA tags from spot notes. Multi-park activations must not be common, as no one has previously mentioned this. So long as a QSO can log all of the park codes in a comma-delimited list and an accurate progress report can be generated, that's sufficient for the first few steps.
Bottom line, I don't think you need to do anything dealing with an organic database within DXLab - just determine if it is an ATNO from your POTA records based on spot data.
+ Realtime award tracking for POTA was the 4th step described in

/g/DXLab/message/229282

+ Given the significant development effort involved, initiating it would be contingent on significant utilization after the first 3 steps were complete. As of today, the poll shows 54 DXLab users pursuing POTA.

+ The fact that one activator can simultaneously activate up to 6 parks with no way to identify all of those parks in spot notes (which are limited to 29 characters) makes realtime award tracking for POTA less valuable to POTA chasers.

? ? ? ? ?73,

? ? ? ? ? ? ? ?Dave, AA6YQ


Re: Spotcollector frozen (well sorta)

 

+ AA6YQ comments below
Thanks Joe, all four spot sources are showing green status.
Pre Filtering is off.
?
Oh, I just found it (or something that got it going).? I had size control set to 7 days.? I changed that setting from Prune @ 7 days to setting below, setting a database file size at 30K QSO's and it kicked everything loose.? Spots are once again flying in and populating the bandspreads etc.?
?
I have no idea what or why, but it appears that we're good now.?
+ Your Spot Database was evidently so large that the resulting load was more than your PC could handle. Preventing this is why SpotCollector provides the ability to monitor the number of entries inthe Spot Database and keep it pruned to a manageable size.

? ? ? ? ? ? 73,

? ? ? ? ? ? ? ? ? Dave, AA6YQ
?


Re: Spotcollector frozen (well sorta)

 

Thanks Joe, all four spot sources are showing green status.
Pre Filtering is off.
?
Oh, I just found it (or something that got it going).? I had size control set to 7 days.? I changed that setting from Prune @ 7 days to setting below, setting a database file size at 30K QSO's and it kicked everything loose.? Spots are once again flying in and populating the bandspreads etc.?
?
I have no idea what or why, but it appears that we're good now.?
?
Thanks for the help.? Back to DXing...
?
73, Mike? K9MK
?


Re: new POTA and SOTA poll #poll-notice

 

A bit late to the party but here is my .02 on the matter.? FWIW, I have 5500+ total contacts with POTA activators and ~2200 confirmed parks.
?
The first issue is that the POTA database is very dynamic with new parks being added continuously, sometimes literally daily.? For example, there are about 8 areas that I could submit today within 15 miles of my QTH that would be eligible to be issued a POTA number.? I have on 3 occasions submitted an area and usually within a few hours they have been assigned a POTA number.? I would think that it would be a nightmare to keep such an organic database up to date.? Not sure, but I pretty sure that there are multiple individuals that have the authority and ability to add new POTA entities.? Not to mention that entities get deactivated (deleted) from time to time.? All of this, IMHO, leads me to believe that it would be an exercise in frustration to even be able to utilize such a database much less keep it up to date.
?
The second issue it that it is somewhat common for an activation counting for multiple parks.? The operator N2NWK is famous for his five-fer and six-fer activations in the Washington DC area.? If a dedicated POTA field is implemented, you would probably need to have at a minimum 4 of them per QSO like you do with the grid squares (Grid 1 - Grid 4).? Spots on the DXcluster system rarely indicated more than one POTA entity, and if they do there is no set format on how they are indicated.
?
Given all of that, my suggestion is the following:
?
1)? Only deal with whether or not you have worked that entity on any band or mode.? Don't worry about different bands and/or modes - period.
2)? An organic database isn't needed - do what the POTAPlus Chrome extension does - parses the spots on the pota.app as well as you POTA records on their database to determine ATNO status.??
3)? Extract the POTA data from other spots like what DXKeeper does already when you have the USERDEFINED_0 as POTA and like GridTracker does for WSJT modes and check it like #2 above.
?
Bottom line, I don't think you need to do anything dealing with an organic database within DXLab - just determine if it is an ATNO from your POTA records based on spot data.
?
Dennis - WB0WAO