RE: [Q15X25] Applications for use with newqpsk?
Good. Yes I have been in contact with Roland (author of Digtrx). It uses the
same RDFT DLLs and is a very good way to get familiar with RDFT.
From: Stephane Riviere [mailto:stephane@...]
Sent: Sunday, May 09, 2004 06:32 AM
Subject: Re: [Q15X25] Applications for use with newqpsk?
Hi Rick & all.
> Here is the site for all the info on Barry Sanderson's RDFT (previouslyThanks. An other link to a ready to go windows program using Barry
> called hdsstv) work.
Sanderson's RDFT. May be useful to quickly test RDFT ?
The page is mostly in brazilian, but the software is in english.
Oleron Island - France
Yahoo! Groups Links
- --- 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