Loading ...
Sorry, an error occurred while loading the content.

RE: [Q15X25] Applications for use with newqpsk?

Expand Messages
  • Rick Muething
    Stephane, 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. Rick
    Message 1 of 32 , May 9 4:34 AM
    • 0 Attachment
      Stephane,

      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.

      Rick KN6KB


      -----Original Message-----
      From: Stephane Riviere [mailto:stephane@...]
      Sent: Sunday, May 09, 2004 06:32 AM
      To: Q15X25@yahoogroups.com
      Subject: Re: [Q15X25] Applications for use with newqpsk?


      Hi Rick & all.

      > Here is the site for all the info on Barry Sanderson's RDFT (previously
      > called hdsstv) work.

      Thanks. An other link to a ready to go windows program using Barry
      Sanderson's RDFT. May be useful to quickly test RDFT ?

      http://planeta.terra.com.br/lazer/py4zbz/hdsstv/teste1.html#digtrx

      The page is mostly in brazilian, but the software is in english.

      --
      Stephane Riviere
      Oleron Island - France
      http://stephane.rochebrune.org





      Yahoo! Groups Links
    • Charles Brabham
      ... I have an idea that would solve this problem (busy detection) definatively by simply staying on the air. - The transmitter operates continuously,
      Message 32 of 32 , May 21 7:37 AM
      • 0 Attachment
        --- In Q15X25@yahoogroups.com, Mark Miller <kramrellim@c...> wrote:

        >
        > I understand that it must be a very complex task to develop a busy
        > detection scheme.

        I have an idea that would solve this problem (busy detection)
        definatively by simply staying on the air. - The transmitter operates
        continuously, year-round.

        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
        obviously. )

        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.

        Charles, N5PVL

        BTY - There is some info about RadioMirror at http://www.uspacket.net
      Your message has been successfully submitted and would be delivered to recipients shortly.