[aprssig] Subaudible PSK31 APRS

[Wes Johnston, AI4PX]

One more question... more to do with psk31...

Can we up the baud rate to 64?  144/31.5 = 4.57sec per position report.
Could we cut that in 1/2?

Wes


On 2008-08-19, Robert Bruninga <bruninga at usna.edu> wrote:
>
> 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.
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>



-- 
Wes
---
Our lives begin to end the day we become silent about things that matter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.tapr.org/pipermail/aprssig/attachments/20080819/3efd6df5/attachment.htm