Order Tray | Contact Us | Home | SIG Lists

[aprssig] "Best" packet decoder solution

Scott Miller scott at opentrac.org
Tue Dec 28 19:39:25 UTC 2010


I remember seeing that at DCC one year.  Seemed like it made for some 
pretty long packets.

I've been thinking about using a simple Hamming code with interleaving 
to get some resilience while still being easy to decode for an 8-bit MCU.

I think if we're going to see any FEC scheme succeed for APRS, it needs 
to be either simple to implement or we need to take the time to build 
and publish a definitive reference implementation.  The more you 
complicate things, the less inclined developers will be to tackle it. 
Already, building something like a G3RUH modem means digging through 
someone else's source code to find all of the little details no one 
bothered to document, or that you can't find because a thousand 
well-meaning but ill-informed hams posted their own flawed interpretation.

Scott
N1VG

On 12/28/2010 8:57 AM, Wes Johnston wrote:
> Hmmm.... did not know about this. Looks like they did a test, and
> depending on if you are a half full or half empty kind of person, the
> results can be interpreted very differently...
>
> http://www.stensat.org/projects/FX-25/FX-25_performance.htm
>
> In a nutshell, 61 packets send, 9 would have been decoded with normal
> ax25. 19 additional packets could have been received using the fx.25
> method. Still, 1/2 of the packets were not recoverable.
>
> A half full person might say that we could cut our packet loss due to
> error by a factor of 3 (9 vs 9+19).
>
> I still can't find any info that tells how much longer the packets are
> on air. Why hasn't this been pursued since 2006? Not enough success in
> this test? This looks like something that could be relatively easy to
> include in sent packets.
>
> Wes
>
>
> ----- Original Message ----- From: "Jason KG4WSV" <kg4wsv at gmail.com>
> To: "TAPR APRS Mailing List" <aprssig at tapr.org>
> Sent: Tuesday, December 28, 2010 11:27 AM
> Subject: Re: [aprssig] "Best" packet decoder solution
>
>
> On Tue, Dec 28, 2010 at 8:40 AM, Wes Johnston <wes at ai4px.com> wrote:
>> Hmm.... dopplegänger packets anyone? Two IDENTICAL packets back to back.
>> At first blush you get the benefit of a 2nd shot at decoding a packet.
>
> With "hard" decoding, double packets is a waste of time/bandwidth if
> there's an error in either one. With the confidence level decoding,
> maybe there would be some benefit.
>
>> It's *really* a shame that AX25 doesn't support FEC at level 2.
>
> Google FX.25. This was proposed for (and maybe flown on) on a
> cubesat. IIRC, they wrapped an AX.25 with some FEC information, so
> that the packet could be decoded using standard AX.25 hardware, but
> FEC-enabled hardware could attempt error correction.
>
> -Jason
> kg4wsv
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>




More information about the aprssig mailing list