RE: [Q15X25] Why so sensitive about SCS?
I agree with your comments. I was not so much defending SCS as their right
to do what ever they please as a company. It seems like too often hams (all
of us) expect every company or programmer to donate their intellectual
property. While noble that is not often in the best interest of
The ARQ protocol I am working on is intended (as many ARQ protocols) for
unattended operation....or at least semi unattended operation as is done in
Winlink 2000. In Winlink the automated station (BBS or PMBO) is the
unattended one and NEVER initiates a connection...it only responds to
connect requests from remote stations which (in the case of AirMail or
Paclink ...two clients for Winlink 2000) are always manned. This does not
of course solve the remaining problem of the hidden transmitter (hidden to
the station initiating the connection) that could possibly be interfered
with by the BBS station. However I plan to include some level of busy
detection in the final implementation that will detect at least certain
classes of channel activity. In practice this is not a perfect solution but
having run a HF BBS for almost 8 years my experience is the vast majority of
interference issues can be classified into two categories having little to
do with the hidden transmitter issue.
1) Poor operating practice on the station initiating the connection calling
on top of an existing connection or otherwise busy channel. This
unfortunately is not limited as we know to digital modes...poor operating
practice is just that.
2) Adjacent channels using improper (bandwidth) for reception. A common
example of this is PSK 31 (a 50-100Hz bandwidth mode) running wide-open
panoramic receivers (4 KHZ) while complaining about adjacent channel Pactor
or RTTY stations killing their QSO. I like PSK and use it myself but once
you start a PSK QSO you should narrow down the receiver to the proper
bandwidth and this avoids most of what is called "Pactor interference". You
don't find CW or RTTY operators running 4 KHZ of receiver bandwidth...and
you also never hear complaints from them about adjacent channel
interference. Trying to carry on a QSO in a narrow mode with a panoramic
receiver is again just poor operating practice. Virtually all modern
receivers have (or have optional) narrow filters that can be set to the
correct bandwidth for the intended mode.
There is also a proposal at the ARRL which I understand they intend to
present to the FCC about restructuring the band plan allowing voluntary
segmentation by bandwidth not mode. This would group similar bandwidth modes
in similar segments.
I think this type of structure is very important if we are to see any real
innovation from the sound card modes. It is just not practical to keep
adjusting the rules according to mode when you have so many sound card and
digital voice modes being developed.
Your comments and suggestions on this are appreciated.
From: Mark Miller [mailto:kramrellim@...]
Sent: Tuesday, May 11, 2004 06:42 AM
Subject: [Q15X25] Why so sensitive about SCS?
I was wondering why you were defending SCS, I understand now after visiting
winlink.org. I am certainly not defending KAM in any way. You brought up
KAM as a comparison to SCS. SCS nor KAM will never make a product with the
success of the sound card modes as long as the protocol will not even be
licensed. It is simple economics. The soundcard modes may even be
inferior to SCS's Pactor II and Pactor III, but soundcard modes will and
have been widely accepted because they are free or nearly free, and perform
very well. KAM modems and SCS modems are too expensive. Your GTOR example
is very true. GTOR failed, not because it was inferior, it failed because
of a failed marketing approach. Lets put CLOVER in that same category. I
congratulate you on working hard on a viable sound card protocol that will
be open for all to improve on.
Since your background is with Winlink2000, is this new soundcard ARQ setup
also supposed to run unattended? If so, how do you plan to satisfy
§97.101 (d)? It has been 10 years since PR-Docket 94-69 was released and
still no "novel technical and operational approaches to the use of shared
frequency bands" by unattended stations have made the scene.
At 06:37 PM 5/10/2004, you wrote:
>No one prevented Kantronics from coming out with their own protocol and a
>better cheaper version of a PTC II....no one except Kantronics! Kantronics
>sat on the KAM technology and milked it for almost 10 years while the rest
>of the world went DSP and computer prices fell as performance went
>you can buy a pretty powerful DSP chip for 10 bucks and a KAM (which worksto
>no better than the 10 year old model) still costs over $400. Let's not
>blame SCS for making a profitable business and not giving away the rights
>Pactor II or III. The problem is there is no competition because the hamperformance
>market is not that big or profitable and competition is the ONLY thing that
>will bring aggressive pricing. Kantronics only innovation GTOR was a total
>afterthought and amounted to not much more than using binary compression.
>Hams are going to have to understand that if you want the higher
>today's technology (hardware and software) can deliver you have only a fewgive
>1) Learn how to use and apply the technology yourself and be willing to
>that knowledge away.to
>2) Pay those that are willing to invest and risk their own time and money
>make such products.to
>I am working hard on a viable sound card protocol and initial test results
>are encouraging. I encourage others to join in and contribute if we want
>try and advance the technology and generate a competitive marketplace.
- --- In Q15X25@yahoogroups.com, Mark Miller <kramrellim@c...> wrote:
>I have an idea that would solve this problem (busy detection)
> I understand that it must be a very complex task to develop a busy
> detection scheme.
definatively by simply staying on the air. - The transmitter operates
A. Is that legal?
I would use multiple psk streams, each sending a multicast signal
a'la John Hansen W2FS's "RadioMirror" protocol. If you are familiar
with RadioMirror, the following will make sense:
Each psk stream would send from a seperate data block, each working
it's way through all the available data blocks as usual for
RadioMirror. By staggering these data streams time-wise, they provide
rapid updates and fills for each other, and at the same time ups the
overall throughput. Remember that with multicast, "throughput" is
measured in how fast you can get the entire set of data blocks across
to many stations, intact and entire.
It's a lot like EMWIN, but taken to the next step.
RadioMirror provides fills by retransmitting all the data over and
over again, in serial fashion. Using multiple psk streams would allow
this same process to occur in parallel fashion. (much faster)
RadioMirror utilizes a KISS TNC, and so is limited to using 1k
packets, with some off-the-air time. Using multiple psk streams,
there would be no reason for the transmitter to ever unkey. The data
stream could flow uninterrupted, continuously.
John Hansen talks about a single, serial RadioMirror data stream at
1200 baud being capable of moving 20 megabytes a day... Psk streams
would of course go at a much slower baud rate, but being multiple
streams that do not have to pause and break every 1k, I think that
this psk/multicast do-dad could pump an impressive amount of data.
Couple that with the fact that the transmitted data is not point-to-
point, dedicated to a single station but multicast instead, being
distributed to an unlimited number of receiving stations over an
enormous geographical area, and you are looking at data transfer on
HF that leaves everything currently available very, very far behind.
Yes, that would include PACTOR III. Nothing that operates point-to-
point come come close.
More streams = faster pumping... I'd want the server's number of psk
streams to be optional (1-15) and the client to automatically adjust
to the number of streams received.
For emergency communications, a continental-scale data distribution
system like this would be of obvious value.
I forgot to suggest that the server also run the client software,
updating it's files from another server on another band or freq.
Networking these critters would expand their capability yet again.
B. Is this technically feasable?
C. Anybody want to put on their asbestos gloves and code it?
To get an idea of how multicast works, as opposed to the point-to-
point stuff we currently use, imagine this: In a room full of people,
you pass around a note that says "point-to-point", waiting until it
finally gets around to everybody. - Then hold up a sign that everone
can see at once that says "Multicast".
( A fair comparasin would have some of the folks making copies of the
data, which would speed up the process some - but not enough
The bigger the room, the more contrast you see. Now think about the
overall coverage area of an HF transmission on 20 meters. That's a
really big room.
BTY - There is some info about RadioMirror at http://www.uspacket.net