[aprssig] Subaudible PSK31 APRS

[Scott Miller]

 > So if the code is already there, and the varicode is already
 > there then that hard part is all already done.  And if using

Varicode is NOT the hard part.  It takes a few lines of assembly code 
and one lookup table to implement in the OpenTracker.  It's just not 
appropriate.  It's a Huffman code intended to represent English text. 
For anything with a different probability distribution there's no point.

If you want to implement a Huffman compression scheme for APRS data, 
then make it clear that that's what you're doing.  Don't complicate 
things by adding Varicode into the mix.

By using a fixed binary format, you eliminate the two bits required 
between each Varicode character.  Also consider the value of having a 
known, consistent transmission length - it'd really suck to live 
somewhere where the coordinates come out to be significantly longer than 
average.  You have to plan for the WORST case if you're using a Huffman 
code and you're trying to limit transmission time.

> northern hemisphere averages 1.5 bits.  SO using the syntax of
> the above proposed APRS data, then the total bit count for all
> the fixed fields is:
> 
> CCCCCCSSQDDMMmmmDDDMMMmmmsssCCCSSSaaaFFFfffttt...
> 
> 4444442423434444234444444666244244444 is 145 bits in varicode

Setting aside the question of number distribution for a moment, adding 
the 00 character delimiters brings it up to 219 bits.

> Doing the same thing in binary would require:
> 
> 40 bits for callsign 6666664
> 48 bits for LAT/LONG
> 13 bits for symbol
> 9  bits for course
> 10 bits for speed
> 20 bits for altitude
> 
> For a total of 140 bits.  Almost exactly the same as using
> standard PSK-31 varicode that is 100% compatible with all
> existing systems.

Only 64% of what Varicode would require, in fact, when you consider the 
delimiters and accept your own estimates of average symbol lengths. 
(Try comparing three spaces with an 'o' if you don't see the need for a 
delimiter.)

> So the value of using straight-off-the-shelf PSK-31 using
> varicode (144 bits) compared to using a new, completely unique,
> unreadable except by special hardware and software binary new

Don't know where you're getting the 'special hardware' requirement.  Is 
someone selling Varicode chips?  And I wouldn't call your scheme exactly 
human readable.  Parsing a fixed-length binary message is much simpler 
than what you're proposing.

When we're not dealing with a huge installed base of unchangeable 
hardware, designing a new protocol as an ugly kludge so it can be used 
with off-the-shelf software and parsers written in BASIC just doesn't 
make any sense.  There's no reason NOT to do it right.  And I'm pretty 
sure there IS already an 8-bit binary BPSK mode out there... but even if 
there's not, adapting PSK31 code is simple.

> Anyway, that is what I am proposing for APRS over PSK-31 (oh,
> plus a 16 bit checksum at the end of either one).

A checksum on the transmitted bits, on the ASCII values of the Varicode 
characters, or on the decoded APRS equivalent?  Remember that Varicode 
only does 7 bits, and that 16-bit checksum is (if it's designed right) 
going to have a perfectly uniform distribution of values.  That means 7 
bits of your checksum could take up to 12 bits on the air.

ANY Huffman coding scheme operates by making some symbols longer than 
they would be otherwise.  There's always overhead, and you only get a 
net gain when there is a strong statistical bias in your data for 
certain symbols.  It's true that you could divide up the world by 
population density into a Huffman tree and probably save a few bits, but 
it wouldn't be worth the added complexity.  And again, knowing for sure 
that every position everywhere will always take x bits to send just 
makes life easier.

Scott
N1VG