Re: Linux Packet Interface Hardware

[Dave Platt <dplatt@radagast.org>]

> There are some advantages at 6PACK, but they relate to time of real
> serial ports, not USB virtual devices that run at 500 or 20 000 times
> the speed of 1200 bps packet...
> 
> But then we hams tend to prefer running with _old_ hardware instead of
> doing something truly smart.  A GMSK modulation and some sort of FEC
> coding would be smart, but as it is incompatible with 1960es landline
> audio modulation used for 1200 bps packet, such ideas will never gain
> any use.

Several ideas intermixed here, so I have several comments.

I think that there are probably two different "markets" which could be
addressed by improvements to ham packet technology... but which may
need technology which is significantly different in detail.

(1) End-users - individual hams, who want to add some amount of
    packet connectivity to an otherwise-already-functioning station.

    Having to buy expensive TNCs, and (especially) expensive new data
    radios, is a non-starter for most of these people.  Solutions
    which can use their existing radio hardware are preferred.  This
    often means "mic/speaker interface to an FM radio".

    May operate mobile or portable (or, at least, with mobile or portable
    radios and TNC setups - not necessarily moving around), with simple
    or impromptu antennas.

(2) Base stations, backbones, infrastructure - stations which are generally
    fixed in location, operating over a longer period of time, with
    significant investment in the equipment, antennas, computers, and
    the setup and optimization of all these things.

Now... with regard to your specific suggestions...

Forward error correction seems like an excellent idea, no matter what
the lower-level modulation is - it could cut packet retransmissions down
by quite a lot.  It would be beneficial if the specific parameters for
the FEC were somewhat adjustable, and were explicitly identified in the
packet headers - this would allow operation under a range of different
error rates and correction levels.  Given the interference and dropout
behaviors seen on VHF and UHF, you'd want to use a significant amount
of data interleaving, with a correction-block size large enough that
a single noise burst or multipath-flutter wouldn't knock out too many
bits to allow error correction to occur.

Reed-Solomon EC is well understood and free code seems to be available.
More effective correction could probably be achieved via a turbo-code
system (perhaps with a flexible puncturing algorithm) but I'm not sure
about the patent status of turbo codes... we wouldn't want to create
another AMBE-like licensing debacle!

Systems using sophisticated error-correction coding might best be
implemented in the PC itself, with the the "TNC" mostly driving the
radio itself.  The interface between the PC and the "TNC" might just
be frames or packets filled with bits, with the PC doing all of the
actual frame-detection and error correction.

My understanding is that current 9600 bit/second ham packet isn't
too far from being GMSK in its design?

I've read a lot which believes me to believe that GMSK, and similar
single-carrier modulations have a significant vulnerability to
multipath interference.  Ham 9600 packet has been notorious for
this... works rather better with highly-directional antennas than
with spray-and-bounce omnis.  Some digital land-mobile deployments
I've heard about, have had serious problems with picket-fencing
when the mobile station is... well, mobile... and have had to deploy
additional base stations to improve signal coverage.

So, I think there might be merit in pursuing two different
approaches to improving performance:  one for casual hams and
mobile operation (standard-FM-radio-compatible) and one for
infrastructure/backbone use.

For base/backbone use, adding FEC to the current 9600-bit
protocol could help.  I think there's already some sort of data
scrambler in use, to try to help with the low-frequency-content
issue, but perhaps it could be improved... or maybe a trellis-
coded QAM16 or some such modulation could be used to enforce
a low average DC offset.

For improved audio-radio-compatible performance... I've long been
a fan of DMT (discrete multi-tone), OFDM, and other modulations in
this family.  Back in the late 1980s, the Telebit Trailblazer modems
were a very successful niche product - probably the most popular
way of tying together Unix/Linux systems over phone lines.  They
could manage to maintain a 9600-bit/second connection (half duplex)
over lousy, scratchy overseas land lines and satellite links, when
industry-standard V.32 models would just gasp and choke and disconnect.
I swear, the Telebits would work over two tin cans and a length of
damp string.

I don't know the the fine details of their protocols, but do recall
that they were a DMT system, with several hundred individual carriers
spaced evenly across the voice-band spectrum.  Each carrier was
modulated (QPSK or QAM?) at a relatively low rate - around 7 baud
I think.  The protocol was point-to-point, and adaptive - each modem
could tell its peer which carrier frequencies were working well,
and which were noisy or attenuated.  I believe they applied FEC to
the data prior to modulation.

I'd love to see a ham-packet modulation based on this sort of
technology.  It's probably something which could be made compatible
with the soundmodem framework.

I recall reading that somebody was working on a system somewhat
like this for HF packet use - a protocol called SCAMP.  I think it
died on the vine, although it's possible that some of its ideas were
picked up by newer versions of WinLink.

As to compatibility with current ham TNCs and nodes... well, clearly,
it's tricky.  I think it'd probably be desirable to treat the new
modulations a bit like Ethernet, in that they could carry multiple
higher-level protocols within appropriate framing structures.  We
could carry AX.25 (e.g. as BPQEther), or TCP/IP, or jump right to
IPv6.  If I recall correctly, this is the approach D*Star has
taken... it uses Ethernet framing.

This could allow backwards compatibility with existing ham
infrastructures, while still allowing advances and the use of
better high-level protocols on the same frequencies (and on the
same systems!).

As I understand it, essentially all of the ham packet systems
in use today still implement AX.25 2.0 (which dates back to the
mid-1980s).  The effort in the late 1990s to create a newer
revision (AX.25 2.2) doesn't seem to have come to much.

1200-baud packet and the TNC-2 infrastructure is probably
like crabgrass and FORTRAN - we'll never be free of them, and will
always have to deal with them in one way or another.

> One related USB interface issue is that there is no specification for
> serial port!  All that exist are proprietary chip vendor specific things.
> (Unless something has crept up during last month.)

Yup.  It really annoys me that the USB consortium didn't specify standard
device-class interfaces for serial ports, parallel ports, and
network adapters *years* ago!