486Baud rate (was Re: [Q15X25] Re: Kantronics, Kam XL)
- Jan 9, 2007The 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
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
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
Could a viable mimic of that be achieved?
PS: Daydreaming....perhaps...even a mixture of those ideas with ALE and
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.
> 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
> 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)
- << Previous post in topic