RE: [Q15X25] Applications for use with newqpsk?
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 up....Now
you can buy a pretty powerful DSP chip for 10 bucks and a KAM (which works
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 to
Pactor II or III. The problem is there is no competition because the ham
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 performance
today's technology (hardware and software) can deliver you have only a few
1) Learn how to use and apply the technology yourself and be willing to give
that knowledge away.
2) Pay those that are willing to invest and risk their own time and money to
make such products.
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 to
try and advance the technology and generate a competitive marketplace.
From: Mark Miller [mailto:kramrellim@...]
Sent: Monday, May 10, 2004 01:56 PM
Subject: RE: [Q15X25] Applications for use with newqpsk?
Yes but this is amateur radio, many would like to roll their own, and that
is not possible with Pactor II and Pactor III.
A KAM can't do P II and P III because KAM is not licensed to use it. That
is kind or an artificial bargain, don't you think?
At 06:57 PM 5/9/2004, you wrote:
>Yes of course but the other side of the coin is Pactor II and III work fararguably
>better than Pactor I and SCS builds a reliable box and support it well with
>continual firmware upgrades. Comparatively the PTC IIex at $700 is
>a better bargain than a $450 KAM.
- --- 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