[aprssig] Subaudible PSK31 APRS
Scott Miller scott at opentrac.orgTue Aug 19 17:27:14 UTC 2008
- Previous message: [aprssig] Subaudible PSK31 APRS
- Next message: [aprssig] Subaudible PSK31 APRS
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> 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
- Previous message: [aprssig] Subaudible PSK31 APRS
- Next message: [aprssig] Subaudible PSK31 APRS
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the aprssig mailing list