Order Tray | Contact Us | Home | SIG Lists

[ax25-layer2] ECC/FEC

scott at opentrac.org scott at opentrac.org
Thu Aug 3 15:22:26 UTC 2006


>Note that this is likely a ax.25 v3.0 issue because a legacy TNC is 
>unlikely to be able to cope with EDAC without a significant firmware
upgrade.

Not if the parity block is in a separate frame.  A legacy TNC will accept
the data frame if it's intact and throw it away if it's not, like any other
frame.  When it gets the parity frame, it'll fail FCS (and could be
constructed to always appear as a specific PID as awell) and it'll be
treated as noise and ignored.

A new TNC, on the other hand, would buffer a damaged packet until it either
received a parity frame that successfully repaired it, or until another
valid data frame is received - the assumption being that the parity block is
regenerated with each retransmission and has no opportunity to be separated
from its data block.

> where <p> is the probability of a given packet being corrupted
>        <b> is the time (in bits) required to do the retry,
>            including the usual packet overheads due to TXD, 
> 
> I don't have good estimates for <b> and <n> as most AX.25 systems are 
> set uniquely.

Well, here's a data point for you - on the test CD I have from 144.39 in Los
Angeles at rush hour, I can decode 850 packets and I get 350 FCS errors
after excluding runts (packets too short to be valid.)  That gives a value
for p of about 0.4.  Even on a less crowded APRS channel, I think 0.25 would
be a reasonable assumption.

More importantly, there is NO retry capability in APRS, except for ACK'd
text messages.  And APRS (or OpenTRAC) is the reason I want to do this - it
certainly wouldn't have the same benefit for connected mode.  Also, most
people don't run connected mode while they're driving and are spared the
effects of mobile flutter.

> Another consideration is how packets tend to be corrupted. Most 
> systems seem to assume that the probability of any particular bit 
> being corrupted is the same as that of any other bit being corrupted. 

Reed-Solomon codes are good for applications where errors come in bursts,
and real-world interference definitely seems to do that to packets.

As for channel usage, a typical APRS packet might have a 150 ms TXD and 400
ms of data (60 bytes).  An RS(255,233) parity block might add 36 bytes for
HDLC flags, FCS, and data.  That's an extra 240 ms - 790 ms vs. 550 ms.
It's not an insignificant increase, but users tend to compensate for busy
channels by INCREASING their beacon rate to get more packets through -
hopefully a good ECC scheme would reduce the need for that.  Also, there are
shorter RS codes - I think 16 bytes of parity might still be plenty for
APRS.

Scott
N1VG







More information about the ax25-layer2 mailing list