Difference between revisions of "Heath/FX.25"
(→AX-25 Patch) |
|||
(4 intermediate revisions by the same user not shown) | |||
Line 15: | Line 15: | ||
<pre>AX.25 <-> FX.25 <-> Radio <-> Radio <-> AX.25 <-> FX.25</pre> | <pre>AX.25 <-> FX.25 <-> Radio <-> Radio <-> AX.25 <-> FX.25</pre> | ||
− | This extension make HF Packet Radio A LOT more useful. | + | This extension would make HF Packet Radio A LOT more useful. |
== Hacking == | == Hacking == | ||
Line 27: | Line 27: | ||
* [http://www.stensat.org/projects/FX-25/FX-25_extract.c Decoder] | * [http://www.stensat.org/projects/FX-25/FX-25_extract.c Decoder] | ||
− | I think the relevant code that needs to be hacked is this: | + | I think the relevant code that needs to be hacked is ax25.c in this: |
[http://www.tazenda.demon.co.uk/phil/net-tools/ net-tools] | [http://www.tazenda.demon.co.uk/phil/net-tools/ net-tools] | ||
− | + | == FX-25 Patch == | |
− | + | This patch gets the extractor to compile. GCC spits the worrisome warning: | |
+ | |||
+ | FX-25_extract.c:817: warning: integer constant is too large for ‘long’ type | ||
+ | |||
+ | Usage is: patch -p0 < FX-25.patch | ||
<pre> | <pre> |
Latest revision as of 11:10, 4 June 2008
While discussing internet access via HF Packet Radio on the forums, we discovered this...
FX.25 Forward Error Correction Extension to AX.25 Link Protocol (PDF)
How It Works
It takes an AX.25 packet and adds forward error correction to it. The resultant packet doesn't confuse the far end as it has been designed to be compatible with AX.25. After the FX.25 has been decoded, it is passed to the FX.25 decoder which turns it to an AX.25 packet.
This is slightly counter intuitive because you'd think it would be like this...
AX.25 <-> FX.25 <-> Radio <-> Radio <-> FX.25 <-> AX.25
But it is actually like this...
AX.25 <-> FX.25 <-> Radio <-> Radio <-> AX.25 <-> FX.25
This extension would make HF Packet Radio A LOT more useful.
Hacking
It doesn't look that hard as the protocol has a really clever design. There are a few problems though:
- Hasn't been implemented on Linux
- All the parameters seem to be hardcoded
Source Code:
I think the relevant code that needs to be hacked is ax25.c in this: net-tools
FX-25 Patch
This patch gets the extractor to compile. GCC spits the worrisome warning:
FX-25_extract.c:817: warning: integer constant is too large for ‘long’ type
Usage is: patch -p0 < FX-25.patch
--- FX-25_extract.c.orig 2007-10-23 14:00:12.000000000 -0500 +++ FX-25_extract.c 2008-06-04 03:51:50.000000000 -0500 @@ -84,6 +84,24 @@ //#include "char.h" #define DTYPE unsigned char + unsigned char out_buffer = 0; + int out_bits = 0; + int consec_ones = 0; + unsigned char out_byte; + unsigned char block[BLOCKSIZE]; + int i; + unsigned char mstate, phase; + unsigned char sample_char; + unsigned char fault; + unsigned int dbuffer, bytecount; + unsigned char derrors; + int erasures; + + int in_size; + unsigned *in_buf; + int argc; + char ** argv; + /* Reed-Solomon codec control block */ struct rs { unsigned int mm; /* Bits per symbol */ @@ -795,8 +813,8 @@ // /***************************************************************************/ char find_corr_tag (unsigned char newbyte, char threshold) { - - static unsigned long long const tag = INT64_C(0x3E2F538ADFB74DB7); // fixed correlation tag value + + static unsigned long long const tag = 0x3E2F538ADFB74DB7; // fixed correlation tag value int i, j; static unsigned long long ltemp1 = 0; // this one needs to be persistent unsigned long long ltemp2, tag_temp; @@ -845,8 +863,13 @@ // Process data LSb first // // -int main(int argc, char **argv) +int main(int argc2, char **argv2) { + + argc = argc2; + argv = argv2; + +/* unsigned char out_buffer = 0; int out_bits = 0; int consec_ones = 0; @@ -862,6 +885,7 @@ int in_size; unsigned *in_buf; +*/ struct rs *rs; int index;