Date   

Re: LOTW upload first time

Ted Boerkamp
 

HI Dave...I have done what you asked me to do to figure out what happened causing 88 errors
With No matching qso in log. I selected the first qso in the list and I did the Update from Lotw.
I found the LoTW_UpdateSingle_ADI.txt file and looked at it.
After the <eoh> the only line showing is <APP_LoTW_EOF>
I tried to find more info on this but don’t understand the issue with it.
Any thoughts what has happened here?
73 Ted VE3SS

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Dave AA6YQ
Sent: Thursday, October 15, 2020 8:54 PM
To: DXLab@groups.io
Subject: Re: [DXLab] LOTW upload first time

+ AA6YQ comments below

Hi Dave.....this "No matching QSO in log" error has me stumped. What is DXkeeper comparing my uploaded Qs to?

+ As I stated in my previous response

"DXKeeper expects that the information reported by LoTW for a QSO exact matches that QSO's information in your log; any discrepancy produces this error message"

< https://groups.io/g/DXLab/message/196762>

+ In that response, I provided an example:

"For example, if you submit a QSO to LoTW whose start time is 00:00:00 Z, then modified the logged QSO's start time to 00:00:01Z, and the invoke "Sync LoTW QSOs", the result will be "no matching QSO in log".


You say any discrepancy will cause this but that could mean anything!!

+ The discrepancy can only be in one of the logged items that DXKeeper submits to LotW. The 10 items that DXKeeper submits to LoTW are documented in the second paragraph of this article:

<https://www.dxlabsuite.com/dxkeeper/Help/QSL.htm#QSLing%20via%20LotW>

1. Callsign of the station worked
2. UTC date at which the QSO began
3. UTC time at which the QSO began
4. QSO Mode (mapped to modes accepted by LOTW)
5. QSO Frequency
6. QSO Band
7. QSO receive frequency
8. QSO receive band
9. Satellite name
10, Propagation mode

How am I supposed to know what has mismatched on 88 Qs???

+ As I suggested in my previous response, "Pick one mismatch, and get to the bottom of it. That will likely explain the other 87."

+ Choose one QSO in your log for which DXKeeper reported "no matching QSO in log". Right-click this QSO, and select "Update from LoTW" from the pop-up menu. After the operation completes, navigate to DXKeeper's Databases folder and use Notepad to open the file

LoTW_UpdateSingle_ADI.txt

+ After the <eoh> tag in this file, you will find ADIF fields containing information being reported by LoTW. For example, the TIME_ON and QSO_DATE fields will convey the QSO's start time. In the logged QSO you chose, compare each of the 10 items that DXKeeper sent to LoTW with the information reported by LoTW. Find the mismatch.

I have printed off the list of calls and started looking at what I logged.
I cant see anything that I missed or could be interpreted as wrong. One of the Qs I actually confirmed with a qsl card and the data on the card I received matches my log

exactly!!! If my start time is logged a minute off what the other guy uploaded, is this grounds for this error to pop up??

+ The "no matching QSO in log" message is not reporting a mismatch between what you submitted and what your QSO partner submitted.

+ The "no matching QSO in log" message is reporting a mismatch between the information you submitted to LoTW, and the information LoTW is now reporting to DXKeeper -- which should be identical to what you submitted. If it's not identical, then you either changed the contents of one of those 10 items in the logged QSO after submitting it to LoTW, or the data was corrupted in transmit between DXKeeper and LoTW, or LoTW corrupted the data you submitted.

Why did LOTW report this group of 88 errors (87 no matches error) from my first upload while I was trying to sync the Second batch I uploaded with my second callsign?

+ When you invoked "Sync LoTW QSOs", LoTW reports QSOs newly-confirmed on or after the day you last submitted "Sync LoTW QSOs" - erroneously ignoring the time of the last "Sync LoTW QSOs" invocation that DXKeeper submits with its query to LoTW. Evidently, the QSOs you submitted in your first batch were confirmed on the same day as the QSOs you submitted in your second batch. Ignoring the time of last invocation is a defect in LoTW, but it hasn't been corrected in the ~10 years since I reported it.

+ Furthermore, LoTW is not the source of the "no matching QSO in log" error messages. DXKeeper is displaying this error message because the information being reported by LoTW is inconsistent with the information DXKeeper sent to LoTW, as described above.

What filter or SQL do I need to get the list of 88 errors appearing on my log screen again?
Thank you for your help..it is appreciated. I am not sure where to look next.

+ Focus on debugging a single logged QSOs that generated the "no matching QSO in log" error message, using the steps prescribed above.

73,

Dave, AA6YQ







--
This email has been checked for viruses by AVG.
https://www.avg.com


Re: Lost Flex 6400

Dave AA6YQ
 

+ AA6YQ comments below

I have a three radio setup on Commander - IC-9700, IC-7610 and Flex 6400. I'm done with contesting for a bit so decided to just do some casual operation today and suddenly Commander was no longer talking to the 6400. For the life of me I can't figure out why. Help is needed!

+ I suggest that you review these step-by-step instructions for configuring Commander to control a Flex Signature radio:

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

+ If that doesn't get you going, please let me know.

73,

Dave, AA6YQ


Lost Flex 6400

Richard Lawn
 

I have a three radio setup on Commander - IC-9700, IC-7610 and Flex 6400. I'm done with contesting for a bit so decided to just do some casual operation today and suddenly Commander was no longer talking to the 6400. For the life of me I can't figure out why. Help is needed!

Rick, W2JAZ

--
Rick, W2JAZ 


Re: Default Mode in Capture Window

rcktscientist64
 

I log O when I'm calling CQ and RO when I answer a CQ so I can tell who was calling CQ when I look back through my log.

Bruce - K5WBM

On Oct 17, 2020, at 2:49 PM, iain macdonnell - N6ML <@N6ML> wrote:

On Sat, Oct 17, 2020 at 12:12 PM Fred Kemmerer <fkemmerer@...> wrote:

Thank you for considering supporting default modes. For JT65 EME, RO, and O reports are used almost exclusively. There is basically no use of the -xx signal reports common with FT8/FT8 and some other WSJT-X modes. It might be best if the end-user could set their defaults for at least any modes that are used in EME (ex JT65, QRA64, JT9, etc). If these modes are used for terrestrial contacts, then the -xxx format would be appropriate but when these modes are used for EME (moon bounce), it would need to be RO and O to be useful. I really would like to see the RO and O reports to be available as an option for these modes as it's easy to forget to include them when making contacts rapidly such as during the various EME contests such as ARRL EME. Maybe blank unless an RO, O option is set and one of the EME modes is in set via Commander?
As pointed out by someone else in this discussion, the "report" is (if
anything) just "O". "RO" means "[R]oger (I received my report), and
yours is (also) [O]".

73,

~iain / N6ML





Re: Default Mode in Capture Window

iain macdonnell - N6ML
 

On Sat, Oct 17, 2020 at 12:12 PM Fred Kemmerer <fkemmerer@...> wrote:

Thank you for considering supporting default modes. For JT65 EME, RO, and O reports are used almost exclusively. There is basically no use of the -xx signal reports common with FT8/FT8 and some other WSJT-X modes. It might be best if the end-user could set their defaults for at least any modes that are used in EME (ex JT65, QRA64, JT9, etc). If these modes are used for terrestrial contacts, then the -xxx format would be appropriate but when these modes are used for EME (moon bounce), it would need to be RO and O to be useful. I really would like to see the RO and O reports to be available as an option for these modes as it's easy to forget to include them when making contacts rapidly such as during the various EME contests such as ARRL EME. Maybe blank unless an RO, O option is set and one of the EME modes is in set via Commander?
As pointed out by someone else in this discussion, the "report" is (if
anything) just "O". "RO" means "[R]oger (I received my report), and
yours is (also) [O]".

73,

~iain / N6ML


Re: Default Mode in Capture Window

Fred Kemmerer
 

Thank you for considering supporting default modes. For JT65 EME, RO, and O reports are used almost exclusively. There is basically no use of the -xx signal reports common with FT8/FT8 and some other WSJT-X modes. It might be best if the end-user could set their defaults for at least any modes that are used in EME (ex JT65, QRA64, JT9, etc). If these modes are used for terrestrial contacts, then the -xxx format would be appropriate but when these modes are used for EME (moon bounce), it would need to be RO and O to be useful. I really would like to see the RO and O reports to be available as an option for these modes as it's easy to forget to include them when making contacts rapidly such as during the various EME contests such as ARRL EME. Maybe blank unless an RO, O option is set and one of the EME modes is in set via Commander?
--
Best and 73,

Fred, AB1OC
https://stationproject.blog
https://www.n1fd.org


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

Dave AA6YQ
 

+ AA6YQ comments below
when I tried to solve the problem on my own, I think I did not understand correctly the shown section "Configuring Pathfinder" of
http://www.dxlabsuite.com/pathfinder/Help.htm

Having read the part "In the Internet Explorer panel, click the Update Emulation button" I immediatly thought it would be a setting to do in the Internet Explorer itself.

+ Thanks, Tom. I made some improvements in the documentation that should help:

<https://www.dxlabsuite.com/pathfinder/Help.htm>

       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,
when I tried to solve the problem on my own, I think I did not understand correctly the shown section "Configuring Pathfinder" of
http://www.dxlabsuite.com/pathfinder/Help.htm

Having read the part "In the Internet Explorer panel, click the Update Emulation button" I immediatly thought it would be a setting to do in the Internet Explorer itself.

Well -- my fault.

73
Tom


--
"In the Internet Explorer panel, click the Update Emulation button; doing so will add an entry to the Windows Registry that enables Pathfinder to display web pages using the full capabilities of the version of Internet Explorer installed on your computer. Depending upon the version of Windows you are running, a small User Account Control window seeking your approval may appear; this window may only be visible on the Windows Taskbar, in which case you should open it from there. After you approve this action, Pathfinder will offer to terminate so that you can restart it with the new Windows Registry setting in force."


Re: VE7CC - Spot Source

Dave AA6YQ
 

$ AA6YQ comments below

On Fri, Oct 16, 2020 at 6:15 PM Dave AA6YQ <@AA6YQ> wrote:

+ AA6YQ comments below

Contesters make extensive use of the CC User model (inserted infront of their context logging software) - or at least they did when I was involved a while back. If anyone's more sensitive to spot latency than DXers, it'd be contesters.

+ Have they measured the added latency and decided it was acceptable, or do they just employ CC User because they have no alternative?
I'm fairly sure that N1MM Logger[+] has/had its own spot filtering capabilities too... but I haven't been in that world for a while.

I see no reason to suspect that CC User would add more than a fraction of a second of latency. Do you have reason to believe that it would?

$ 50 years of professional hardware and software engineering have taught me that "guilty until proven innocent" is the appropriate outlook.

$ My concern with the unnecessary use of CC User is not latency, but rather unnecessary CPU and memory consumption, and "one more thing to break".

73,

Dave, AA6YQ


Re: VE7CC - Spot Source

iain macdonnell - N6ML
 

On Fri, Oct 16, 2020 at 6:15 PM Dave AA6YQ <@AA6YQ> wrote:

+ AA6YQ comments below

Contesters make extensive use of the CC User model (inserted infront of their context logging software) - or at least they did when I was involved a while back. If anyone's more sensitive to spot latency than DXers, it'd be contesters.

+ Have they measured the added latency and decided it was acceptable, or do they just employ CC User because they have no alternative?
I'm fairly sure that N1MM Logger[+] has/had its own spot filtering
capabilities too... but I haven't been in that world for a while.

I see no reason to suspect that CC User would add more than a fraction
of a second of latency. Do you have reason to believe that it would?

I doubt that anyone would attempt to measure it unless there was some
perception of it being a problem. I've never heard of such a
perception.

73,

~iain / N6ML


Re: VE7CC - Spot Source

Dave AA6YQ
 

+ AA6YQ comments below

Contesters make extensive use of the CC User model (inserted infront of their context logging software) - or at least they did when I was involved a while back. If anyone's more sensitive to spot latency than DXers, it'd be contesters.

+ Have they measured the added latency and decided it was acceptable, or do they just employ CC User because they have no alternative?

73,

Dave, AA6YQ


Re: VE7CC - Spot Source

iain macdonnell - N6ML
 

On Fri, Oct 16, 2020 at 5:29 PM Dave AA6YQ <@AA6YQ> wrote:

$ more AA6YQ comments below


% 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.

$ 1800 bytes/sec would not strain a dialup connection. When SpotCollector was first released in 2001, many users employed dialup connections.
There was no CW Skimmer in 2001. I'm starting to see obvious
robo-feeds of FT8 (etc.) spots now too.

I suppose we'll have to agree to disagree on the potential impact to a
marginal internet connection in a remote location.


% 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 :)

$ Without a network analyzer or access to source code, there's no way to know how much delay is being inserted.
Contesters make extensive use of the CC User model (inserted infront
of their context logging software) - or at least they did when I was
involved a while back. If anyone's more sensitive to spot latency than
DXers, it'd be contesters.


% 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.....

$ The addition of "pre-filtering" to SpotCollector is relatively recent. I suspect that anyone still using CC User with SpotCollector is doing so because they aren't aware of SpotCollector's new capability, not because they've determined that CC User's CPU and memory consumption are justified by the small reduction in internet bandwidth.
Perhaps. I don't have enough data to attempt a definitive determination on that.

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

Now it works again.
Pathfinder now shows: Emulation is consistent, Version 11, Emulation 11.

+ Good!

When the error occured the first time I searched in a help file for a solution and found the hint to "activate Internet Explorer Emulation", but I thought this would be a setting within the Internet Explorer -- so I had no chance to find such a setting :)


+ If you post the URL of the help file that suggested to "activate Internet Explorer Emulation", I will clarify the action to be taken.

73,

Dave, AA6YQ


Re: VE7CC - Spot Source

Dave AA6YQ
 

+ AA6YQ comments below

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.

+ Please try using SpotCollector's pre-filtering mechanism instead of CC User, and see if you notice any difference. On the "Spot Sources" tab of SpotCollector's Configuration window, click the "Pre-filter" button in the lower-right corner.

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

+ What seemed like a fire hose then is a trickle now.

73,

Dave, AA6YQ


Re: VE7CC - Spot Source

Dave AA6YQ
 

$ more AA6YQ comments below


% 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.

$ 1800 bytes/sec would not strain a dialup connection. When SpotCollector was first released in 2001, many users employed dialup connections.

% 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 :)

$ Without a network analyzer or access to source code, there's no way to know how much delay is being inserted.


% 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.....

$ The addition of "pre-filtering" to SpotCollector is relatively recent. I suspect that anyone still using CC User with SpotCollector is doing so because they aren't aware of SpotCollector's new capability, not because they've determined that CC User's CPU and memory consumption are justified by the small reduction in internet bandwidth.

73,

Dave, AA6YQ


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

Tom DF7TV
 

Thank you very much Dave!

Now it works again.
Pathfinder now shows: Emulation is consistent, Version 11, Emulation 11.

When the error occured the first time I searched in a help file for a solution and found the hint to "activate Internet Explorer Emulation", but I thought this would be a setting within the Internet Explorer -- so I had no chance to find such a setting :)

Great support, great software Dave!

73
Tom


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> 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