Linux Packet Interface Hardware

Linux Packet Interface Hardware

[Jim Kusznir]

Hi all:

I'm in the process of designing some kinda-embedded applications that
will need to employ packet "compatibility layers" to allow access of
packet radios.

In one application, I'm proposing relacing a node stack with a linux
box, some interface (subject of this e-mail), and the existing radios
with their audio (discriminator if appropriate), tx line, squelch
line, etc.  Other applications may not be as demanding as the nodes,
but similar.  In essence, I'm looking for a device to connect to the
equivalent of the 6-pin mini-din connector used for "data" on most
modern radios and linux.

I'm familiar with the state of the art back in the late '90's.  I also
realize that not a lot has necessarily changed since then....
However, I suspect something may have.

the solution should be capable of running several different packet
interfaces, and at 9600 or 1200 baud.  These interfaces should turn
into linux axX interfaces.

I know one solution is to get modern TNCs (such as the PK-96, etc),
and either put them in kiss mode or replace the rom with a KISS-only
rom.  I know that linux can do sound card packet as well.  However,
I'm wondering if there's something inbetween.  I'm not entirely
against the sound card TNC option, but have some questions as to the
robustness and performance of such a system.  Also, its likely in my
implementation that I'd be using usb audio adapters to provide the
sound card.  And I want to do 9600 baud with them.  Of course, there's
also the how-to-key-the-transmitter problem as well.

I see in the linux kernel support for YAM and some others; are any of
these viable solutions?  Anything else to recommend?

Thanks!
--Jim, K7LL

Re: Linux Packet Interface Hardware

[Ray Wells]

Jim,

If I may comment on the YAM. I have one of these and it works quite well 
at 9k6 under Debian 4.0.

Today, however, there is no support for the YAM and purchasing the PCB 
may be an impossible task.

My general preference is for TNC's running a KISS only EPROM although my 
Baycom USCC>4 card (1x0k3, 2x1k2 and 1x9k6 modem) works very well. It's 
the original ISA version. A PCI version was also produced.

Ray vk2tv

Jim Kusznir wrote:
> Hi all:
>
> I'm in the process of designing some kinda-embedded applications that
> will need to employ packet "compatibility layers" to allow access of
> packet radios.
>
> In one application, I'm proposing relacing a node stack with a linux
> box, some interface (subject of this e-mail), and the existing radios
> with their audio (discriminator if appropriate), tx line, squelch
> line, etc.  Other applications may not be as demanding as the nodes,
> but similar.  In essence, I'm looking for a device to connect to the
> equivalent of the 6-pin mini-din connector used for "data" on most
> modern radios and linux.
>
> I'm familiar with the state of the art back in the late '90's.  I also
> realize that not a lot has necessarily changed since then....
> However, I suspect something may have.
>
> the solution should be capable of running several different packet
> interfaces, and at 9600 or 1200 baud.  These interfaces should turn
> into linux axX interfaces.
>
> I know one solution is to get modern TNCs (such as the PK-96, etc),
> and either put them in kiss mode or replace the rom with a KISS-only
> rom.  I know that linux can do sound card packet as well.  However,
> I'm wondering if there's something inbetween.  I'm not entirely
> against the sound card TNC option, but have some questions as to the
> robustness and performance of such a system.  Also, its likely in my
> implementation that I'd be using usb audio adapters to provide the
> sound card.  And I want to do 9600 baud with them.  Of course, there's
> also the how-to-key-the-transmitter problem as well.
>
> I see in the linux kernel support for YAM and some others; are any of
> these viable solutions?  Anything else to recommend?
>
> Thanks!
> --Jim, K7LL
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hams" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>   

Re: Linux Packet Interface Hardware

[Matti Aarnio]

On Tue, Jun 15, 2010 at 04:43:45PM -0700, Jim Kusznir wrote:
> 
> Hi all:
> 
> I'm in the process of designing some kinda-embedded applications that
> will need to employ packet "compatibility layers" to allow access of
> packet radios.
> 
> In one application, I'm proposing relacing a node stack with a linux
> box, some interface (subject of this e-mail), and the existing radios
> with their audio (discriminator if appropriate), tx line, squelch
> line, etc.  Other applications may not be as demanding as the nodes,
> but similar.  In essence, I'm looking for a device to connect to the
> equivalent of the 6-pin mini-din connector used for "data" on most
> modern radios and linux.
> 
> I'm familiar with the state of the art back in the late '90's.  I also
> realize that not a lot has necessarily changed since then....
> However, I suspect something may have.
> 
> the solution should be capable of running several different packet
> interfaces, and at 9600 or 1200 baud.  These interfaces should turn
> into linux axX interfaces.

I would suggest making it an USB device with "BPQether" type of interface.
At USB level it would look like a _generic_ ( = no extra drivers )
ethernet, but it would understand only BPQether type of packets, and
therefore would not get to transmit just anything that system happens
to send on its way.

There would be need for unique serial numbers ( = "mac address" ) for
the devices.  Anything would be good as long as first byte of MAC
address has its lowest bit clear (the multicast indicator)
(Even prefix "BPQ" = 0x42, 0x50, 0x51 )

See  "man bpqparams" for the control interface.

To implement a control command channel, like to set ptt delays, etc.
that could be an AX.25 frame with destination call of 'NOCALL' (the
classical misconfiguration token) and an UI frame with control data.
Speed would be fixed, but nothing prevents having multiple virtual
ethernet interfaces in same USB device, each with their own speeds.

As a bonus, this same hardware could be plugged on Windows as well
without any special drivers.  If the settings are correct, then on
windows a BPQ32 suite will be able to drive it too - and you get
even more people interested in that device.

> Thanks!
> --Jim, K7LL

73 de Matti, OH2MQK

Re: Linux Packet Interface Hardware

[Dave Platt]

> I know one solution is to get modern TNCs (such as the PK-96, etc),
> and either put them in kiss mode or replace the rom with a KISS-only
> rom.  I know that linux can do sound card packet as well.  However,
> I'm wondering if there's something inbetween.  I'm not entirely
> against the sound card TNC option, but have some questions as to the
> robustness and performance of such a system.  Also, its likely in my
> implementation that I'd be using usb audio adapters to provide the
> sound card.  And I want to do 9600 baud with them.  Of course, there's
> also the how-to-key-the-transmitter problem as well.
> 
> I see in the linux kernel support for YAM and some others; are any of
> these viable solutions?  Anything else to recommend?

Just some comments, based on my own fiddling-around over the past
few years.

First meta-comment:  I'd strongly suggest that you review the information
at

	http://www.scc-ares-races.org/packet.html

and consider getting in touch with Michael N6MEF and Fish K6FSH, two
of the lead packet guys in our area.  They and others have been doing
a really major re-work of the packet network that we use for ARES/RACES
support here in Santa Clara County... upgrading from a single BBS to
a multi-node backbone, switching to newer TNCs and radios, and using
Linux for a lot of the infrastructure.  We're also making a lot of use
of the "Outpost" front-end software developed for us by Jim KN6PE
(written up in QST in April of last year)... this does not run natively
on Linux, alas (I'm considering both WINE and VirtualBox solutions, as
well as a native Outpost work-alike of some sort)

I've used traditional command-line TNCs with Linux, as well as KISS-mode
(both a TNC-2 with a KISS-only replacement ROM, and a TNC-X), and
have used soundmodem in several versions on several different PCs.  Each
has its advantages and disadvantages.

Using the Linux AX.25 kernel stack can be immensely convenient, since
it allows you to drive many different sorts of TNCs, and to write
all sorts of Linux-based AX.25 clients and servers in almost any
language you want.  It ought to be possible (for example) to write
a sophisticated packet-radio client or gateway in Perl.

However, using the kernel AX.25 stack is not without its gotchas.

There seems to be a quirk in the way that the kernel handles
AX.25 connection timers, which I think may lead to less-than-ideal
behavior under conditions of network congestion.  The quirk is
this:  the T1 (lost-packet retransmit) timer is started at the time
that the kernel's packet layer hands the current set of frames off
to the driver (hardware or KISS) to be transmitted... *not* at the
time when the driver has actually transmitted them.  Under congested
network conditions, this can result in the T1 timer expiring before
the frames have even been transmitted by the radio... and this leads
to possibly-unnecessary frame retransmissions.

As I read the code, this is going to affect *all* AX.25 packet
drivers.  I think it *might* be possible to correct it for those
packet drivers which actually interface directly with the radio
hardware (e.g. Baycom, Z8560SCC) and for 6Pack.  I don't think
it's possible to correct it at all for KISS, since the KISS protocol
doesn't include any sort of "OK, I sent it!" feedback from the TNC
to the host.

This is an annoyance, but probably not a severe problem... the
kernel's code to estimate round-trip time (and adjust the T1
timer setting accordingly) ought to adapt to the presence of
congestion, use a longer T1 timer in the future, and the extra
retransmissions will not occur (or will occur less frequently).

Now... as far as specific modem/TNC types and hookups go...
you've got a bunch of choices.

Probably the most obvious is the first you've considered...
KISS hookups to traditional TNCs, over serial ports.  Clean,
simple, pretty scalable (you may want something like an
8-serial-port USB adapter), and your transmission and reception
quality will be as good as each TNC's modem will provide.  You
may be able to re-use many of your existing TNCs for this,
and keep the cost down.  This is probably the most straightforward
approach.

A variant on this would be talking to a bunch of TNCs over
a single serial port using 6Pack.  I don't know how many TNCs
support this protocol, though.

TNC or radio interfaces which require tight CPU interaction
with the hardware (e.g. Baycom) are probably a Really Bad
Idea for your application... not scalable.

Running multiple soundmodems, over multiple sound interfaces...
yes, this should be possible.  For 1200-baud AFSK, most decent
sound interfaces ought to work reasonably well once you get the
levels set properly.  Using USB audio adapters may well work
OK... I don't know how many a single USB interface will be able
to support without suffering from dropouts or other glitches.
You might need to hack on the soundmodem code in order to
provide some sort of shared-PTT capability (e.g. setting
individual bits on the parallel port) to control individual
radios' PTT lines).  You could probably use multiple SignaLink USB
adapters - these seem to have good audio quality, and have their
own built-in VOX-based PTT circuit.

You'll want to use the ALSA drivers for talking to such USB
audio devices.  Make sure you've got a current version of the
soundmodem program (0.13, I think?) - older versions didn't
implement all of the "start" and "stop" calls in the ALSA API
quite right, and could lock up on some ALSA devices.

For 9600-baud... well, you'd be on more uncertain territory there.
I don't think the 9600-baud FSK support in the soundmodem has been
used anywhere near as much as the 1200-baud support, and I haven't
heard anything about its actual performance.  I understand that
9600 FSK requires very flat frequency response of the data channel
(down to fairly near DC), and simple USB-audio adapters designed
for driving headphones may roll off at too high a frequency due
to too-small DC-blocking capacitors.  VOX-based PTT control might
not work well (hard to get the hang-time adjusted properly, to
allow fast turnaround of the radio channel, without dropping
out inappropriately).

Do consider the fact that each soundmodem process is going to
be chewing up CPU cycles constantly (well, when receiving, at
least) even when there's no traffic.  A good modern CPU can
probably handle quite a few of these (e.g. an Atom) but
at the cost of using somewhat more electricity than if the CPU
were idling and just waiting for input from a KISS TNC.  This
might or more not be more power than a stack of TNCs would use.

The soundmodem code does have one AX.25 quirk you ought to be
aware of.  When sending two or more AX.25 frames in a single
transmission, it tends to violate the recommendation in section
2.2.11 of the AX.25 spec:

  2.2.11 Interframe Time Fill

  Whenever it is necessary for a DXE to keep its transmitter on while
  not actually sending frames, the time between frames should be filled
  with contiguous flags.

The actual behavior of the soundmodem is to send one flag at the
end of the current frame, then insert between zero and seven 0-bits,
and then send another flag to begin transmission of the next frame.

This has the effect (seven times out of eight) of inserting a short,
invalid frame between two good ones.  Most TNCs will simply detect the
runt frame and silently discard it.  A very few (e.g. the TNC-X with
its original firmware) will lose HDLC sync, won't be re-sync'ed properly
by the second flag, and will end up missing the second real frame.  I
understand that the revised firmware for the TNC-X is better at handling
these not-quite-as-recommended AX.25 transmissions by the soundmodem.

I hope that this semi-random brain dump has been of some slight use!

73,

	Dave AE6EO

Re: Linux Packet Interface Hardware

[Curt, WE7U]

LOTS of good info Dave!  A couple of minor comments:

On Tue, 15 Jun 2010, Dave Platt wrote:

> For 9600-baud... well, you'd be on more uncertain territory there.
> I don't think the 9600-baud FSK support in the soundmodem has been
> used anywhere near as much as the 1200-baud support, and I haven't
> heard anything about its actual performance.  I understand that
> 9600 FSK requires very flat frequency response of the data channel
> (down to fairly near DC), and simple USB-audio adapters designed
> for driving headphones may roll off at too high a frequency due
> to too-small DC-blocking capacitors.

Another thing to watch is whether the PLL in the transmitter you're
using tries to compensate for the low-frequency audio.  Many
PLL-based radios will try to do this, screwing up the transmission.
I used to have a 9600 baud modem hooked to an ICOM IC-27A and it
definitely had that problem.  Even some "9600-baud ready" radios
with the modem connector on the back might have this sort of
problem.


> The actual behavior of the soundmodem is to send one flag at the
> end of the current frame, then insert between zero and seven 0-bits,
> and then send another flag to begin transmission of the next frame.

Note that the 0 bits are a disadvantage for the reasons mentioned,
but they're an advantage for the purpose of getting more clock
transitions to sync up with at the receive side.  If it weren't for
the extra short packet in there that some devices create it would be
much better to have a sequence of 0-bits than flags.  This is
especially important for the first part of a transmission when the
receiver is attempting to sync up to the transmit clock:  With
0-bits you can often use a shorter TXD at the transmit side yet
still get the receiver to sync before the data starts across.  It
might also be important in lower S/N conditions.

-- 
Curt, WE7U.                         <http://www.eskimo.com/~archer>
    APRS:  Where it's at!                    <http://www.xastir.org>
   Lotto:  A tax on people who are bad at math. - unknown
Windows:  Microsoft's tax on computer illiterates. - WE7U.
The world DOES revolve around me:  I picked the coordinate system!"

Re: Linux Packet Interface Hardware

[Jim Kusznir]

Thanks everyone, lots of good info!

A few questions:

I've seen a few references to 6-pack, and know that its a "special
firmware" that one would load on the TNCs...But I can't seem to find
that firmware anywhere.  Does anyone know where I can actually get it,
and find info about what TNCs it supports?

It seems that for hardware available today, the recommendation for
infrastructure use is to use a TNC in KISS or 6-pack mode.  I've been
using one at home in KISS mode for a while, and I've been noticing
what I think now is the T1 timer problem, and its been causing very
frustrating and massive reduction in throughput on my local 9k6
channel, even though my radio and the node are the only two on
frequency!  I often see my system try and send retransmits before the
first packet ever even makes it out the radio (but on the other hand,
I also think my TNC is sitting on packets way too long -- PacComm
Spirit-2).  I am contemplating replacing the firmware chip with a
KISS-only or 6-pack firmware chip and see what that does, if I can
find one for this TNC.

As to new installations, does anyone recommend a 9k6 TNC for a good
cost/performance metric that can be used with linux effectively?  It
should be external, as the embedded hardware I'm likely to run it on
will not have PCI slots, and definitely will NOT have ISA slots.

I like the ideas about a BPQether USB device; from the description,
though I gather one has not been made to date?  I'm curious, and I'll
keep this in mind for a potential CE/EE project here (School of EECS,
WSU and the W7YH Amateur Radio Club).

The information on sound modems is well taken; I think I'll limit that
deployment to end-user stations in my planning.

Thanks all for the ideas/input.  I think the BPQether driver best fits
what I was hoping to find, except for the fact that it doesn't exist
off-the-shelf yet....

--Jim

On Wed, Jun 16, 2010 at 5:45 AM, Curt, WE7U <curt.we7u@gmail.com> wrote:
>
> LOTS of good info Dave!  A couple of minor comments:
>
> On Tue, 15 Jun 2010, Dave Platt wrote:
>
>> For 9600-baud... well, you'd be on more uncertain territory there.
>> I don't think the 9600-baud FSK support in the soundmodem has been
>> used anywhere near as much as the 1200-baud support, and I haven't
>> heard anything about its actual performance.  I understand that
>> 9600 FSK requires very flat frequency response of the data channel
>> (down to fairly near DC), and simple USB-audio adapters designed
>> for driving headphones may roll off at too high a frequency due
>> to too-small DC-blocking capacitors.
>
> Another thing to watch is whether the PLL in the transmitter you're
> using tries to compensate for the low-frequency audio.  Many
> PLL-based radios will try to do this, screwing up the transmission.
> I used to have a 9600 baud modem hooked to an ICOM IC-27A and it
> definitely had that problem.  Even some "9600-baud ready" radios
> with the modem connector on the back might have this sort of
> problem.
>
>
>> The actual behavior of the soundmodem is to send one flag at the
>> end of the current frame, then insert between zero and seven 0-bits,
>> and then send another flag to begin transmission of the next frame.
>
> Note that the 0 bits are a disadvantage for the reasons mentioned,
> but they're an advantage for the purpose of getting more clock
> transitions to sync up with at the receive side.  If it weren't for
> the extra short packet in there that some devices create it would be
> much better to have a sequence of 0-bits than flags.  This is
> especially important for the first part of a transmission when the
> receiver is attempting to sync up to the transmit clock:  With
> 0-bits you can often use a shorter TXD at the transmit side yet
> still get the receiver to sync before the data starts across.  It
> might also be important in lower S/N conditions.
>
> --
> Curt, WE7U.                         <http://www.eskimo.com/~archer>
>   APRS:  Where it's at!                    <http://www.xastir.org>
>  Lotto:  A tax on people who are bad at math. - unknown
> Windows:  Microsoft's tax on computer illiterates. - WE7U.
> The world DOES revolve around me:  I picked the coordinate system!"
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hams" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux Packet Interface Hardware

[Curt, WE7U]

On Wed, 16 Jun 2010, Jim Kusznir wrote:

> I've been
> using one at home in KISS mode for a while, and I've been noticing
> what I think now is the T1 timer problem, and its been causing very
> frustrating and massive reduction in throughput on my local 9k6
> channel, even though my radio and the node are the only two on
> frequency!  I often see my system try and send retransmits before the
> first packet ever even makes it out the radio (but on the other hand,
> I also think my TNC is sitting on packets way too long -- PacComm
> Spirit-2).

Tweak your KISS parameters.  If there are only two on frequency then
you can increase your p-persistence quite a bit and perhaps decrease
your slottime.

-- 
Curt, WE7U.                         <http://www.eskimo.com/~archer>
    APRS:  Where it's at!                    <http://www.xastir.org>
   Lotto:  A tax on people who are bad at math. - unknown
Windows:  Microsoft's tax on computer illiterates. - WE7U.
The world DOES revolve around me:  I picked the coordinate system!"

Re: Linux Packet Interface Hardware

[Matti Aarnio]

On Wed, Jun 16, 2010 at 09:16:29AM -0700, Jim Kusznir wrote:
> Thanks everyone, lots of good info!
> 
> A few questions:
> 
> I've seen a few references to 6-pack, and know that its a "special
> firmware" that one would load on the TNCs...But I can't seem to find
> that firmware anywhere.  Does anyone know where I can actually get it,
> and find info about what TNCs it supports?

  http://www.baycom.org/bayweb/tech/tnc/firmware.htm
  http://www.symek.com/g/tnc2firmware.html
  http://www.flexnet.be/main/Firmware.htm

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.

> It seems that for hardware available today, the recommendation for
> infrastructure use is to use a TNC in KISS or 6-pack mode.  I've been
> using one at home in KISS mode for a while, and I've been noticing
> what I think now is the T1 timer problem, and its been causing very
> frustrating and massive reduction in throughput on my local 9k6
> channel, even though my radio and the node are the only two on
> frequency!  I often see my system try and send retransmits before the
> first packet ever even makes it out the radio (but on the other hand,
> I also think my TNC is sitting on packets way too long -- PacComm
> Spirit-2).  I am contemplating replacing the firmware chip with a
> KISS-only or 6-pack firmware chip and see what that does, if I can
> find one for this TNC.

Existing firmwares are available mainly for TAPR TNC2 clones.

I did recently search for source code of KISS firmware - and did find it
from my local archive.  Trying to get it to compile with some modern
Z80 compiler existing on UNIX is entirely different scale of adventure,
and I haven't done that yet completely..

  ftp://ftp.funet.fi/pub/ham/packet/tapr/kissv7.zip

I am trying to get that compiled with sdcc's z80 assembler, but...
there are a number of syntax differences, and available assembler syntax
documentation isn't clearest.. (neither original Z80, nor sdcc-as-z80)

I would like to improve that with two ways:
  - Strict transmission queue timeout of N seconds (10-15 seconds)
  - CRC on KISS frames (SMACK or FLEXNET way)

The first one is needed for avoiding packets to wait too long in Tx queue
waiting for silence on channel and thus tx permit.  The second one is
always a good idea.


> As to new installations, does anyone recommend a 9k6 TNC for a good
> cost/performance metric that can be used with linux effectively?  It
> should be external, as the embedded hardware I'm likely to run it on
> will not have PCI slots, and definitely will NOT have ISA slots.
> 
> I like the ideas about a BPQether USB device; from the description,
> though I gather one has not been made to date?  I'm curious, and I'll
> keep this in mind for a potential CE/EE project here (School of EECS,
> WSU and the W7YH Amateur Radio Club).

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.)

However there are good abstractions for ethernet-like devices, and
for some reason I didn't like "modem" specifications when I looked
at them a while back -- I think because they don't seem to offer
"packet oriented" interface, whereas "ethernet" does have that.
But I could remember wrong...

> The information on sound modems is well taken; I think I'll limit that
> deployment to end-user stations in my planning.
> 
> Thanks all for the ideas/input.  I think the BPQether driver best fits
> what I was hoping to find, except for the fact that it doesn't exist
> off-the-shelf yet....

Not even off-the-lab...
To be seen if I have time for the project this summer - an NXP LPC2368
with USB device interface, and a couple CML MX164 modems..
I made the hardware last summer, but didn't have time for the software.

> --Jim

73 de Matti, OH2MQK

Re: Linux Packet Interface Hardware

[Dave Platt]

Curt, WE7U wrote:
> 
> LOTS of good info Dave!  A couple of minor comments:

> Another thing to watch is whether the PLL in the transmitter you're
> using tries to compensate for the low-frequency audio.  Many
> PLL-based radios will try to do this, screwing up the transmission.
> I used to have a 9600 baud modem hooked to an ICOM IC-27A and it
> definitely had that problem.  Even some "9600-baud ready" radios
> with the modem connector on the back might have this sort of
> problem.

Interesting!  I hadn't encountered, or thought of that issue.
Yeah, a PLL-based frequency synthesizer which is designed for
rapid frequency changes and quick stabilization (e.g. during
scanning) could easily end up trying to "correct the errors"
caused by the low-frequency signal being fed directly to the
modulator.

I've read opinions by people who said that old-style crystal-
based radios are a better choice for running a 9600 bit/second
backbone than modern synthesized radios are.  Maybe this is why?

I do know that our local guys have had difficulty getting good,
predictable performance out of the 9600 bit/second backbone they
have been trying to set up.  Our first assumptions were that
the main problems have been noise, multipath, and intermod...
but maybe transmitter frequency stability is also complicating
matters.  I'll mention this to Michael.

> Note that the 0 bits are a disadvantage for the reasons mentioned,
> but they're an advantage for the purpose of getting more clock
> transitions to sync up with at the receive side.  If it weren't for
> the extra short packet in there that some devices create it would be
> much better to have a sequence of 0-bits than flags.  This is
> especially important for the first part of a transmission when the
> receiver is attempting to sync up to the transmit clock:  With
> 0-bits you can often use a shorter TXD at the transmit side yet
> still get the receiver to sync before the data starts across.  It
> might also be important in lower S/N conditions.

Hmmm... that's an argument I haven't seen proposed in the X.25 or
AX.25 literature.

During the initial part of transmission (before the first frame)
I could well see it... send a continuous stream of 0-bits during
the TXDELAY period (to allow for the modem-level clock
synchronization), then send one or two FLAGs to sync up the
HDLC bitstream.  Dunno about in between frames, though.

When I figured out that the soundmodem and my TNC-X weren't
playing well together, I looked into the soundmodem code and
figured out a couple of possible fixes.  One is to modify
soundmodem's HDLC encoder and bit-stuffer so that it doesn't
generated invalid (runt) frames.  The reason for the runts, is
that the encoder doesn't attempt to maintain bit synchronization
in its output buffer in between frames... at the end of a frame,
it appends the final FLAG to its output and then flushes the
output buffer, and starts packing the next frame at the beginning
of a new byte.  I did develop a patch to maintain synchronization
between frames, but it has never been incorporated into the official
software (Thomas didn't care for it).

Another possible approach would be to give soundmodem the ability
to generate a somewhat more complex start-of-frame sequence...
perhaps a programmable number of zero-bytes followed by a programmable
number of FLAGs.  This would allow TNCs with marginal firmware (or
operating under noisy conditions) a better chance to re-synchronize
at the beginning of the next frame.

> I've seen a few references to 6-pack, and know that its a "special
> firmware" that one would load on the TNCs...But I can't seem to find
> that firmware anywhere.  Does anyone know where I can actually get it,
> and find info about what TNCs it supports?

As far as I can tell, it was only ever available as an EEPROM swap-out
for the classic TAPR TNC-2 design.

It was developed by the Flexnet people. The firmware is supposedly
available (as "6pack.bin") on any system running Flexnet 3.2.  I
dug around on the Flexnet home page

  http://www.afthd.tu-darmstadt.de/~flexnet/intro.html

and through their archives.  The download directory contains
a "6pack.lzh" archive, which does (when unpacked with the
"lza" utility) contain a file called "6pack.bin", but it's only
4k bytes long... I have difficulty believing that this is
actually valid firmware for a TNC-2.  You might want to write
to the Flexnet people and ask them for a clean copy of the
PROM image file.

Apparently, some older TNC-2 systems with slower clocks are
limited in their ability to support 6Pack, and need a bit of
hardware modification.  6Pack appears to want to run its serial
port at 2x the modem data speed, so supporting 9600 bit/second
operation on an older TNC-2 isn't possible without modifications
to increase its serial port speed.

> It seems that for hardware available today, the recommendation for
> infrastructure use is to use a TNC in KISS or 6-pack mode.  I've been
> using one at home in KISS mode for a while, and I've been noticing
> what I think now is the T1 timer problem, and its been causing very
> frustrating and massive reduction in throughput on my local 9k6
> channel, even though my radio and the node are the only two on
> frequency!  I often see my system try and send retransmits before the
> first packet ever even makes it out the radio (but on the other hand,
> I also think my TNC is sitting on packets way too long -- PacComm
> Spirit-2).  

I agree with Curt - your TNC's delay and persistence values are
probably a bit out of whack with your upper-level protocol timeouts.

As I read things, the T1 timer in your AX.25 stack needs to be
set high enough to allow your packet to be transmitted, and the
response to come back.  In the Linux kernel, T1 is normally set to
twice the average-measured round trip time, with the default
value for the AX.25 device being 10 seconds.  The RTT calculations
operate on a basis of averaging, with a lower clamp limit of 1
second and an upper clamp limit of 30 seconds.

It's possible to adjust T1 on a per-connection basis, once
you've created the socket... but unfortunately I don't see any way
to adjust it semi-permanently for a device/port, or for the whole
AX.25 stack.  The default and clamp values are compiled into the
kernel and don't seem to be configurable.

In a standard TNC-2 (with current firmware), the TNC will delay
before transmitting (once it hears clear air) by a multiple
of the slot delay time.  The multiple will be between 1, and
the persistence limit, apparently chosen at random.  If your limit
(or the slot time) is set too high, it'll be possible for the
Linux system's T1 timer to expire before the TNC transmits,
even if the air is completely clear. Lowering the persistence
limit and/or the slot-delay time could help throughput.

However, setting your parameters too aggressively would cause
your station to "hog the air", at which point other users
of the frequencies may show up on your doorstep to gently
reason with you (e.g. pitchforks and flaming torches being
optional :-).

You may need to specifically enable P-Persistence in your TNC
settings - it might default to an older mode of operation.

I'd suggest checking that SCC-ARES-RACES page I pointed to... our
guys have developed a set of recommendations for TNC settings, to
improve overall throughput and reduce unnecessary retransmissions
during busy-air conditions.

> Thanks all for the ideas/input.  I think the BPQether driver best fits
> what I was hoping to find, except for the fact that it doesn't exist
> off-the-shelf yet....

I agree - an interesting idea.

As far as the actual USB protocol goes, you'd probably want to look
into the "usbnet.c" driver in the kernel.  This implements a fairly
generic "USB driver for Ethernet-like thingies" framework, for a bunch
of devices which share a fairly common approach to the problem of
sending Ethernet frames over USB connections.  It's used for some
PC-to-PC "USB null modem" cables, other sorts of network-like peripherals,
and for some actual USB network adapters.  [Only a minority of USB
Ethernet devices use this framework - most are implemented with vendor-
or chipset-specific USB protocols and are extremely non-portable.]

You could probably implement this sort of USBNET protocol in a
high-end microcontroller, which is then wired up to one or more
modem chips or ADC/DAC chips which interface to the radio.  Using
BPQether framing on Ethernet seems like a fine idea.

The Cypress microcontrollers with the EZ-USB stack could be
suitable targets.  These have the ability to have their firmware
downloaded by the host over USB each time they plug in and
enumerate... easy updating, no need to burn EEPROMs or flash
firmware directly into the chips.  High-end PIC micros could
be another workable choice.

Re: Linux Packet Interface Hardware

[Matti Aarnio]

On Wed, Jun 16, 2010 at 03:29:54PM -0700, Dave Platt wrote:
...
> > Thanks all for the ideas/input.  I think the BPQether driver best fits
> > what I was hoping to find, except for the fact that it doesn't exist
> > off-the-shelf yet....
> 
> I agree - an interesting idea.
... 
> The Cypress microcontrollers with the EZ-USB stack could be
> suitable targets.  These have the ability to have their firmware
> downloaded by the host over USB each time they plug in and
> enumerate... easy updating, no need to burn EEPROMs or flash
> firmware directly into the chips.  High-end PIC micros could
> be another workable choice.

While the idea of "load the firmware at boot" is great idea during
development, it becomes not-so-great in deployment.

I would prefer flashing in the production firmware, and possibly
supplying a way to re-flash it if necessary, but never playing
development mode games with users.

Even with windows we are seeing that 2-3 years down the road the
old drivers / firmware loads  become non-functional when windows
versions change.   It is always better to use abstractions that
do not need any sort of device driver disks on any platform, and
the way to achieve that is preferrably not subscribing on OS vendors
driver integration program.

What if your modem has ethernet?  No way to upload firmware thru
USB then.  (BPQether over ethernet...)

73 de Matti, OH2MQK

Re: Linux Packet Interface Hardware

[Jim Kusznir]

It appears that the PacComm firmware (both the very old version I got
it with and the new one I paid $30 for last year) seem to have a bug
such that:

1) its not possible to leave KISS mode without doing a RAM reset (pull
battery or use the jumper)
2) When switching to KISS mode, all the parameters specified in the
non-kiss mode are ignored.  So I'm running with "default" tx delay,
etc.

This is partially why I thought I'd need to replace the ROM with a
KISS-specific ROM in order to configure some of these settings.

--Jim

On Wed, Jun 16, 2010 at 9:46 AM, Curt, WE7U <curt.we7u@gmail.com> wrote:
> On Wed, 16 Jun 2010, Jim Kusznir wrote:
>
>> I've been
>> using one at home in KISS mode for a while, and I've been noticing
>> what I think now is the T1 timer problem, and its been causing very
>> frustrating and massive reduction in throughput on my local 9k6
>> channel, even though my radio and the node are the only two on
>> frequency!  I often see my system try and send retransmits before the
>> first packet ever even makes it out the radio (but on the other hand,
>> I also think my TNC is sitting on packets way too long -- PacComm
>> Spirit-2).
>
> Tweak your KISS parameters.  If there are only two on frequency then
> you can increase your p-persistence quite a bit and perhaps decrease
> your slottime.
>
> --
> Curt, WE7U.                         <http://www.eskimo.com/~archer>
>   APRS:  Where it's at!                    <http://www.xastir.org>
>  Lotto:  A tax on people who are bad at math. - unknown
> Windows:  Microsoft's tax on computer illiterates. - WE7U.
> The world DOES revolve around me:  I picked the coordinate system!"
>
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux Packet Interface Hardware

[Curt, WE7U]

On Wed, 16 Jun 2010, Dave Platt wrote:

> I've read opinions by people who said that old-style crystal-
> based radios are a better choice for running a 9600 bit/second
> backbone than modern synthesized radios are.  Maybe this is why?

Certainly can be a big factor.


> I do know that our local guys have had difficulty getting good,
> predictable performance out of the 9600 bit/second backbone they
> have been trying to set up.  Our first assumptions were that
> the main problems have been noise, multipath, and intermod...
> but maybe transmitter frequency stability is also complicating
> matters.  I'll mention this to Michael.

Should be easy to test by putting various audio frequencies in to
the modulator and verifying whether the PLL tracks with them or
allows the radio to shift frequency properly with the modulation.
Or phase, if you're phase modulating it.  Starting to get way out of
my realm of expertise though!


>> Note that the 0 bits are a disadvantage for the reasons mentioned,
>> but they're an advantage for the purpose of getting more clock
>> transitions to sync up with at the receive side.  If it weren't for
>> the extra short packet in there that some devices create it would be
>> much better to have a sequence of 0-bits than flags.  This is
>> especially important for the first part of a transmission when the
>> receiver is attempting to sync up to the transmit clock:  With
>> 0-bits you can often use a shorter TXD at the transmit side yet
>> still get the receiver to sync before the data starts across.  It
>> might also be important in lower S/N conditions.
>
> Hmmm... that's an argument I haven't seen proposed in the X.25 or
> AX.25 literature.

The thoughts come from a project I did in 1985 with a RS Micro Color
Computer and an XR-2211 on an interrupt pin, decoding 300/600/1200
baud packet (w/o a TNC).  Said computer had 6803 processor at
0.79MHz (TV colorburst Xtal / 4).  Was fun, but figured out I locked
faster with 0 bits than with a flag and had to figure out why.  Also
did full CRC-16 checking with above scheme.  I saw at the time that
some TNC's were sending flags and some zero bytes during the TXD
period.


> During the initial part of transmission (before the first frame)
> I could well see it... send a continuous stream of 0-bits during
> the TXDELAY period (to allow for the modem-level clock
> synchronization), then send one or two FLAGs to sync up the
> HDLC bitstream.  Dunno about in between frames, though.

If I remember the spec correctly (have the printed version at home)
0 bytes like that aren't allowed between frames, and a single flag
can delineate two data frames.  Don't know whether most TNC's can
handle that last.  Or soundmodem.  Or AGWPE & friends.


> When I figured out that the soundmodem and my TNC-X weren't
> playing well together, I looked into the soundmodem code and
> figured out a couple of possible fixes.  One is to modify
> soundmodem's HDLC encoder and bit-stuffer so that it doesn't
> generated invalid (runt) frames.

> Another possible approach would be to give soundmodem the ability
> to generate a somewhat more complex start-of-frame sequence...
> perhaps a programmable number of zero-bytes followed by a programmable
> number of FLAGs.  This would allow TNCs with marginal firmware (or
> operating under noisy conditions) a better chance to re-synchronize
> at the beginning of the next frame.

Check the spec.  I think it says flags only between frames, which
doesn't give you as good a chance to resync.

-- 
Curt, WE7U.                         <http://www.eskimo.com/~archer>
    APRS:  Where it's at!                    <http://www.xastir.org>
   Lotto:  A tax on people who are bad at math. - unknown
Windows:  Microsoft's tax on computer illiterates. - WE7U.
The world DOES revolve around me:  I picked the coordinate system!"

Re: Linux Packet Interface Hardware

[Dave Platt]

> 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!

Re: Linux Packet Interface Hardware

[Dave Platt]

> If I remember the spec correctly (have the printed version at home)
> 0 bytes like that aren't allowed between frames, and a single flag
> can delineate two data frames.  

You're correct, and in fact that (one inter-frame FLAG) does seem to
be the transmit-behavior of the TNCs I've looked at.

>                    Don't know whether most TNC's can
> handle that last.  Or soundmodem.  Or AGWPE & friends.

Yes, as far as I can tell, they all do handle this properly...
the arrival of the FLAG at the end of the first frame triggers
the delivery of that frame (assume that the FCS is valid) and
sets the state machine back to the "FLAG has been received, looking
for first byte of the frame" state.

> Check the spec.  I think it says flags only between frames, which
> doesn't give you as good a chance to resync.

Yup (in fact I quoted the spec in my earlier message).  However,
the stated spec is written as a "should", rather than a "shall"...
which means that this behavior is a recommended best practice,
but not obligatory.  As a result, the current soundmodem
implementation isn't an actual violation of the AX.25 spec;
it is just (in my opinion) less compliant than it could be.

The second "fix" I proposed (allowing more zero-bits, and
more than one FLAG between frames) would be equally not-so-good.

The only really compliant fix is to do as my patch did, and
eliminate the extra zeros entirely.  At that point, adding more
FLAGs between frames might or might not help matters under
conditions of channel noise... one would have to do a bunch of
testing to see whether it's a win or a loss.

Re: Linux Packet Interface Hardware

[Andrew Errington]

On Thu, June 17, 2010 08:53, Dave Platt wrote:
<snip>
> Several ideas intermixed here, so I have several comments.

Me too

> (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

You can build a really cheap TNC for about $30:

http://www.n9cx.net/BobBall.htm

I have made three of them.  They work!

73,

Andrew

Re: Linux Packet Interface Hardware

[Curt, WE7U]

On Wed, 16 Jun 2010, Jim Kusznir wrote:

> 2) When switching to KISS mode, all the parameters specified in the
> non-kiss mode are ignored.  So I'm running with "default" tx delay,
> etc.

You can send custom-crafted KISS packets to the TNC which set
various KISS parameters.  Assuming you have set your serial port
parameters you can do things like this:

     #!/usr/bin/perl
     sleep 1;
     printf("%c%c%c", 192, 255, 192);
     sleep 1;


Which is the "kiss-off.pl" script from the Xastir project.  Run it
against a serial port like this:

     ./kiss-off.pl >/dev/ttyS1


See the KISS spec (online) for the parameters you can set.  The
above script takes a TNC out of KISS mode.  Again I'd mess with the
p-persistence and slottime parameters.  Looks like default TXD is
1/2 second though which is a bit long so mess with that too.

The above 192, 255, 192 sequence is FEND RETURN FEND.  Assuming
you're not messing with a multi-port TNC so that we can assume the
upper four bits to be 0, you'd set parameters like so:

     FEND 0x01 0x20 FEND   # TXD in 10ms units
     FEND 0x02 0x40 FEND   # P-Persistence
     FEND 0x03 0x0a FEND   # SlotTime in 10ms units

or:

     192 1 32 192
     192 2 64 192
     192 3 10 192

Make sure that if 0xc0 or 0xdb appear in your data that you use the
escape characters as mentioned in the spec.

-- 
Curt, WE7U.                         <http://www.eskimo.com/~archer>
    APRS:  Where it's at!                    <http://www.xastir.org>
   Lotto:  A tax on people who are bad at math. - unknown
Windows:  Microsoft's tax on computer illiterates. - WE7U.
The world DOES revolve around me:  I picked the coordinate system!"

Re: Linux Packet Interface Hardware

[walter harms]

It seems there is a serious lack for information.

Is someone willing to create a Howto from the discussion ?

re,
 wh

Re: Linux Packet Interface Hardware

[Jim Kusznir]

Hi all:

A while has passed since this message went out originally, but I now
have a student interested in perusing this as an embedded systems
class project.  As we looked more into this, we found a deficit of
information in some important areas, namely the actual modulation
technique.  Before actually proposing this project, the student wants
to make sure its actually something within his relm of doing, and the
biggest questions at the moment are the requirements for actually
encoding the data into AFSK/FSK signals.  Are there any good
references on that?  Does someone also have handy the specification of
the BPQether spec?

He's looking at using a PIC product for the implementation that
actually has an ethernet port on it rather than the USB ether device,
but there is still flexibility in that.  Any other input on this would
be appreciated.

--Jim, K7LL

On Tue, Jun 15, 2010 at 6:24 PM, Matti Aarnio <matti.aarnio@zmailer.org> wrote:
> On Tue, Jun 15, 2010 at 04:43:45PM -0700, Jim Kusznir wrote:
>>
>> Hi all:
>>
>> I'm in the process of designing some kinda-embedded applications that
>> will need to employ packet "compatibility layers" to allow access of
>> packet radios.
>>
>> In one application, I'm proposing relacing a node stack with a linux
>> box, some interface (subject of this e-mail), and the existing radios
>> with their audio (discriminator if appropriate), tx line, squelch
>> line, etc.  Other applications may not be as demanding as the nodes,
>> but similar.  In essence, I'm looking for a device to connect to the
>> equivalent of the 6-pin mini-din connector used for "data" on most
>> modern radios and linux.
>>
>> I'm familiar with the state of the art back in the late '90's.  I also
>> realize that not a lot has necessarily changed since then....
>> However, I suspect something may have.
>>
>> the solution should be capable of running several different packet
>> interfaces, and at 9600 or 1200 baud.  These interfaces should turn
>> into linux axX interfaces.
>
> I would suggest making it an USB device with "BPQether" type of interface.
> At USB level it would look like a _generic_ ( = no extra drivers )
> ethernet, but it would understand only BPQether type of packets, and
> therefore would not get to transmit just anything that system happens
> to send on its way.
>
> There would be need for unique serial numbers ( = "mac address" ) for
> the devices.  Anything would be good as long as first byte of MAC
> address has its lowest bit clear (the multicast indicator)
> (Even prefix "BPQ" = 0x42, 0x50, 0x51 )
>
> See  "man bpqparams" for the control interface.
>
> To implement a control command channel, like to set ptt delays, etc.
> that could be an AX.25 frame with destination call of 'NOCALL' (the
> classical misconfiguration token) and an UI frame with control data.
> Speed would be fixed, but nothing prevents having multiple virtual
> ethernet interfaces in same USB device, each with their own speeds.
>
> As a bonus, this same hardware could be plugged on Windows as well
> without any special drivers.  If the settings are correct, then on
> windows a BPQ32 suite will be able to drive it too - and you get
> even more people interested in that device.
>
>> Thanks!
>> --Jim, K7LL
>
> 73 de Matti, OH2MQK
>
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html