Date   

Re: VE7CC - Spot Source

Jim N7US
 

Once you set the filters at the node using CC User, you can close it and thereafter connect directly to the node with SpotCollector.  I have several profiles set up at VE7CC and AE5E for different filters using different SSIDs (N7US, N7US-20, etc.) for different purposes.  N7US-20, for instance, gives me CW spots for the contest bands from K/VE, and I use that with N1MM+.

My standard profile, N7US, gives me spots from K/VE for 160-10M and from other stations in W9 for 6M, all excluding FT4/8.

In the original days of AK1A's DX PacketCluster (I was a sysop for many years), unfiltered spots were known as "The fire hose."

Jim N7US
Sent from Samsung tablet


-------- Original message --------
From: "iain macdonnell - N6ML via groups.io" <ar@...>
Date: 10/16/20 6:19 PM (GMT-06:00)
To: DXLab@groups.io
Subject: Re: [DXLab] VE7CC - Spot Source

On Fri, Oct 16, 2020 at 3:04 PM Dave AA6YQ <aa6yq@...> wrote:
>
> * More AA6YQ comments below
>
>
> It is en easy program to create filters which can be sent to the cluster. That limits bandwidth.
>
> + SpotCollector provides the ability to pre-filter cluster spots. See
>
> <https://www.dxlabsuite.com/dxlabwiki/SpotDatabasePrefilter>
>
> + With SpotCollector running, the VE7CC user application adds no value, but forces incoming spots to be processed twice, unnecessarily increasing CPU loading and memory consumption.
> That's not really accurate - (AFAIK - it's been years since I've used
> it) filters configured by the (VE7)CC User program are effected *on
> the cluster node*, so the spots don't even traverse the network
> (internet). This may make a significant difference to someone with
> limited bandwidth, and would not consume CPU/memory on the client PC.
> Those filters can be configured using commands/macros, but the CC User
> tool provides a nice GUI.
>
> * The CPU and memory consumed by running the CC User app significantly exceed the cost of conveying ~100 byte spots over the network every few seconds.

Curious how you quantified the cost of each, and what the actual results were?

I would have guessed that the network consumption would be more than
"~100 bytes every few seconds", especially if skimmer spots are
included.

I'm very lucky to have gigabit fiber internet to my home. I'm guessing
that some DXLab users have somewhat less than that, and some of those
users may have PCs with adequate capacity to run the CC User client (I
don't really it being especially bloated (but again, it's been years
since I used it).


> * Is there something wrong with SpotCollector's pre-filter GUI? There's a screen shot in the article cited above.

I think it's more about where the filtering is effected (on the client
or on the server). My point about the CC User GUI is that it provides
a nice interface for managing *server-side* filtering

73,

    ~iain / N6ML




Re: VE7CC - Spot Source

iain macdonnell - N6ML
 

On Fri, Oct 16, 2020 at 4:45 PM Dave AA6YQ <aa6yq@ambersoft.com> wrote:

% more AA6YQ comments below

Curious how you quantified the cost of each, and what the actual results were?

I would have guessed that the network consumption would be more than
"~100 bytes every few seconds", especially if skimmer spots are included.

I'm very lucky to have gigabit fiber internet to my home. I'm guessing that some DXLab users have somewhat less than that, and some of those users may have PCs with adequate capacity to run the CC User client (I don't really it being especially bloated (but again, it's been years since I used it).

% A DX spot is 75 bytes. At this moment, telnet.reversebeacon.net is reporting 8600 spots per hour, which is 2.4 spots per second, which is 180 bytes per second. No one's internet connection will be strained by this. No one's internet connection would be strained by 10X that bandwidth.
Is that really true? Maybe it is, and I'm way behind the times. It
used to be that there were lots of remote areas where broadband
service is not available, so choices (still) included options like
dial-up and satellite. Maybe that's all changed. Interested to hear
from others on this.


% With CC user running, every incoming spot that survives the cluster filters must be received, processed, and retransmitted to SpotCollector. These tasks consume CPU and memory resources, but add no value. I don't know whether the added time delay on incoming spots is significant.
I would imagine that the delay would be measured in milliseconds. I
know that you're quick to jump on the spots, but I'd be surprised if
milliseconds makes a difference :)


% At most, CC user should only be started when there's a desire to modify cluster filter settings; then it should be terminated so that SpotCollector can interact with its spot sources directly. But I doubt that the internet bandwidth savings achieved by "filtering at the cluster" will be noticeable.
It's been too long since I used it to recall if there are any settings
that are only effective for the session in which they are selected.
Even if they are, if someone wants to make frequent changes, it's
convenient to have the client running all of the time.

I'm not saying that everyone should be using this model - I'm just not
convinced that there aren't cases where it does make sense.....

73,

~iain / N6ML


Re: Pathfinder does not obtain (and diplay in DXKeeper LOG page) NAME and QTH data from QRZ.COM

Dave AA6YQ
 

+ AA6YQ comments below

...sent it to the new address.

My email address used is df7tv (at) mailbox.org

If that still does not work, I may temporarily upload the ErrorLog.txt file (Looking up "AA6YK") to my QSL.NET homepage. So you might download it from there.

+ Thanks for the errorlog.txt file, Tom.

+ In the "Internet Explorer" panel at the bottom of Pathfinder's Configuration, click the "Update Emulation" button. This should change the "Emulation" displayed in this panel from blank to 11.

+ Now try a callbook lookup of AA6YK.

73,

Dave, AA6YQ


Re: VE7CC - Spot Source

Dave AA6YQ
 

% more AA6YQ comments below

Curious how you quantified the cost of each, and what the actual results were?

I would have guessed that the network consumption would be more than
"~100 bytes every few seconds", especially if skimmer spots are included.

I'm very lucky to have gigabit fiber internet to my home. I'm guessing that some DXLab users have somewhat less than that, and some of those users may have PCs with adequate capacity to run the CC User client (I don't really it being especially bloated (but again, it's been years since I used it).

% A DX spot is 75 bytes. At this moment, telnet.reversebeacon.net is reporting 8600 spots per hour, which is 2.4 spots per second, which is 180 bytes per second. No one's internet connection will be strained by this. No one's internet connection would be strained by 10X that bandwidth.

% With CC user running, every incoming spot that survives the cluster filters must be received, processed, and retransmitted to SpotCollector. These tasks consume CPU and memory resources, but add no value. I don't know whether the added time delay on incoming spots is significant.

% At most, CC user should only be started when there's a desire to modify cluster filter settings; then it should be terminated so that SpotCollector can interact with its spot sources directly. But I doubt that the internet bandwidth savings achieved by "filtering at the cluster" will be noticeable.

73,

Dave, AA6YQ


Re: VE7CC - Spot Source

iain macdonnell - N6ML
 

On Fri, Oct 16, 2020 at 3:04 PM Dave AA6YQ <aa6yq@ambersoft.com> wrote:

* More AA6YQ comments below


It is en easy program to create filters which can be sent to the cluster. That limits bandwidth.

+ SpotCollector provides the ability to pre-filter cluster spots. See

<https://www.dxlabsuite.com/dxlabwiki/SpotDatabasePrefilter>

+ With SpotCollector running, the VE7CC user application adds no value, but forces incoming spots to be processed twice, unnecessarily increasing CPU loading and memory consumption.
That's not really accurate - (AFAIK - it's been years since I've used
it) filters configured by the (VE7)CC User program are effected *on
the cluster node*, so the spots don't even traverse the network
(internet). This may make a significant difference to someone with
limited bandwidth, and would not consume CPU/memory on the client PC.
Those filters can be configured using commands/macros, but the CC User
tool provides a nice GUI.

* The CPU and memory consumed by running the CC User app significantly exceed the cost of conveying ~100 byte spots over the network every few seconds.
Curious how you quantified the cost of each, and what the actual results were?

I would have guessed that the network consumption would be more than
"~100 bytes every few seconds", especially if skimmer spots are
included.

I'm very lucky to have gigabit fiber internet to my home. I'm guessing
that some DXLab users have somewhat less than that, and some of those
users may have PCs with adequate capacity to run the CC User client (I
don't really it being especially bloated (but again, it's been years
since I used it).


* Is there something wrong with SpotCollector's pre-filter GUI? There's a screen shot in the article cited above.
I think it's more about where the filtering is effected (on the client
or on the server). My point about the CC User GUI is that it provides
a nice interface for managing *server-side* filtering

73,

~iain / N6ML


Re: VE7CC - Spot Source

Dave AA6YQ
 

* More AA6YQ comments below


It is en easy program to create filters which can be sent to the cluster. That limits bandwidth.

+ SpotCollector provides the ability to pre-filter cluster spots. See

<https://www.dxlabsuite.com/dxlabwiki/SpotDatabasePrefilter>

+ With SpotCollector running, the VE7CC user application adds no value, but forces incoming spots to be processed twice, unnecessarily increasing CPU loading and memory consumption.
That's not really accurate - (AFAIK - it's been years since I've used
it) filters configured by the (VE7)CC User program are effected *on
the cluster node*, so the spots don't even traverse the network
(internet). This may make a significant difference to someone with
limited bandwidth, and would not consume CPU/memory on the client PC.
Those filters can be configured using commands/macros, but the CC User
tool provides a nice GUI. 

* The CPU and memory consumed by running the CC User app significantly exceed the cost of conveying ~100 byte spots over the network every few seconds. 

* Is there something wrong with SpotCollector's pre-filter GUI? There's a screen shot in the article cited above.

       73,

              Dave, AA6YQ


Re: VE7CC - Spot Source

iain macdonnell - N6ML
 

On Fri, Oct 16, 2020 at 2:23 PM Dave AA6YQ <aa6yq@ambersoft.com> wrote:

+ AA6YQ comments below

It is en easy program to create filters which can be sent to the cluster. That limits bandwidth.

+ SpotCollector provides the ability to pre-filter cluster spots. See

<https://www.dxlabsuite.com/dxlabwiki/SpotDatabasePrefilter>

+ With SpotCollector running, the VE7CC user application adds no value, but forces incoming spots to be processed twice, unnecessarily increasing CPU loading and memory consumption.
That's not really accurate - (AFAIK - it's been years since I've used
it) filters configured by the (VE7)CC User program are effected *on
the cluster node*, so the spots don't even traverse the network
(internet). This may make a significant difference to someone with
limited bandwidth, and would not consume CPU/memory on the client PC.
Those filters can be configured using commands/macros, but the CC User
tool provides a nice GUI.

73,

~iain / N6ML


Re: DXKeeper problem

Dave AA6YQ
 

+ AA6YQ comments below
I am referring to entry boxes in Log QSOs, Auxiliary and WSL.  Flashing in red are call, mode, Tx band, begin.  Flashing in blue are end, station call and my QTH. 

+ A QSO with no callsign, mode, band, or start time specified is illegal, which is why DXKeeper is flashing those labels in red font. Click the Edit button above the Log Page Display, and then click the Delete button above the Log Page Display

 Occasionally is the message "DXKeeper failed to launch after 180 seconds".  After 2 or 3 restarts, DXKeeper performs normally.

+ That's a classic sign of interference from an mis-configured or incompetent anti-malware application. See

<https://www.dxlabsuite.com/dxlabwiki/ApplicationInteference>

     73,

                Dave, AA6YQ


Re: VE7CC - Spot Source

Dave AA6YQ
 

+ AA6YQ comments below
It is en easy program to create filters which can be sent to the cluster. That limits bandwidth.

+ SpotCollector provides the ability to pre-filter cluster spots. See

<https://www.dxlabsuite.com/dxlabwiki/SpotDatabasePrefilter>

+ With SpotCollector running, the VE7CC user application adds no value, but forces incoming spots to be processed twice, unnecessarily increasing CPU loading and memory consumption.

           73,

                   Dave, AA6YQ

 


Re: DXKeeper problem

Ed Ireland
 



+ To what does "the upper boxes" refer? Which items have their labels flashing in red or blue font?

       73,

              Dave, AA6YQ

I am referring to entry boxes in Log QSOs, Auxiliary and WSL.  Flashing in red are call, mode, Tx band, begin.  Flashing in blue are end, station call and my QTH.  When I close DXKeeper and restart, the flashing red and blue do not appear but I get the message "this QSO has not been unlocked for modification; set its end time?"  Occasionally is the message "DXKeeper failed to launch after 180 seconds".  After 2 or 3 restarts, DXKeeper performs normally.

Thanks,

Ed K5YZW

On Thu, Oct 15, 2020 at 7:08 PM Dave AA6YQ <aa6yq@...> wrote:
The following message started coming up when I start DXKeeper:  "This QSO has not been unlocked for modification; set its end time?"  The upper boxes are flashing red and blue but they are blank.  I have not been able to find a QSO that does not have an end time. 

+ To what does "the upper boxes" refer? Which items have their labels flashing in red or blue font?

       73,

              Dave, AA6YQ









Re: VE7CC - Spot Source

Henk Remijn PA5KT
 

It is en easy program to create filters which can be sent to the cluster. That limits bandwidth.

Also useful when spotcollector is not used. Most of the time during contests, which is 95% of my operating.

I use Spotcollector for award chasing.

73 Henk PA5KT

Op 16-10-2020 om 18:53 schreef Dave AA6YQ:

Why is anyone interposing the "VE7CC user" program between SpotCollector and spot sources?

       73,

            Dave, AA6YQ


Re: Pathfinder does not obtain (and diplay in DXKeeper LOG page) NAME and QTH data from QRZ.COM

Dave AA6YQ
 

+ AA6YQ comments below

I sent it again...and hope this time it works :)

+ Still nothing received. Please try sending the message to

dave.bernstein (at) comcast.net

73,

Dave, AA6YQ


Re: Pathfinder does not obtain (and diplay in DXKeeper LOG page) NAME and QTH data from QRZ.COM

Tom DF7TV
 

Hello Dave,

I sent it again...and hope this time it works :)

73
Tom


Re: Pathfinder does not obtain (and diplay in DXKeeper LOG page) NAME and QTH data from QRZ.COM

Dave AA6YQ
 

+ AA6YQ comments below

Thank you Dave!
I just sent the according message to you.

+ I have not received your message, Tom. My email address is

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ


Re: ASCII 60 and 62 in Spot Source macro commands

Chuck, WS1L
 

Just a quick update.  I found the problem in one of the other parts of the macro.  Yes, substituting <60><62> for <> does in fact work.

73 de Chuck, WS1L



On Fri, Oct 16, 2020 at 2:28 PM Chuck Chandler <chandlerusm@...> wrote:
I'm trying to limit one of my spot sources to -

My call, no matter where spotted OR
Skimmer spots from Zone 5 that ARE NOT of K or VE stations
IF the skimmer spots are validated.

The macro should read -
SET DX FILTER CALL=WS1L OR ((CTY <> [K,VE]) AND((SPOTTERCQZONE=5) AND SKIMVALID))

but the < and > aren't passed to the cluster since SC thinks they are enclosing macros.  May I replace them with <60><62> to get the same result?

73 de Chuck, WS1L


FW: [ARRL-LoTW] LoTW now supports FST4

Dave AA6YQ
 

FYI

73,

Dave, AA6YQ

-----Original Message-----
From: ARRL-LoTW@groups.arrl.org [mailto:ARRL-LoTW@groups.arrl.org] On Behalf Of Greg K0GW
Sent: Friday, October 16, 2020 10:52 AM
To: ARRL-LoTW@groups.arrl.org
Subject: [ARRL-LoTW] LoTW now supports FST4

The ADIF standard has been updated to support FST4 as a sub-mode of MFSK.
Accordingly, CONFIG.xml for Logbook has been updated to version 11.13 to support FST4. Users will be offered the update when they run TQSL.

FST4 is only available in WSJT-X. An ADIF file emitted by WSJT-X should properly identify FST4. Therefore, anyone using the WSJT-X ADIF file for upload should find it smoothly imported in Logbook, provided that they have updated to use the latest version of the Config file.
73,
Greg, K0GW


Re: Pathfinder does not obtain (and diplay in DXKeeper LOG page) NAME and QTH data from QRZ.COM

Tom DF7TV
 

Thank you Dave!
I just sent the according message to you.

73
Tom


Re: ASCII 60 and 62 in Spot Source macro commands

Chuck, WS1L
 

Yes, and it didn't return any errors, but the cluster is still showing spots of W and VE stations.  I've posted elsewhere about that but I would like to rule out the macro substitution as a problem.  

Entering the command directly from the talk window has the exact same behavior, so I'm pretty sure this isn't the issue, just trying to rule it out.

73 de Chuck, WS1L



On Fri, Oct 16, 2020 at 2:34 PM iain macdonnell - N6ML <ar@...> wrote:
On Fri, Oct 16, 2020 at 11:28 AM Chuck, WS1L <chandlerusm@...> wrote:
>
> I'm trying to limit one of my spot sources to -
>
> My call, no matter where spotted OR
> Skimmer spots from Zone 5 that ARE NOT of K or VE stations
> IF the skimmer spots are validated.
>
> The macro should read -
> SET DX FILTER CALL=WS1L OR ((CTY <> [K,VE]) AND((SPOTTERCQZONE=5) AND SKIMVALID))
>
> but the < and > aren't passed to the cluster since SC thinks they are enclosing macros.  May I replace them with <60><62> to get the same result?

It seems like that should work. Did you try it?

73,

    ~iain / N6ML






Re: ASCII 60 and 62 in Spot Source macro commands

iain macdonnell - N6ML
 

On Fri, Oct 16, 2020 at 11:28 AM Chuck, WS1L <chandlerusm@gmail.com> wrote:

I'm trying to limit one of my spot sources to -

My call, no matter where spotted OR
Skimmer spots from Zone 5 that ARE NOT of K or VE stations
IF the skimmer spots are validated.

The macro should read -
SET DX FILTER CALL=WS1L OR ((CTY <> [K,VE]) AND((SPOTTERCQZONE=5) AND SKIMVALID))

but the < and > aren't passed to the cluster since SC thinks they are enclosing macros. May I replace them with <60><62> to get the same result?
It seems like that should work. Did you try it?

73,

~iain / N6ML


ASCII 60 and 62 in Spot Source macro commands

Chuck, WS1L
 

I'm trying to limit one of my spot sources to -

My call, no matter where spotted OR
Skimmer spots from Zone 5 that ARE NOT of K or VE stations
IF the skimmer spots are validated.

The macro should read -
SET DX FILTER CALL=WS1L OR ((CTY <> [K,VE]) AND((SPOTTERCQZONE=5) AND SKIMVALID))

but the < and > aren't passed to the cluster since SC thinks they are enclosing macros.  May I replace them with <60><62> to get the same result?

73 de Chuck, WS1L

3221 - 3240 of 200001