Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[RTTY\]\s+Decoder\s+performance\s+on\s+crowded\s+bands\s*$/: 49 ]

Total 49 documents matching your query.

1. [RTTY] Decoder performance on crowded bands (score: 1)
Author: Tim Shoppa <tshoppa@gmail.com>
Date: Mon, 28 Sep 2015 10:25:41 -0400
Wow, there was a lot of activity for CQ WW RTTY! 20M and 15M were filled completely between 080-150kc above band edge, The "bottom ends" of the band were particularly crowded. I used 3 decoders simul
/archives//html/RTTY/2015-09/msg00082.html (9,084 bytes)

2. Re: [RTTY] Decoder performance on crowded bands (score: 1)
Author: Don AA5AU <aa5au@bellsouth.net>
Date: Mon, 28 Sep 2015 19:42:47 +0000 (UTC)
Tim wrote: "The frequency resolution and accuracy seems to have improved in the skimmers in the past few years and often times I would click on a spot and be tuned within 10Hz, that is great!" Yes, i
/archives//html/RTTY/2015-09/msg00092.html (13,244 bytes)

3. Re: [RTTY] Decoder performance on crowded bands (score: 1)
Author: "Jeff AC0C" <keepwalking188@ac0c.com>
Date: Mon, 28 Sep 2015 14:48:07 -0500
Don, I ran Alex Skimmer Server on a local QS1R in the WPX earlier this year and the results were hard to believe. Performance was exceptional. And the benefit is that 100% of the spots are workable b
/archives//html/RTTY/2015-09/msg00093.html (14,674 bytes)

4. Re: [RTTY] Decoder performance on crowded bands (score: 1)
Author: "David G3YYD" <g3yyd@btinternet.com>
Date: Mon, 28 Sep 2015 15:56:54 -0500
Tim Interesting comments. I wonder which decoder or was it decoders you were using in 2Tone? They are there for a purpose. I normally run two 2Tones per DI one with selective decoder and the other wi
/archives//html/RTTY/2015-09/msg00095.html (10,292 bytes)

5. Re: [RTTY] Decoder performance on crowded bands (score: 1)
Author: Pete Smith N4ZR <n4zr@contesting.com>
Date: Mon, 28 Sep 2015 17:09:40 -0400
One potential step toward improved RTTY Skimserv results is to use the CT1BOH "skimquality" filters available through AR Cluster V6. See <http://reversebeacon.blogspot.com/2013/12/a-new-tutorial-on-u
/archives//html/RTTY/2015-09/msg00107.html (16,399 bytes)

6. Re: [RTTY] Decoder performance on crowded bands (score: 1)
Author: Lee Sawkins <ve7cc@shaw.ca>
Date: Mon, 28 Sep 2015 23:58:19 -0600 (MDT)
-- Original Message -- Tim You were implying that something is wrong with my node's default filtering. Your own filtering at the VE7CC-1 cluster node was last updated Dec 14, 2014. Your country filte
/archives//html/RTTY/2015-09/msg00124.html (9,528 bytes)

7. Re: [RTTY] Decoder performance on crowded bands (score: 1)
Author: Pete Smith N4ZR <n4zr@contesting.com>
Date: Tue, 29 Sep 2015 07:02:31 -0400
Jeff, I'd be interested to know to what you attribute the reduction in the number of S&P mis-spots. Is it simply because with many Skimmers spotting this year, the chance of someone mistakenly spotti
/archives//html/RTTY/2015-09/msg00127.html (17,168 bytes)

8. Re: [RTTY] Decoder performance on crowded bands (score: 1)
Author: Tim Shoppa <tshoppa@gmail.com>
Date: Tue, 29 Sep 2015 18:37:46 -0400
Wow, thanks for all the responses! Most especially to Lee VE7CC himself, who helped me figure out how to reset a filter I had apparently applied over a year ago (probably by clicking on the "NE ONLY"
/archives//html/RTTY/2015-09/msg00144.html (10,677 bytes)

9. Re: [RTTY] Decoder performance on crowded bands (score: 1)
Author: "WW3S" <ww3s@zoominternet.net>
Date: Tue, 29 Sep 2015 18:57:57 -0400
What I think usually happens is the skimmer cannot tell the difference between who is who.....so since most people now append their CQ message with CQ, it goes like this.... CQ AA5AU AA5AU CQ and the
/archives//html/RTTY/2015-09/msg00147.html (8,802 bytes)

10. Re: [RTTY] Decoder performance on crowded bands (score: 1)
Author: Gary Senesac <al9a@mtaonline.net>
Date: Tue, 29 Sep 2015 16:18:03 -0800
Quick fix. Don't send the 'DE' before your call. It is absolutely unnecessary! Gary AL9A Sent from my Kindle HDX What I think usually happens is the skimmer cannot tell the difference between who is
/archives//html/RTTY/2015-09/msg00150.html (9,235 bytes)

11. Re: [RTTY] Decoder performance on crowded bands (score: 1)
Author: Lee Sawkins <ve7cc@shaw.ca>
Date: Tue, 29 Sep 2015 18:58:30 -0600 (MDT)
Jamie How sending this. "{enter}WW3S WW3S ". Maybe this would break the association between the CQ from AA5AU and you better and not spot you. I seem to rarely get spotted during S&P and this is what
/archives//html/RTTY/2015-09/msg00151.html (10,296 bytes)

12. Re: [RTTY] Decoder performance on crowded bands (score: 1)
Author: Lee Sawkins <ve7cc@shaw.ca>
Date: Tue, 29 Sep 2015 19:08:15 -0600 (MDT)
Oops .... Correction I meant to say: How about sending this. "{enter}WW3S WW3S ". etc -- Original Message -- Jamie How sending this. "{enter}WW3S WW3S ". Maybe this would break the association betwee
/archives//html/RTTY/2015-09/msg00152.html (10,709 bytes)

13. Re: [RTTY] Decoder performance on crowded bands (score: 1)
Author: "Joe Subich, W4TV" <lists@subich.com>
Date: Tue, 29 Sep 2015 21:12:30 -0400
'T would not be a problem if you started your DE WW3S WW3S message with <CR><LF> The skimmers would then see two different calls/stations 73, ... Joe, W4TV On 9/29/2015 6:57 PM, WW3S wrote: What I th
/archives//html/RTTY/2015-09/msg00153.html (10,003 bytes)

14. Re: [RTTY] Decoder performance on crowded bands (score: 1)
Author: Michael Adams <mda@n1en.org>
Date: Wed, 30 Sep 2015 03:45:22 +0000
The last time I rewrote my collection of RTTY contest macros (about a year ago?), I thought that the consensus on best practice was to use CRLF's sparingly, only at the start of a CQ, in order to be
/archives//html/RTTY/2015-09/msg00155.html (9,229 bytes)

15. Re: [RTTY] Decoder performance on crowded bands (score: 1)
Author: "Jeff AC0C" <keepwalking188@ac0c.com>
Date: Wed, 30 Sep 2015 00:32:33 -0500
Pete, Sorry for the confusion. Let me expand a bit... I dont' have much battle-experience running assisted; just the one time WPX 2014 run. I ran my local skimmer server setup here fed by my antenna
/archives//html/RTTY/2015-09/msg00156.html (19,439 bytes)

16. Re: [RTTY] Decoder performance on crowded bands (score: 1)
Author: "john@kk9a.com" <john@kk9a.com>
Date: Wed, 30 Sep 2015 07:03:05 -0400
Not only is it a waste of time, DE can be a source of error. More than once last weekend the state did not decode and the DE did, leading me to believe that the station I was working was in Delaware.
/archives//html/RTTY/2015-09/msg00158.html (8,952 bytes)

17. Re: [RTTY] Decoder performance on crowded bands (score: 1)
Author: Don AA5AU <aa5au@bellsouth.net>
Date: Wed, 30 Sep 2015 13:47:42 +0000 (UTC)
According to Pete's (N4ZR) post today, "{enter}WW3S WW3S" is suppose to break the association from the CQ but it doesn't appear to be true in some cases. Putting a C/R L/F {enter} in front of nearly
/archives//html/RTTY/2015-09/msg00160.html (12,462 bytes)

18. Re: [RTTY] Decoder performance on crowded bands (score: 1)
Author: "David G3YYD" <g3yyd@btinternet.com>
Date: Wed, 30 Sep 2015 10:33:15 -0500
One way of eliminating the problem is to analyse the previous text. So if received was CQ M7T M7T CQ AA5AU AA5AU there is sufficient information to parse the text to realise the CQ is by M7T and the
/archives//html/RTTY/2015-09/msg00161.html (13,458 bytes)

19. Re: [RTTY] Decoder performance on crowded bands (score: 1)
Author: Jerry Flanders <jeflanders@comcast.net>
Date: Wed, 30 Sep 2015 10:56:43 -0400
I use spaces exclusively. Beginning and end of every macro. I wish everyone did. You won't read DTEGJW4UKEW5 when I sign my call, _and_ your print won't scroll up. Jerry W4UK At 11:45 PM 9/29/2015, M
/archives//html/RTTY/2015-09/msg00162.html (11,003 bytes)

20. Re: [RTTY] Decoder performance on crowded bands (score: 1)
Author: Tim Shoppa <tshoppa@gmail.com>
Date: Wed, 30 Sep 2015 11:00:50 -0400
It's interesting that in my original post, I said I wanted as little filtering on skimmed spots as possible - something VE7CC was quick to help me with. When my run rate slows down, I do not mind cli
/archives//html/RTTY/2015-09/msg00163.html (10,516 bytes)


This search system is powered by Namazu