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.

41. Re: [RTTY] Decoder performance on crowded bands (score: 1)
Author: "Jim Hargrave" <w5ifp@gvtc.com>
Date: Wed, 30 Sep 2015 21:22:02 -0500
This thread has been enlightening to say the least, even if it is re-visited after each contest. It would be nice if everyone that has responded with "their opinions" would spend half that amount of
/archives//html/RTTY/2015-09/msg00197.html (9,537 bytes)

42. Re: [RTTY] Decoder performance on crowded bands (score: 1)
Author: Bill Turner <dezrat@outlook.com>
Date: Wed, 30 Sep 2015 19:29:08 -0700
-- ORIGINAL MESSAGE --(may be snipped) REPLY: As I said, you rarely if ever see it because most ops DO place an {ENTER} command at the start of each macro. Without the {ENTER} the problem would exist
/archives//html/RTTY/2015-09/msg00198.html (10,772 bytes)

43. Re: [RTTY] Decoder performance on crowded bands (score: 1)
Author: Bill Turner <dezrat@outlook.com>
Date: Wed, 30 Sep 2015 19:49:01 -0700
-- ORIGINAL MESSAGE --(may be snipped) REPLY: There is one other common cause for wrong frequency spots that has nothing to do with skimmers. Stations using AFSK often spot the suppressed carrier fre
/archives//html/RTTY/2015-09/msg00199.html (10,566 bytes)

44. Re: [RTTY] Decoder performance on crowded bands (score: 1)
Author: Gary Senesac <al9a@mtaonline.net>
Date: Wed, 30 Sep 2015 19:25:00 -0800
Jerry, I think you're a WriteLog user. If so that would explain why you don't see lines jumping up the screen. Wayne W5XD was very clever in his programming of the Rttyrite window - analogous to the
/archives//html/RTTY/2015-09/msg00200.html (10,600 bytes)

45. Re: [RTTY] Decoder performance on crowded bands (score: 1)
Author: Rick Ellison <rellison@twcny.rr.com>
Date: Thu, 1 Oct 2015 07:06:29 -0400
There is also a non-scrolling window in N1MM now. That was included from the start of the + version.. 73 Rick N2AMG Jerry, I think you're a WriteLog user. If so that would explain why you don't see l
/archives//html/RTTY/2015-10/msg00000.html (9,117 bytes)

46. [RTTY] Decoder performance on crowded bands (score: 1)
Author: Salvatore Irato <iw1ayd@gmail.com>
Date: Thu, 1 Oct 2015 14:32:48 +0200
Oh YES Lee! All this make it very clear, I suppose that from who is the originator of the entry there could be applied any further check about the skimmer in use. Perhaps what seemed to me is wrong .
/archives//html/RTTY/2015-10/msg00001.html (11,487 bytes)

47. Re: [RTTY] Decoder performance on crowded bands (score: 1)
Author: "Larry" <lknain@nc.rr.com>
Date: Thu, 1 Oct 2015 09:23:06 -0400
I saw several cases where the leading and/or trailing character of a call sign got clipped. Perhaps the skimmer is seeing something like that. We have had the discussion many times about how to minim
/archives//html/RTTY/2015-10/msg00002.html (12,668 bytes)

48. Re: [RTTY] Decoder performance on crowded bands (score: 1)
Author: Salvatore Irato <iw1ayd@gmail.com>
Date: Thu, 1 Oct 2015 18:34:33 +0200
Hi Larry. Yes, you are right. But I was supposing/speculating, maybe wrongly, that the latest RTTY skimmer is a little bit more prone to that kind of error. It seemed to me that the DL4RCK RTTY wasn'
/archives//html/RTTY/2015-10/msg00008.html (15,953 bytes)

49. Re: [RTTY] Decoder performance on crowded bands (score: 1)
Author: "Jim W7RY" <w7ry@centurytel.net>
Date: Sun, 4 Oct 2015 16:45:13 -0700
Indeed Rick... But for some reason, it doesn't work exactly the same as Writelog. I was a long time Writelog user, (at least 7 years) and it was great... the N1MM+ version is not the same. 73 Jim W7R
/archives//html/RTTY/2015-10/msg00020.html (11,732 bytes)


This search system is powered by Namazu