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

486Baud rate (was Re: [Q15X25] Re: Kantronics, Kam XL)

Expand Messages
  • Jose A. Amador
    Jan 9, 2007
      The efforts I am seeing might indicate that we are attempting to bite a
      bit too large....

      On one side, the reports that Q15X25 works better at 2300 baud, and that
      the 100 baud packet mode incorporated into MultiPSK works when 300 baud
      does not looks like a hint to go at lower speeds and bandwidths, and at
      least match the expected thruput of 300 baud packet, reliably. It is a
      pity that only some AEA TNC's could go below 300 baud, and that it did
      not become popular. Greed or carelessness? Cannot tell, but the results
      are there for all to see.

      I have been a witness that Pactor II and III are better alternatives
      than 300 (and HF 1200 baud) packet, with some 10 times the thruput.

      SCS has achieved to better protect the data in transit, starting with
      their old "memory ARQ", and using adaptative techniques, like switching
      in more complex constellations (Pactor II with 2 carriers) or more
      carriers with no more complex constellations than DQPSK, starting with
      as few as 2 carriers, and going up to as many as 16, depending on the
      channel quality. It is complex and has a price, but works quite well.

      Should a faithful copy be made? Guess not, including the avoidance of
      patent infringements, but there are salient points in display for all to
      see. Adaptativity and data protection seem to be the key.

      The behavior with Q15X25 seem to follow this pattern, using slower
      speeds if it is more reliable, and avoiding the filters passband edges.

      In a multicarrier environment, it is wise to confine them in the
      flattest propagation delay portion of the passband. The edges do not
      have this desirable property.

      It is important to go as fast as POSSIBLE to catch band openings and
      move traffic, but with an eye in EFFICIENCY, neither that fast that the
      water spills out of the bucket, neither that slow that it takes an
      eternity to fill it up. With 300 baud packet, most of the water was
      spilled outside (endless retries....remember?)....

      It is better (for moving BBS traffic) to have one drop falling INTO the
      bucket for a day than a large hose with large pressure bouncing the
      water on the bottom of the bucket spilling it all over the place for a
      short while (wasting bandwidth). The good choice seems to be an average
      of those extreme conditions. Transmitting data, and not live voice, you
      are not forced to some minimum transmission speed. Just use the one that
      DELIVERS the most.

      The HF channel is a variable one. In good years we can move to higher
      frequencies, as close to the MUF multipath diminishes or dissapears, but
      regional nets with the required path geometries do not enjoy these
      benefits.

      And yes, the trend in the times we are living is using PC's and sound
      cards, as it is versatile and somehow, affordable. Making it open
      software may allow some worthwhile contributions and a shorter
      development time.

      I have seen one similar solution: Using smaller motherboards with less
      power hungry processors (VIA, etc) allows the development to be done in
      the PC and ported to a smaller and less power hungry box, powered from a
      DC-DC converter. It seems to be the fashion nowadays. There are non ham
      networks in South America (and possibly Africa) being built that way.

      The AEA hardware solution saw the light in 1988....almost 20 years ago.
      And at the pace the development goes nowadays, and the attitudes we are
      seeing (life is hard and short, I am not criticizing anyone), it looks
      that those boxes are history.

      Once again, pactor channel access solutions seem to show the way. You
      can go with a single speed for all links in a shared channel, like in
      wire (X.25 was born in that environment) on VHF/UHF, but on HF all paths
      in a network won't show the same quality, so you cannot use the single
      speed shared channel efficiently for all, neither a mix of speeds on a
      shared channel seems to be a viable solution so far. So peer to peer
      links at the highest EFFICIENT speed (maximizing ALLOWABLE thruput, not
      HOPING the highest theoretical one to be AVAILABLE always) seem to be
      the solution. It is the way the HF, ham side of the link works in
      Winlink 2000.

      Could a viable mimic of that be achieved?


      Jose, CO2JA


      PS: Daydreaming....perhaps...even a mixture of those ideas with ALE and
      an SDR....

      Second...could we be able to live with variable bandwidth, adaptive
      digital transmissions in our ham bamds without quarreling among us?

      Sorry for the crossposting, but to me, it seems interesting for both groups.

      Ken wrote:
      > Well some bad news today after so long a effort of trying to get this
      > damn mode into current technology like the Kam XL.
      >
      > A response from Tomi to my request to have the mode properly
      > documented so developers like Kantronics could include it in their
      > TNC range.
      >
      > ---
      >> Do you have a more up to date Q15X25 technical description
      >> available
      > please? (Last release received 2005-07-20).
      >
      > Sorry to say but no. I have mosty forgotten the whole modem as I
      > haven't used it and I don't think anyone else does either... At least
      > I haven't heard from anyone.
      >
      > Unless I get a sudden inspiration to document stuff, I probably won't
      > update it any more. ---
      >
      > So it seems we are at a dead end again. :( Most disapointing. I have
      > been chasing this since 2005! :(
      >
      > OK So whats next? We still need a newer faster mode for HF that is
      > ax25 / packet compatable for our existing networks.
      >
      > Any idea's? The big issue I see is having something that we can get
      > the TNC manufacturers to include. A mode that is within the
      > capability of some of the latest hardware like the Kam XL's etc.
      >
      > My only other idea is to abandon triditional TNC technology and go
      > down the path of using Embedded PC boards with USB sound card dongles
      > and linux. While this would offer more mode flexability and access
      > to a better supported software base it's main limitations are these
      > devices are generally power hungry which is bad news for field apps
      > like solar sites and digi's etc.
      >
      > Any idea's anyone?
      >
      > ~Ken - VK4AKP .-.-.
      >
      > --- In Q15X25@yahoogroups.com <mailto:Q15X25%40yahoogroups.com>, kd4e
      > <kd4e@...> wrote:
      >>
      >>> Jose A. Amador wrote: Could I suggest that PAX/PAX2 be considered
      >>> as candidate modems formats?
      >>
      >> There is no point to either -- they are costly proprietary formats
      >> -- contrary to good sense and Ham tradition.
      >>
      >> Many manufacturers have tried the proprietary mode idea and all
      >> have failed. Kantronics among them, more recently joined by Alinco,
      >> Kenwood, and Icom's competing VHF/UHF digital and linking schemes.
      >>
      >> Ham radio needs a non-proprietary foundation same as in the
      >> Internet realm, e.g. IEEE 802.11 and others.
      >>
      >> We need a robust format that is 100% non-proprietary:
      >>
      >> 1. All of the code is published and anyone is allowed to base apps
      >> on it.
      >>
      >> 2. No exclusive source hardware requirement.
      >>
      >> 3. Cross-OS platform compatible -- Apple, Linux, and MS.
      >>
      >> Only then will we have something likely to earn the support of the
      >> majority of digital mode Ham ops and only then can we move into the
      >> digital mode future working together vs divided and making
      >> inefficient use of fragmented development resources.
      >> --
      >>
      >> Thanks! & 73, doc, KD4E ... somewhere in FL URL: bibleseven (dot)
      >> com
    • Show all 15 messages in this topic