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

Re: [Q15X25] Applications for use with newqpsk?

Expand Messages
  • Jason Buchanan
    ... hi - I ve had a handful of contacts with this mode - perhaps when you get it going we can try some contacts. I have mixw and no linux capability (don t
    Message 1 of 32 , May 1, 2004
    • 0 Attachment
      ve7it wrote:

      >Greetings,
      >The posts look pretty slim on this group. I am working on setting up
      >Thomas's usermode soundmodem under FC1. I got as far as running the
      >diags in soundmodemconfig. Is there a web site or can someone give me
      >a hand understanding what front end applications talk with the user
      >mode sound modem and what I need to do to get far enough to get "hello
      >world" sent out using the newqpsk modem. I dont need help with the
      >radio interfacing or PTT circuits, just how to use /dev/soundmodem0 or
      >/dev/sm0 or /dev/ax0 or ????.
      >I am really hoping that the newqpsk modem code can be used as a
      >replacement for the closed pactor protocols. I would love to be able
      >to retrieve email on 80 meters while sitting around the campfire!.
      >
      >

      hi - I've had a handful of contacts with this mode - perhaps when you
      get it going we can try some contacts. I have mixw and no linux
      capability (don't have a spare machine) to run it in linux.


      73 Jason N1SU
    • 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, 2004
      • 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.