<div>One more question... more to do with psk31...</div>
<div> </div>
<div>Can we up the baud rate to 64? 144/31.5 = 4.57sec per position report. Could we cut that in 1/2?</div>
<div> </div>
<div>Wes<br><br> </div>
<div><span class="gmail_quote">On 2008-08-19, <b class="gmail_sendername">Robert Bruninga</b> <<a href="mailto:bruninga@usna.edu">bruninga@usna.edu</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">So here is my proposal for the APRS PSK31 format:<br><br>CCCCCCSSQDDMMmmmDDDMMMmmmsssCCCSSSaaaFFFfffttt...CS<br>
<br>Where CCCCCCSS is call and SSID<br>Q is the quadrant (NE,SE,NW,SW)<br>DDMMmmm is latitude to 6 feet<br>DDDMMmmm is longitude to 6 feet<br>sss is symbol in GPSxyz format<br>CCC is course<br>SSS is speed<br>aaa is altitude in Mic-E format<br>
FFFfff is freqeuency in MHz<br>ttt... Is free field status text.<br>CS is a checksum or CRC whatever<br><br>Now then using the translation of digits to lower case letters<br>optimizes the use of PSK-31 varicode using the following table<br>
which shows the digit, the number of varicode bits used, the<br>replacement lower case letter and the desciption. Notice that<br>UNUSED fields (SPACES) only take one bit when a field is not<br>used.<br><br>_ 1 SPACE for unused fields<br>
0 2 e for zero<br>1 3 o for one<br>2 3 t for two<br>3 4 a for three<br>4 4 n for four<br>5 4 i for five<br>6 5 s for six<br>7 5 r for seven<br>8 5 l for eight<br>9 6 m for nine<br><br>For LAT/LONG quadrant we would use these conversions:<br>
<br>NE 2 e all Europe and Asia<br>NW 1 SPACE all of the USA<br>SE 3 t Australia<br>SW 3 o Pacific<br><br>The average of digits five and below (25% of most decimal<br>fields) is 3.3 bits. And for all 10 digits is 4.1. The<br>
northern hemisphere averages 1.5 bits. SO using the syntax of<br>the above proposed APRS data, then the total bit count for all<br>the fixed fields is:<br><br>CCCCCCSSQDDMMmmmDDDMMMmmmsssCCCSSSaaaFFFfffttt...<br><br>4444442423434444234444444666244244444 is 145 bits in varicode<br>
<br>Doing the same thing in binary would require:<br><br>40 bits for callsign 6666664<br>48 bits for LAT/LONG<br>13 bits for symbol<br>9 bits for course<br>10 bits for speed<br>20 bits for altitude<br><br>For a total of 140 bits. Almost exactly the same as using<br>
standard PSK-31 varicode that is 100% compatible with all<br>existing systems.<br><br>So the value of using straight-off-the-shelf PSK-31 using<br>varicode (144 bits) compared to using a new, completely unique,<br>unreadable except by special hardware and software binary new<br>
invention to save 5 bits out of 140 seems to be a slam dunk.<br>PLUS, the added comment field being human text will be more<br>efficient under varicode than using binary any day.<br><br>Anyway, that is what I am proposing for APRS over PSK-31 (oh,<br>
plus a 16 bit checksum at the end of either one).<br><br>Bob, Wb4APR<br><br><br>> > Many psk31 programs are public source code,<br>> > so we are free to modify them to decode any format<br>> > we dream up.<br>
><br>> So if the code is already there, and the varicode<br>> is built-in then that hard part is all already done.<br>> And if using varicode is [as] efficient... then<br>> that has to be weighted against the value of<br>
> being 100% compatible with and able to troubleshoot<br>> with existing PSK31.<br>><br>> It's a tradeoff that has to be considered.<br>> Going off and re-inventing a totally new, totally<br>> unique binary system that can only be docoded and<br>
> displayed by totally new unique hardware and firmware<br>> only to [be pure binary] is not something that<br>> should be just blindly adopted without assessing<br>> the tradeoffs.<br>><br>>> Thing is, I can't see where any number (ie 0)<br>
>> would be more common than another number (7,8 or 9).<br>><br>> In DDMM.mmmDDDMM.mmm there are 15 bytes.<br>> Here are the ones that are not 7 8 or 9:<br>><br>> So XDXM.mmmXDDXM.mmm more than 25% don't use 78 or 9.<br>
><br>>> our callsigns are statistically spread out.<br>><br>> Yes, and using lower case letters, then the varicode average<br>is<br>> 6 bits per letter which is the same as straight binary.<br>><br>>> The only exeption I can see in this is...<br>
>> that most people live 28 <55 latitude and<br>>> prioritize the characters which comprise<br>>> those latitudes.<br>><br>> Yes, which is exactly what I propose, [since]<br>> [varicode has advantages there too].<br>
><br>> Notice I have added a third decimal point in<br>> the LAT/LONG to give 6 foot precision....<br>><br>> 343444433444444 bits which adds up to 56 bits<br>> using varicode compared to the 48 bits of<br>
> straight binary. I don't see that saving a few<br>> ... bits is worth completely ambandonig full<br>> compatibility with all existing PSK-31. Plus<br>> most of these ... bits can be saved when other<br>
> fixed fields are not used. Remember that a SPACE<br>> or "0"... in varicode only takes 1 or 2 bits,<br>> instead of straight binary of 7 and 4. SO packet<br>> formats that have unused fields will actually<br>
> save many bits compared to fixed binary...<br>><br>> Ill...put together the whole plan so you can see.<br>><br>> Bob, Wb4APR<br><br>> ><br>> > I'd like to say we could pack callsigns into smaller<br>
> > spaces.... using 6 bits for example.<br>><br>> Yes, varicode alredy does that.<br>><br>> > Do we want to use the log method of representing speed as<br>> > used in mic-e? or a simple linear scale to keep it easy for<br>
<br>> > hte pic programers?<br>><br>> I propose the standard APRS format of CSE/SPD<br>> which only goes to 999 MPh or KPH, but it encodes<br>> into only 12 bits or so each for CSE and SPD and<br>> maintains full familiarity with existing PSK-31<br>
> and APRS...<br>><br>>> We also need to come up with some sort of<br>>> check digit at the end of the packet.<br>><br>> Agreed.<br>><br>>> I think with this format, we can forget status texts.<br>
><br>> No way. That is where Frequency, altitude and<br>> other useful information reside. They should<br>> all be allowed, just like in normal APRS. There<br>> is no reason to put any limits on this format,<br>
> or we will regret it later when every radio does it...<br>><br>>> We _really_ need to make this format as easy<br>>> as we can for the pic processor modems to encode.<br>>> We accomodate anything we dream up with a PC or<br>
>> basic.... but the pic processors are another story.<br>><br>> That is why simple fixed-field format that then is<br>> turned over to the standard PSK-31 varicode<br>> processor is simple and clean. Done.<br>
> Not re-inventing a new wheel.<br>><br>> Again, Im not hard over on this, but it must be<br>> considered against all tradeoff's. Besides,<br>> it would also nail down a universal standard for<br>> APRS over PSK-31 in the first place.<br>
><br>> Bob, WB4APR<br><br>> > On Mon, Aug 18, 2008 at 6:11 PM,..<br>>>> I'd also like to second Scott's comment about<br>>>> varicode. ... varicode is great for written<br>>>> text... LOUSY for callsigns and numbers.<br>
>><br>>> My proposal was to use fixed fields. Numeric<br>>> fields such as the LAT/LONG/CSE/SPD fields<br>>> would use the 10 most used lower case letters<br>>> to equal 0-9 so that the average is just 4 bits<br>
>> per digit when sent as varicode.<br>>> _ = SPACE 1 bit<br>>> 0 = e bits 2<br>>> 1 = t bits 3<br>>> 2 = n bits 3<br>>> ...<br>>> Etc.<br>>><br>
>> So any unused fields with SPACE or "0" only take 1<br>>> or 2 bits and are better than binary. And the<br>>> longest (5 bit letters) are used for 7,8,9<br>>> which statistically do not occur in more than 25%<br>
>> of all of the LAT/LONG/CSE/SPD fields. The<br>>> result can be as short or shorter than fixed field<br>>> binary. And we have the advantage that everyone<br>>> can troubleshoot it with any off-the-shelf PSK-31<br>
>> receive program...<br>>><br>>> Same with the callsign. Lower case is used,<br>>> so that all the advantages of compression of<br>>> varicode is used. Varicode randomly on lower<br>>> case calls takes the same average 36 bits as<br>
>> binary... Or at most 38. But the advantage is<br>>> decodablity on any PSK-31 program for trouble-<br>>> shooting.<br><br><br>_______________________________________________<br>aprssig mailing list<br>
<a href="mailto:aprssig@lists.tapr.org">aprssig@lists.tapr.org</a><br><a href="https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig">https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig</a><br></blockquote></div><br>
<br clear="all"><br>-- <br>Wes<br>---<br>Our lives begin to end the day we become silent about things that matter