[Skimmertalk] SSB + Skimmer idea

[David Robbins]

Most of that can be handled by specifications required to be used in the
transmitter in order to be spotted.
1. require specific fixed cw speed.  This simiplifies the skimmer problem
since it doesn't have to figure out the speed
2. require specific tone frequency in the audio.  This should make the
proper frequency to spot obvious.
3. require a 'cq' or 'test' in the message to satisfy the keyword
requirement of the skimmer software
4. require the cw only be sent with your cq voice recording
5. skimmers already can filter so they have to hear the same call two or
more times on the same frequency

The bandwidth of skimmers can be increased as hardware improves so wider
bands can be covered, or periodic scanning of bandsegments as is already
possible with the aggregator ini file switcher could be used.  And of course
the throughput of the rbn will have to be increased regularly as more
skimmers come on line anyway, the rtty skimmer server would be only a small
blip compared to what might be possible with voice mode skimmers!



David Robbins K1TTT
e-mail: mailto:k1ttt at arrl.net
web: http://wiki.k1ttt.net
AR-Cluster node: 145.69MHz or telnet://k1ttt.net


-----Original Message-----
From: Skimmertalk [mailto:skimmertalk-bounces at contesting.com] On Behalf Of
Pete Smith N4ZR
Sent: Wednesday, December 10, 2014 13:29
To: Edward Kritsky; skimmertalk at contesting.com
Subject: Re: [Skimmertalk] SSB + Skimmer idea

Speaking only for myself, not on behalf of the RBN team, I'm opposed to the
idea, for a number of reasons:

CW Skimmer/Skimmer Server  software would require significant modifications.

VE3NEA is about to release RTTY Skimmer Server, which will massively
increase the amount of RBN traffic.  Even the current level strains the
capability of logging software and cluster servers.

SDRs currently in use have maximum coverage range of ~180 KHz. Phone bands
are much wider.

Intelligibility of fast CW will be dependent on audio adjustments, unless
transmitters are switched to CW, and then different radios will differ in
what frequency they transmit CW on, with the same VFO setting. 
If MCW is used, quality will depend on audio settings, and may not be legal
in many countries. Very high-speed CW is more vulnerable to QRM/QRN, so bust
rate will be greatly increased.

Most logging software does not distinguish running from S&P. CW Skimmer
relies on repetition of callsigns and presence of keywords in transmissions
to identify CQers and reduce rate of miscopies.  How much overhead of this
sort is desirable in phone transmissions?

Depending on multiple logging programs to generate the CW on many different
radios risks a real tower of babel. Right now, we have one Skimmer, one
Aggregator, multiple receiver types.  This is already hard to support.

73, Pete N4ZR
Check out the Reverse Beacon Network at
http://reversebeacon.net,
blog at reversebeacon.blogspot.com.
For spots, please go to your favorite
ARC V6 or VE7CC DX cluster node.

On 12/7/2014 5:25 PM, Edward Kritsky wrote:
> Dear Skimmertalk,
>
> Together with my friend, Yuri, UA3ATQ, we came up with an interesting 
> idea on how to identify SSB stations in contests using skimmer 
> technology.
>
> All of the elements are currently present out there and require no or 
> minimal modifications
>
> 1. Radios
> 2. Computers
> 3. Skimmers
> 4. Spotting networks
>
> What needs to be modified would be logging software to enable 
> additional radio station identification.
>
> How?
>
> The idea is to identify stations by transmitting CW ID at high rate of 
> speed (at maximum speed that skimmers can accept), at intervals that 
> would be determined by the operator's behaviour (CQing vs. searching).
> CW ID should not be set to tax outside ops' hearing and would be for 
> skimmers only (although I would not exclude humans entirely).
>
> Logging program would send an ID based on what the op is doing.
>
> There is some trial and error needed to set this in motion - how often 
> should ID be sent, how fast, on what sideband (to correspond to the 
> operating SSB frequency). The op should have a choice of turning it on 
> and off, not to slow him or others down, not to cut into his 
> transmissions etc. Operator's action should have precedence over 
> logging program actions. When ID has not been sent in its entirety, 
> skimmer should ignore it or wait for a successful re-identification.
>
> I'm sure there is a bit of intelligent analysis required on how to 
> make this work for everyone. CW ID can be very short (fraction of a 
> second), it would not slow things down, it (hopefully) would not be 
> viewed as an annoyance (unlike an end-transmission beep in the 
> commercial world)
>
> In my view, it needs to be experimented with before it becomes a 
> mainstream, in or out of contests
>
> What we have seen in CQ WW CW contest with skimmers basically changed 
> how we operate, where we operate and how stations are spotted. Perhaps 
> this is an easy and inexpensive way of bringing this technology to 
> SSB. I don't think FCC should object since maximum allowable CW speed 
> is not an issue - transmitting station identifies itself in voice 
> anyway.
>
> I'm not a member of this forum, so if you wish to reply to my posting, 
> my email address is on the bottom of this message
>
> It would be great to get this off the ground
>
> de Dave, K1TTT: One other consideration is the bandwidth of the 
> existing skimmers. Most are only skimming the bottom 96khz or at most 
> 192khz of the bands, so making wider bandwidths or shifting them for 
> phone contests would be necessary. Some do scan the bands on a 
> schedule so that might be a possibility also.
>
> 73 to all,
>
> Ed Kritsky/NT2X
> Brooklyn, NY

_______________________________________________
Skimmertalk mailing list
Skimmertalk at contesting.com
http://dayton.contesting.com/mailman/listinfo/skimmertalk