[aprssig] Subaudible PSK31 APRS

Tue Aug 19 12:41:04 EDT 2008

So here is my proposal for the APRS PSK31 format:

CCCCCCSSQDDMMmmmDDDMMMmmmsssCCCSSSaaaFFFfffttt...CS

Where CCCCCCSS is call and SSID
Q is the quadrant (NE,SE,NW,SW) 
DDMMmmm is latitude to 6 feet
DDDMMmmm is longitude to 6 feet
sss is symbol in GPSxyz format
CCC is course
SSS is speed
aaa is altitude in Mic-E format
FFFfff is freqeuency in MHz
ttt... Is free field status text.
CS is a checksum or CRC whatever

Now then using the translation of digits to lower case letters
optimizes the use of PSK-31 varicode using the following table
which shows the digit, the number of varicode bits used, the
replacement lower case letter and the desciption.  Notice that
UNUSED fields (SPACES) only take one bit when a field is not
used.

_  1 SPACE for unused fields
0  2 e for zero
1  3 o for one
2  3 t for two
3  4 a for three
4  4 n for four
5  4 i for five
6  5 s for six
7  5 r for seven
8  5 l for eight
9  6 m for nine

For LAT/LONG quadrant we would use these conversions:

NE 2 e     all Europe and Asia
NW 1 SPACE all of the USA
SE 3 t     Australia
SW 3 o     Pacific

The average of digits five and below (25% of most decimal
fields) is 3.3 bits.  And for all 10 digits is 4.1.  The
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

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.

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
invention to save 5 bits out of 140 seems to be a slam dunk.
PLUS, the added comment field being human text will be more
efficient under varicode than using binary any day.

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

Bob, Wb4APR

> > Many psk31 programs are public source code, 
> > so we are free to modify them to decode any format 
> > we dream up.
> 
> So if the code is already there, and the varicode 
> is built-in then that hard part is all already done.  
> And if using varicode is [as] efficient... then 
> that has to be weighted against the value of
> being 100% compatible with and able to troubleshoot 
> with existing PSK31.  
>
> It's a tradeoff that has to be considered.
> Going off and re-inventing a totally new, totally 
> unique binary system that can only be docoded and 
> displayed by totally new unique hardware and firmware 
> only to [be pure binary] is not something that 
> should be just blindly adopted without assessing 
> the tradeoffs.
> 
>> Thing is, I can't see where any number (ie 0) 
>> would be more common than another number (7,8 or 9). 
> 
> In DDMM.mmmDDDMM.mmm there are 15 bytes.  
> Here are the ones that are not 7 8 or 9:
> 
> So XDXM.mmmXDDXM.mmm more than 25% don't use 78 or 9.
> 
>> our callsigns are statistically spread out.  
> 
> Yes, and using lower case letters, then the varicode average
is
> 6 bits per letter which is the same as straight binary.
> 
>> The only exeption I can see in this is...
>> that most people live 28 <55 latitude and 
>> prioritize the characters which comprise 
>> those latitudes.
> 
> Yes, which is exactly what I propose, [since]
> [varicode has advantages there too].
> 
> Notice I have added a third decimal point in 
> the LAT/LONG to give 6 foot precision....
> 
> 343444433444444 bits which adds up to 56 bits 
> using varicode compared to the 48 bits of 
> straight binary.  I don't see that saving a few
> ... bits is worth completely ambandonig full 
> compatibility with all existing PSK-31.  Plus 
> most of these ... bits can be saved when other 
> fixed fields are not used.  Remember that a SPACE
> or "0"... in varicode only takes 1 or 2 bits, 
> instead of straight binary of 7 and 4.  SO packet 
> formats that have unused fields will actually 
> save many bits compared to fixed binary...
> 
> Ill...put together the whole plan so you can see.
> 
> Bob, Wb4APR

> >
> > I'd like to say we could pack callsigns into smaller 
> > spaces.... using 6 bits for example.
> 
> Yes, varicode alredy does that.
> 
> > Do we want to use the log method of representing speed as 
> > used in mic-e?  or a simple linear scale to keep it easy for

> > hte pic programers?  
> 
> I propose the standard APRS format of CSE/SPD 
> which only goes to 999 MPh or KPH, but it encodes 
> into only 12 bits or so each for CSE and SPD and 
> maintains full familiarity with existing PSK-31
> and APRS...
> 
>> We also need to come up with some sort of 
>> check digit at the  end of the packet. 
> 
> Agreed.
> 
>> I think with this format, we can forget status texts.
> 
> No way.  That is where Frequency, altitude and 
> other useful information reside.  They should 
> all be allowed, just like in normal APRS.  There 
> is no reason to put any limits on this format, 
> or we will regret it later when every radio does it...
>   
>> We _really_ need to make this format as easy 
>> as we can for the pic processor modems to encode.  
>> We accomodate anything we dream up with a PC or 
>> basic.... but the pic processors are another story.
> 
> That is why simple fixed-field format that then is 
> turned over to the standard PSK-31 varicode 
> processor is simple and clean.  Done.
> Not re-inventing a new wheel.
> 
> Again, Im not hard over on this, but it must be 
> considered against all tradeoff's.  Besides, 
> it would also nail down a universal standard for 
> APRS over PSK-31 in the first place.
> 
> Bob, WB4APR

> > On Mon, Aug 18, 2008 at 6:11 PM,..
>>> I'd also like to second Scott's comment about
>>> varicode. ... varicode is great for written 
>>> text... LOUSY for callsigns and numbers.
>> 	
>> My proposal was to use fixed fields.  Numeric 
>> fields such as the LAT/LONG/CSE/SPD fields 
>> would use the 10 most used lower case letters 
>> to equal 0-9 so that the average is just 4 bits
>> per digit when sent as varicode.
>>    _ = SPACE  1 bit
>> 	0 = e bits 2
>> 	1 = t bits 3
>> 	2 = n bits 3
>> 	...
>> 	Etc.
>> 	
>> So any unused fields with SPACE or "0" only take 1
>> or 2 bits and are better than binary.  And the 
>> longest (5 bit letters) are used for 7,8,9
>> which statistically do not occur in more than 25%
>> of all of the LAT/LONG/CSE/SPD fields.   The 
>> result can be as short or shorter than fixed field 
>> binary.  And we have the advantage that everyone 
>> can troubleshoot it with any off-the-shelf PSK-31 
>> receive program...
>> 	
>> Same with the callsign.  Lower case is used, 
>> so that all the advantages of compression of 
>> varicode is used.  Varicode randomly on lower 
>> case calls takes the same average 36 bits as
>> binary... Or at most 38.  But the advantage is
>> decodablity on	any PSK-31 program for trouble-
>> shooting.