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

RE: [Q15X25] Why so sensitive about SCS?

Expand Messages
  • Rick Muething
    Mark, 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
    Message 1 of 32 , May 11, 2004
    • 0 Attachment
      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.


      Rick KN6KB

      -----Original Message-----
      From: Mark Miller [mailto:kramrellim@...]
      Sent: Tuesday, May 11, 2004 06:42 AM
      To: Q15X25@yahoogroups.com
      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.


      Mark N5RFX

      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 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
      >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
      >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
      >that knowledge away.
      >2) Pay those that are willing to invest and risk their own time and money
      >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
      >try and advance the technology and generate a competitive marketplace.
      >Rick KN6KB
    • 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.