Date
1 - 8 of 8
Locked How is it that FT/x modes are being spotted as CW on spotting networks? #WSJTX_config
|
I have noticed that many reports submitted to the spotting networks have incorrectly categorized FT/x mode signals as CW. Is there any hope of preventing this frequent mistake and quieting down the inaccurate noise this creates in the cluster system? It makes FT users/spotters look kind of like LIDS when this keeps happening...
-KA1IOR |
|
|
|
Bob Turner
Your problem is the opposite of mine. I've tried for years to not see CW spots, but could not achieve that with 100% accuracy. I believe spotting networks determine mode by frequency, so the mode may not be accurate. Someone could put the mode in the comment, but that would not be 100% reliable as some folks won't.
toggle quoted message
Show quoted text
7 3 Bob N2SCJ -----Original Message-----
From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Geoff Way Sent: Sunday, December 26, 2021 12:26 PM To: main@WSJTX.groups.io Subject: [WSJTX] How is it that FT/x modes are being spotted as CW on spotting networks? #WSJTX_config I have noticed that many reports submitted to the spotting networks have incorrectly categorized FT/x mode signals as CW. Is there any hope of preventing this frequent mistake and quieting down the inaccurate noise this creates in the cluster system? It makes FT users/spotters look kind of like LIDS when this keeps happening... -KA1IOR |
|
|
|
Joe Subich, W4TV
The cluster networks "assume" operating mode based on frequency.
toggle quoted message
Show quoted text
They do not have sufficient "smarts" to differentiate between modes when the SPOTTER does not include the MODE in the comments. IOW, the cluster software is brain dead - particularly for "JT mode" operations away from the "standard frequencies". 73, ... Joe, W4TV On 2021-12-26 12:25 PM, Geoff Way wrote:
I have noticed that many reports submitted to the spotting networks have incorrectly categorized FT/x mode signals as CW. Is there any hope of preventing this frequent mistake and quieting down the inaccurate noise this creates in the cluster system? It makes FT users/spotters look kind of like LIDS when this keeps happening... |
|
|
|
Joe, I agree that the RBN can be pretty "brain dead", but I'm having trouble swallowing the idea that a CW-decoding system is somehow locking onto and identifying an FT/x mode signal as CW. There has to be something wrong in the FT/x spotting system/mechanism.
|
|
|
|
How on earth is the logic of declaring what mode a report is purely on the basis of frequency ever going to have any accuracy? Folks can run CW on pretty much ALL frequencies, and FT users are drifting well below .075 up from the bottom end of the band. Guaranteed to become a bigger and bigger mess...
|
|
|
|
HamApps Support (VK3AMA) <vk3ama.ham.apps@...>
On 27/12/2021 9:28 am, Joe Subich, W4TV wrote:
The structure of a cluster spot, "^" delinted text, does not have facility for recording the mode, thus determining the mode is left to guessing based on frequency or by extracting from spot notes. eg. "18079.9^VK3AMA^1272029820^comment^AX3AMA^8^95^VK3AMA-2^41^21^45^25^^" de Laurie VK3AMA |
|
|
|
Dave AA6YQ
Unfortunately, the worldwide DX spotting network has never included the spotted station's "mode" as an always-present data item in each spot - like callsign or frequency.
toggle quoted message
Show quoted text
SpotCollector, a component of the free-ware DXLab Suite that aggregates DX spots from up to 4 DX Clusters, the DX Summit web cluster, and local instances of WSJT-X to maintain a realtime database with one Entry for each active station, employs two techniques which in combination achieve reasonably accuracy with respect to mode: 1. If a spot's notes specify a mode, that mode is assigned to the database Entry. 2. If a spot's notes do not specify a mode, an included sub-band definition file is consulted to determine the mode based on the spot frequency; each entry in the sub-band definition file specifies a lower frequency, an upper frequency, and a mode. Sub-band usage during contests can vary significantly from non-contest usage. Users can create their own custom sub-band definition files, and choose the one most appropriate for each operating session. SpotCollector also mines spot notes for IOTA, POTA, SOTA, and WWFF tags. 73, Dave, AA6YQ -----Original Message-----
From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Bob Turner Sent: Sunday, December 26, 2021 5:21 PM To: main@WSJTX.groups.io Subject: Re: [WSJTX] How is it that FT/x modes are being spotted as CW on spotting networks? #WSJTX_config Your problem is the opposite of mine. I've tried for years to not see CW spots, but could not achieve that with 100% accuracy. I believe spotting networks determine mode by frequency, so the mode may not be accurate. Someone could put the mode in the comment, but that would not be 100% reliable as some folks won't. 7 3 Bob N2SCJ -----Original Message----- From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Geoff Way Sent: Sunday, December 26, 2021 12:26 PM To: main@WSJTX.groups.io Subject: [WSJTX] How is it that FT/x modes are being spotted as CW on spotting networks? #WSJTX_config I have noticed that many reports submitted to the spotting networks have incorrectly categorized FT/x mode signals as CW. Is there any hope of preventing this frequent mistake and quieting down the inaccurate noise this creates in the cluster system? It makes FT users/spotters look kind of like LIDS when this keeps happening... -KA1IOR -- This email has been checked for viruses by AVG. https://www.avg.com |
|
|
|
Joe Subich, W4TV
There has to be something wrong in the FT/x spotting system/mechanism.The only thing "wrong" is that the *CLUSTER SOFTWARE* /ASSUMES/ that any spot not in the "phone" bands is CW unless the spot contains the mode in its comments. The better software includes the digital mode in the comments but most "manually" entered spots fail to include mode - whether that is JT65, JT9, FT8, FT4, RTTY, PSK31, PSK63, PSK125, etc. The Cluster system needs a "frequency map" for 3540-3650, 7040-7100, 10130-10150, 14050-14125, 18090-18110, 21050-21150, 24900-24930 and 28050-28200 with all of the common "centers of activity" (both primary and secondary). DXLab Suite's SpotCollector includes such a "map" and it catches 80%+ of the digital activity ... the big issue being FT8 F/H operations that can be misidentified as RTTY and RTTY contest activity that can be identified as FT8, FT4 or JT65/JT9 at times. 73, ... Joe, W4TV On 2021-12-26 5:37 PM, Geoff Way wrote: Joe, I agree that the RBN can be pretty "brain dead", but I'm having trouble swallowing the idea that a CW-decoding system is somehow locking onto and identifying an FT/x mode signal as CW. There has to be something wrong in the FT/x spotting system/mechanism. |
|
|