[aprssig] Subaudible PSK31 APRS
Wes Johnston, AI4PX wes at ai4px.comTue Aug 19 17:24:50 UTC 2008
- Previous message: [aprssig] Subaudible PSK31 APRS
- Next message: [aprssig] Subaudible PSK31 APRS
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- 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