> 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