AX25 help site

AX25 help site

[Douglas Cole]

For those just getting their Linux packet station going this page may
help you with that, these articles have an OpenSuSE focus but should
work for most distributions....

http://n7bfs.net/mediawiki/index.php/Ax25

Also I thought I saw a posting asking for an init.d script to bring up
an AX0 interface, here is what my friend KD7DMP has made that works
very well:

http://n7bfs.net/mediawiki/index.php/AX25_init.d

And of course the very useful AX25 wiki
http://www.linux-ax25.org/wiki/Main_Page


Hope this helps.

-- 
Douglas Cole
N7BFS

Re: AX25 help site

[Curt, WE7U]

On Mon, 31 Aug 2009, Douglas Cole wrote:

> For those just getting their Linux packet station going this page may
> help you with that, these articles have an OpenSuSE focus but should
> work for most distributions....
>
> http://n7bfs.net/mediawiki/index.php/Ax25
>
> Also I thought I saw a posting asking for an init.d script to bring up
> an AX0 interface, here is what my friend KD7DMP has made that works
> very well:
>
> http://n7bfs.net/mediawiki/index.php/AX25_init.d
>
> And of course the very useful AX25 wiki
> http://www.linux-ax25.org/wiki/Main_Page

Also the HowTo section at:  http://www.xastir.org

And the APRS wiki:  http://info.aprs.net

-- 
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: AX25 help site

[Bob Nielsen]

On Aug 31, 2009, at 3:48 PM, Curt, WE7U wrote:

> On Mon, 31 Aug 2009, Douglas Cole wrote:
>
>> For those just getting their Linux packet station going this page may
>> help you with that, these articles have an OpenSuSE focus but should
>> work for most distributions....
>>
>> http://n7bfs.net/mediawiki/index.php/Ax25
>>
>> Also I thought I saw a posting asking for an init.d script to  
>> bring up
>> an AX0 interface, here is what my friend KD7DMP has made that works
>> very well:
>>
>> http://n7bfs.net/mediawiki/index.php/AX25_init.d
>>
>> And of course the very useful AX25 wiki
>> http://www.linux-ax25.org/wiki/Main_Page
>
> Also the HowTo section at:  http://www.xastir.org
>
> And the APRS wiki:  http://info.aprs.net

Also the DX Spider wiki: http://wiki.dxcluster.org/index.php/ 
Setting_up_the_AX25_Utilities

Bob, N7XY

Re: AX25 help site

[w8iss]

Wondering if anyone has used the tnc-x either serial port or USB
with their AX25 setup?

James W8ISS

Re: AX25 help site

[Dave Platt]

w8iss wrote:
> Wondering if anyone has used the tnc-x either serial port or USB
> with their AX25 setup?

I have used an earlier version of the TNC-X with AX.25.

I bought it with the USB interface, but wasn't happy with it...
unplugging the adapter tended to cause my system to go into
a CPU-burning loop.  I believe that this may have been due
to problems in the FTDI driver in the kernel and/or in the USB
stack... something didn't take well to having the endpoint device
yanked out from underneath the stack.  Things may have improved
in the several years since then.

I switched over to using one of the RS-232 serial ports in my
system.  This worked more reliably - the hangs went away.

The TNC-X uses KISS as its basic communication protocol with
the host (and it does support hardware flow control to avoid
transmit-buffer overruns).  Unfortunately, KISS has a fundamental
design limitation - it's impossible for the host to know just when
a packet has been transmitted, so that the host can start the
retransmit timer for that connection.  As a result, KISS-based
implementations (including the TNC-X) can make a congested frequency
even worse, by retransmitting packets unnecessarily (the retransmit
timer runs out while the TNC-X still has the packet in its buffer
and is waiting for "clear air" to send).  Without a more
sophisticated protocol between host AX.25 stack and TNC, I don't
think this problem can be avoided.

One problem I noted was a significant incompatibility between
the TNC-X, and Thomas Sailer's "soundmodem", when the former was
on the receiving end and the latter was sending.  When the soundmodem
send back-to-back AX.25 packets, the TNC-X would often lose all but
the first.

Investigation showed (I feel) that both the TNC-X and the soundmodem
were responsible for this - they had different deficiencies, which
individually weren't of great significance but which interacted quite
badly.

Soundmodem's deficiency:  it violates a "SHOULD" clause in the
AX.25 spec, which says that any idle time between packets SHOULD be
filled with FLAG octets (i.e. synchronization or idle).  The code
in soundmodem encodes AX.25 packets one at a time, and it always
starts encoding on a byte boundary in its output buffer.  AX.25
packets aren't always an integral number of bytes, due to the
use of bit stuffing.  The soundmodem will transmit the required
number of complete bytes, padding out the last encoded byte with
zero bits, before it encodes and sends the FLAG which starts the next
packet.  As a result, a back-to-back packet transmission looks like

   FLAG-packet1-FLAG-zeros-FLAG-packet2-FLAG

The TNC-X deficiency:  in the firmware version I received,
the TNC-X would "lose sync" with the packet stream as a result
of the extraneous zero bits in between the FLAG at the end of the
first packet and the FLAG at the start of the next.  Its
packet-parsing logic failed to resynchronize, and wouldn't
successfully do so until it received several FLAG bytes in
sequence... which usually didn't happen until the next
complete transmission.

Result:  massive packet loss and excessive retransmissions.

I reported this problem to the author of TNC-X, and also
to Thomas Sailer (and, in the latter case, included a source
change to the soundmodem which eliminated the mis-packing
in between the packets).  An alternate fix might be to give
the soundmodem the ability to insert one or more additional
PADs in between packets, in order to allow for a more robust
re-syncing.

The author of TNC-X subsequently released a new version of
the firmware, which I believe has addressed this problem
(enabling the firmware to re-sync on the first PAD of the
next packet).  One of these days I need to flash a new
PIC and test it out :-)

Mr. Sailer rejected my proposed fix to the soundmodem.  It's
his feeling that a proper HDLC receiver ought not to mind
the extraneous zero bits in the packet, and that the TNC-X's
failure to resynchronize was the real problem.

I personally feel that both the TNC-X code, and soundmodem,
were slightly in violation of good engineering practice
(i.e. "be conservative in what you send, and liberal in what
you're able to receive") and that modifying the soundmodem
code to comply with the "SHOULD" recommendation in the AX.25
spec would be appropriate.  Since it's his code, I haven't
pursued the matter further... I just patch it locally any time
I install a new version.

I've heard some people criticize the TNC-X for being
rather sensitive to RF coupled back from the transmitter
and antenna - it can hang, and require a power-cycle to reset.
Using a version in a robust metal case, properly grounded, and
with plenty of ferrite chokes on the power and data and radio
cables would probably be wise.

Re: AX25 help site

[Curt, WE7U]

On Tue, 1 Sep 2009, w8iss wrote:

> Wondering if anyone has used the tnc-x either serial port or USB
> with their AX25 setup?

I've been using one for quite a while with serial port and with
serial-to-USB adapter cable.  Have used it with the kernel AX.25
networking and with the Serial KISS TNC code, both from within
Xastir (APRS).

I've also done a bit of TCP/IP using the TNC-X and the kernel AX.25
driver, but only for limited testing, making sure the Xastir Wiki
instructions for installing/configuring AX.25 were correct.  Same
for the Soundmodem instructions.

-- 
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: AX25 help site

[Curt, WE7U]

On Tue, 1 Sep 2009, Dave Platt wrote:

> Soundmodem's deficiency:  it violates a "SHOULD" clause in the
> AX.25 spec, which says that any idle time between packets SHOULD be
> filled with FLAG octets (i.e. synchronization or idle).

> Mr. Sailer rejected my proposed fix to the soundmodem.  It's
> his feeling that a proper HDLC receiver ought not to mind
> the extraneous zero bits in the packet, and that the TNC-X's
> failure to resynchronize was the real problem.

Zero bits in NRZI encoding cause a square wave to be generated at
the decoding end because each zero causes a transition.  It's
actually EASIER to sync up to zero bits than it is flag bits for the
purposes of synchronous decoding.  Of course if these are happening
in-between packets, the decoder is already sync'ed and doesn't need
extra transistions there.  You're talking about zero-bits
in-between the frames.


> I personally feel that both the TNC-X code, and soundmodem,
> were slightly in violation of good engineering practice
> (i.e. "be conservative in what you send, and liberal in what
> you're able to receive") and that modifying the soundmodem
> code to comply with the "SHOULD" recommendation in the AX.25
> spec would be appropriate.

Some commercial TNC's stuff in extra flags, others stuff in zero
bytes at the start of the transmission.  I haven't investigated the
back-to-back packet interface specifically (not interesting at the
time) but as I recall everything years ago used either one or two
flags between packets, nothing else.

I don't recall any firmware-based TNC's that worried about byte
boundaries and then stuffing in zero bits, which should look to the
decoder like a separate all-zero packet in-between the flags.  It
would be better if it did NOT sync up to byte boundaries in this
manner:  The upper-level protocol has to figure out they are
zero-byte packets and toss them.  It could cause problems in some
instances.

-- 
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: AX25 help site

[Matti Aarnio]

On Tue, Sep 01, 2009 at 03:59:15PM -0700, Dave Platt wrote:
...
>     The soundmodem will transmit the required
> number of complete bytes, padding out the last encoded byte with
> zero bits, before it encodes and sends the FLAG which starts the next
> packet.  As a result, a back-to-back packet transmission looks like
> 
>    FLAG-packet1-FLAG-zeros-FLAG-packet2-FLAG

The modulation leader (synch-up) is best sent as all zeros,
but inter-packet gaps should be subsequent FLAGs.
Of course a real receiver notes that "a back to back frame,
but it has bad CRC, discard it."

   zeros - FLAG - packet1 - FLAG (- FLAG ...) packet2 - FLAG - FLAG...

And by the way, things are not at byte-boundaries after transmission,
but they should be back again after HDLC de-stuffing.


I do think that soundmodem as it is now is over-engineered on configuration
department and very much lacking in documentation -- so much so that it is
extremely hard to use without that gui-tool (like when embedding it...)
My reasoning:  If you need GUI to configure something, and it is not some
grapics thing, then you are doing something wrong!

It really calls for heavy investment on configuration simplicity of
soundmodem.

73 de Matti, OH2MQK

Re: AX25 help site

[Dave Platt]

Matti Aarnio wrote:
> On Tue, Sep 01, 2009 at 03:59:15PM -0700, Dave Platt wrote:
> ...
>>     The soundmodem will transmit the required
>> number of complete bytes, padding out the last encoded byte with
>> zero bits, before it encodes and sends the FLAG which starts the next
>> packet.  As a result, a back-to-back packet transmission looks like
>>
>>    FLAG-packet1-FLAG-zeros-FLAG-packet2-FLAG
> 
> The modulation leader (synch-up) is best sent as all zeros,
> but inter-packet gaps should be subsequent FLAGs.
> Of course a real receiver notes that "a back to back frame,
> but it has bad CRC, discard it."

Correct.  The receiver is required (a "MUST" in the spec) to
detect and discard any frame which is either too short, has a
bad CRC, or is not an integral number of bytes (after the
HDLC de-stuffing is performed).

A fully-robust receiver will reject the few extra zero-bits
of zero that the soundmodem may insert, for all three reasons...
this "frame" is too short, an odd number of bits, and has no
valid CRC.  Three thumbs-down ought to be enough :-)

The initial version of the TNC-X firmware was "confused" by
the extra zero bits, and didn't resynchronize immediately with
the second FLAG. It did reject the short "packet" as having a
bad CRC, but its loss of sync meant that it didn't parse the
second packet at all.

I believe that this shortfall has been corrected (or at least
greatly improved) in the current TNC-X firmware.

>    zeros - FLAG - packet1 - FLAG (- FLAG ...) packet2 - FLAG - FLAG...

Agreed - that's the way it's best done, I think.

> And by the way, things are not at byte-boundaries after transmission,
> but they should be back again after HDLC de-stuffing.

Yes - if they aren't, then the resulting packets are bad, and the
spec says that they must be discarded.

Re: AX25 help site

[David Ranch]

Hello Dave,

. . .
> I personally feel that both the TNC-X code, and soundmodem,
> were slightly in violation of good engineering practice
> (i.e. "be conservative in what you send, and liberal in what
> you're able to receive") and that modifying the soundmodem
> code to comply with the "SHOULD" recommendation in the AX.25
> spec would be appropriate.  Since it's his code, I haven't
> pursued the matter further... I just patch it locally any time
> I install a new version.


Curious, does your soundmodem patch cleanly apply against Soundmodem 0.14?

   http://www.baycom.org/~tom/ham/soundmodem/


I think I've been seeing some strange compatibility issues with some
local TNCs and I'd like to see if this patch would help.

Maybe you could post it on the web somewhere?

--David

Re: AX25 help site

[Dave Platt]

> Curious, does your soundmodem patch cleanly apply against Soundmodem 0.14?
> 
>    http://www.baycom.org/~tom/ham/soundmodem/
> 
> 
> I think I've been seeing some strange compatibility issues with some
> local TNCs and I'd like to see if this patch would help.
> 
> Maybe you could post it on the web somewhere?

It does appear to apply, with an offset of a few lines but
no rejected patch chunks, by using the -p1 option.  The
patched source compiled without error.  I haven't tried to use
it yet but I'd expect it'll work OK.

It's available at

   http://www.radagast.org/~dplatt/hamradio/soundmodem-0.7b.patch

I'd be very curious to know whether it addresses the compatibility
problems you've been seeing (and, if so, which TNCs were affected).

Fldigi and RTTY decodes

[David A. Ranch]

	
Hello Everyone,

I'm a new HAM but not new to Linux.  I've been using Fldigi for
monitoring BPSK31, etc. with good luck but I've been finding that RTTY
rarely works.  It maybe decodes 10% of the time even with a strong
signal.  It also seems the good decodes are specific to a given remote
handle's QSO.

I stumbled upon something today which I bet has a major impact on the
RTTY decoding and I was curious about the group's thoughts.


In researching HF Nets, there is the 3950 Century Club's RTTY NET:

   http://www.3905ccn.com/newsite/netsched.htm

In that URL, it specifies LSB *regardless* of the band and they also
specify specific "mark tones".   In studying for my General ticket, the
current ARRL "General Class License Manual" (section 2-12 & 5-5) mentions:

   - RTTY is usually FSK

   - the ARRL docs *does* mention the existence of AFSK RTTY to use LSB

   - Usual RTTY Mark is at 2125hz and Space at 2295 (170hz diff.)



Now, looking at the Fldigi docs on RTTY, this is where things become
obvious there are issues:

    http://www.w1hkj.com/FldigiHelp/RTTYFSK.html


  - FLdigi's RTTY is "AFSK is not FSK - All of the modem signals that
fldigi produces are audio signals"

  - they mention a Pseudo FSK-RTTY support mode with a external circuit:

   http://www.w1hkj.com/FldigiHelp/PseudoFSK.html

  - "You MUST run the radio is USB to have the correct polarity."  This
conflicts with what the the above Century Net URL and the ARRL docs
specify to use LSB.


So my questions for the net are:

  1. What's more common on the digital bands?  FSK RTTY or AFSK RTTY?
If it's FSK RTTY, are people using TNCs to do RTTY vs. soundcard-based
solutions?

  2. Is there a way to determine if a given RTTY transmission is FSK vs.
AFSK?  I have fairly good ears but maybe it's impossible to hear the
difference with background noise?

  3. Can FLdigi still decode FSK-based RTTY?  Maybe this is only a Tx
limitation?

  4. Maybe Fldigi's RTTY decode (and maybe CW) isn't so hot.  Any
recommendations on alternative Linux packages?  I'd love to hear other
user's thoughts on their favorite Linux apps for HF digital modes (maybe
another email thread).


--David
KI6ZHD

Re: Fldigi and RTTY decodes

[Dave Platt]

David A. Ranch wrote:
> 	
> Hello Everyone,
> 
> I'm a new HAM but not new to Linux.  I've been using Fldigi for
> monitoring BPSK31, etc. with good luck but I've been finding that RTTY
> rarely works.  It maybe decodes 10% of the time even with a strong
> signal.  It also seems the good decodes are specific to a given remote
> handle's QSO.
> 
> I stumbled upon something today which I bet has a major impact on the
> RTTY decoding and I was curious about the group's thoughts.

#snip#

> So my questions for the net are:
> 
>   1. What's more common on the digital bands?  FSK RTTY or AFSK RTTY?
> If it's FSK RTTY, are people using TNCs to do RTTY vs. soundcard-based
> solutions?

My guess is that direct FSK is more common among hams who have
been on the air for decades and are using older radios.  Most
newer setups probably use TNCs (or soundcard equivalents) fed
into SSB modulators, and are thus AFSK.

As I understand the math:  there is no actual difference in the RF
waveform and content, between:

(1) a "true FSK" signal - e.g. one in which a single oscillator is
     directly "pulled" by a certain amount (the frequency shift) by
     a baseband signal (the one/zero bit), and

(2) a sideband-synthesized signal, in which a non-changing RF
     carrier is modulated (SSB) via an AFSK signal whose audio
     frequency shift is equal to the desired RF shift and where
     the shift is controlled by the one/zero-bit baseband signal.

Now, this equivalence assumes that the sideband modulation process
is perfect - that is, that the carrier is completely suppressed, and
that the opposite sideband is completely filtered out.

This isn't ever actually the case, of course... no sideband modulator
is perfect.  So, in that sense, a "true" or direct-FSK RTTY signal may
produce a more "pure" modulated RF signal.

On the other hand, it may be easier to get exactly the right frequency
shift with an AFSK process - "pulling" a crystal or VCO by an exact
amount isn't always easy.

This equivalence also assumes that you've got your shift convention
correct... i.e. is a 1-bit signified by a higher RF frequency than
a 0-bit, or by a lower RF frequency?  If the receiving station tries
to use the incorrect shift convention for a given QSO, the signal won't
decode - it'll be gibberish.

You can transmit *either* shift convention with either FSK or
AFSK-into-SSB.

FLdigi "prefers" to use AFSK, since that's what a soundcard-
into-audio-input system is naturally set up for.  The auxiliary
circuit is FSK is interesting, and would be primarily of use (I
imagine) with special-function RTTY radios set up for baseband-
controlled FSK and which don't have a mic (or which have a poor
SSB modulator which doesn't handle AFSK cleanly).

>   2. Is there a way to determine if a given RTTY transmission is FSK vs.
> AFSK?  I have fairly good ears but maybe it's impossible to hear the
> difference with background noise?

You could look at a wider area (say, 10 kHz) around the signal center
frequency with some sort of spectrum analyzer.  If you can see a
residual bit of carrier a few kHz away from the RTTY tones, and perhaps
even see a "ghost image" of the RTTY tones twice as far away, then it's
a good bet that you're looking at an AFSK signal fed into an SSB
modulator, and the modulator has imperfect carrier and opposite-
sideband suppression.

On the other hand, if the RF signal appears pure (no suppressed
carrier or opposite-sideband residue), then it could be FSK, or
it could be a really good SSB modulator transmitting an AFSK
signal.

> 
>   3. Can FLdigi still decode FSK-based RTTY?  Maybe this is only a Tx
> limitation?

FLdigi should be able to decode either with equal clarity, as long as
you get the shift direction correct, because they're essentially the
same signals in the RF domain.

If you fail to decode a soecific signal, try reversing the shift
direction on receive.  You might be able to do this within FLdigi
(I imagine it has an option for this), or could do it by switching
from USB to LSB (or vice versa) and re-tuning to reacquire the signal.

Re: Fldigi and RTTY decodes

[David A. Ranch]

Hello Dave,

Thanks for the excellent email.  I'll give the USB vs. LSB idea a try
and see if that will help.  Sure would be nice if Fldigi could make this
an option within it's configuration.

--David

. . .
> If you fail to decode a soecific signal, try reversing the shift
> direction on receive.  You might be able to do this within FLdigi
> (I imagine it has an option for this), or could do it by switching
> from USB to LSB (or vice versa) and re-tuning to reacquire the signal.
> 

Re: Fldigi and RTTY decodes

[Dave Platt]

David A. Ranch wrote:
> Hello Dave,
> 
> Thanks for the excellent email.  I'll give the USB vs. LSB idea a try
> and see if that will help.  Sure would be nice if Fldigi could make this
> an option within it's configuration.

It looks as if it does.  Switch to RTTY mode, and take a look at the
very bottom of the window.  There's a selector labeled "Rv", and
hovering the cursor over it brings up an explanation of "Reverse".
This may do just what you want... and if it does, you won't have to
alter your rig settings and re-tune when switching between an
RTTY-normal and RTTY-inverted arrangement.

I assume it switches both Tx and Rx bit conventions at the same
time - it would make for an unusual QSO if it didn't :-)