[RTTY] Decoder performance on crowded bands

Thu Oct 1 12:34:33 EDT 2015

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't all that
affected by this issue. But now under the light of what Lee wrote
maybe I am wrong. I am not a partisan of the DL4RCK skimmer, Walter
doesn't need mine advocacy. I was just mumbling about.

It could be that I am wrong, also as by now there are - again it seems
to me - more and more entries from the RDB than before the adoption of
the newest RTTY skimmer. As there are more RTTY skimmer mucking the
air and at an higher rate than before.
So, this statistically would mean that this kind of error is more
"visible" since the adoption of the latest RTTY skimmer than before.

>From another point of view, as Lee shortly described and showed, there
is at least  the ability to check all, more checks, with a quality,
sieve: the effectiveness of record correlation filters against several
kinds of call busting types. Besides the source of any record.
But not all the entries come from there and not all the entries will
trigger the finite rules sieve.
This could be not resolvable at short.
I am looking all just from my side and my windows could not fit the
whole scenario. I have to admit this.
By any mean the 20% of the efforts could solve the 80% of cases. But
the last 20% of case may require a not believable 80% of efforts.

                      73 de iw1ayd Salvo

PS BTW, as this could be solved o minimized by us, just going back to
the original question of the tread, the case of ...
IAMNOISE
TEST IW1AYD IW1AYD CQ IW1QN IW1QN IAMNOISE
... have no solution if not an easy solution. Have to force the code
to correlate back and forth could become not so simple. KIS.
A simple check about any call sign with a foregoing TEST or CQ will
keep on the right way.
So having the proper {TX}{ENTER(LF)}IW1AYD IW1AYD {RX} seems to be a
must. Isn't?

>
> Message: 6
> Date: Thu, 1 Oct 2015 09:23:06 -0400
> From: "Larry" <lknain at nc.rr.com>
> To: <rtty at contesting.com>
> Subject: Re: [RTTY] Decoder performance on crowded bands
> Message-ID: <064D21B8663849F8A07A4ABDBB5F1830 at XV2W>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
>         reply-type=original
>
> 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 minimize the chances of such
> clipping.
>
> 73, Larry  W6NWS
>
> -----Original Message-----
> From: Salvatore Irato
> Sent: Thursday, October 01, 2015 8:32 AM
> To: rtty at contesting.com
> Subject: [RTTY] Decoder performance on crowded bands
>
> 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 ... but anyway I was, not
> analytically, looking at the first file and those entries catches my
> eyes  ...
> -snip-
> 26-Sep 0041Z IW1RUA       14095.1 IW3RUA        9 W3OA-# RTTY
> 26-Sep 0041Z IW1RUA       14095.1 IW3RUA        8 W3OA-# RTTY
> -snip-
> 26-Sep 0041Z W1RUA        14095.1 *No License*  0 W3OA-# RTTY
> 26-Sep 0041Z W1RUA        14095.1 *No License*  0 W3OA-# RTTY
> -snip-
> (I don't remember what is one digit number before the skimmer callsign
> ... quality?)
> Him was IW3RUA, I am quite sure. Forked also it as was for W1AYD that
> I have seen many times on my same QRG over the bandmap lately ... :-)
> BTW IW1RUA doesn't exist ... to my knowledge of IW1 licensee.
> Out of yours excellent work and information, Lee, I would think that
> there is some "smuggling" ... or a very fringe path specific to that
> case.
> In your case, Lee, those W1 calls didn't get the way to be cluster
> wide relayed. But sometimes as I have seen W1AYD it may have followed
> another patch, a "smuggling" path, isn't?
>
> Really not that problem as it could be the way as GRITTY or/and an
> experienced operator may "brain filter" the bandmap. That's part of
> ours personal operating style and possibly of software integration.
> Each are not that easy ...
> Not all the rules could be stoned, not all the stoned rules are the
> best. Software and statics sometimes may not be on the same way. Just
> in case.
>
>
>                        73 de iw1ayd Salvo
>
>
> PS Jumping to other topics ... There are two more questions, that I
> may triggered, but those already received responses. Still I would
> like to ad some words on the subjects ...
>
> The {ENTERLF} is coming from ASR as I am and it is more appealing for
> me ... isn't? Taking care to rule that small lever on the left
> "bumper" of the latest models, i.e. ASCII ASR33.
>
> The tail ending CQ is also appealing as I say after my call that I am
> CQing, not responding to anyone. Who is coming onto HAG21AYD IW1AYD
> could equivocate on what I am doing there.
> The same as for the TU: HISCALL TU IW1AYD CQ. I am ready for another
> contact.
> Not QRZ, as I need fresh call in, no idea or store of anyone other.
> Having it I will coming back
> with TU NOW ...
>
> So I have to agree with Don, from witch I learned the most in the hope
> to apply it right, Rick, that helped me a lot of times, and others
> from witch I constantly learn here.
>
>> Message: 2
>> Date: Wed, 30 Sep 2015 19:19:01 -0600 (MDT)
>> From: Lee Sawkins <ve7cc at shaw.ca>
>> To: rtty at contesting.com
>> Cc: dezrat at outlook.com
>> Subject: [RTTY] Skimmer spots dropped at VE7CC cluster node
>> Message-ID: <716460089.84737880.1443662341911.JavaMail.root at shaw.ca>
>> Content-Type: text/plain; charset=utf-8
>>
>> These links may be interesting to some of you. These are the typical
>> rejected spots of any CC Cluster.
>>
>> RTTY skimmer spots are considered valid if spotted by ONE Skimmer. RTTY
>> Skimmers are generally more accurate than CW and there are simply not
>> enough of them to use 2 or more Skimmers to validate them. CW spots are
>> valid if spotted by 2 or more Skimmers.
>>
>> Here is the list of dropped Skimmer spots by the VE7CC-1 cluster.
>> If you connect to the RBN directly, you will receive all these spots as
>> well as the good ones.
>>
>> Many times there are two calls in succession that are dropped for RTTY
>> calls. I am receiving data from both the RBN and DL4RCK for redundancy.
>> Usually they both spot the same RTTY calls.
>>
>> Most columns are self explanatory.
>>
>> The number directly before a skimmer call is a quality number. It is the
>> number of times a call has been detected as correct minus the number of
>> times it is busted. When the number decreases below 5, it is no longer
>> considered valid. If the active call has not been spotted in 12 minutes it
>> is also no longer considered valid. In one place, for 9A1A the quality
>> number is over 2000. This means 9A1A has been spotted over 2000 times on
>> the same frequency!
>> "Sysop added" means I have manually added a call to the list because it is
>> busted all the time and is never good.
>>
>> http://www.bcdxc.org/ve7cc/ccc/Busted-26-Sep-2015.txt
>> http://www.bcdxc.org/ve7cc/ccc/Busted-27-Sep-2015.txt
>>
>> Lee
>>