<div>How do we get 3200 symbols?</div>
<div>Wes<br><br> </div>
<div><span class="gmail_quote">On 10/2/07, <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, what we really need is an APRS client<br>> software package which is night and<br>> day better than what exists today.  It would
<br>> need to be prepared to provide a change<br>> over to opentrac.<br>><br>> All the Kenwood D700 and THD7A owners would be<br>> left out, and this would be "a bad thing" for many.<br>> However, with enough devices and software to
<br>> support it, a bit of rebel action could make<br>> it happen "on frequency"...<br><br>I agree with the first paragraph, because too many clients never<br>implemented all of APRS and only implemented a few things like
<br>vehicle tracking and then never finished.  We need some working<br>clients that will complete the job and will keep up with the<br>evolution of APRS.<br><br>As to obsoleting all existing hardware, what is missing that you
<br>want, that cannot be done within the existing APRS protocol?  So<br>far, the only two complaints were:<br>1) Not enough precision (APRS capable to 1 foot)<br>2) Not enough symbols (APRS capable of 3200)<br><br>This is not enough to scrap all existing kenwoods and move to a
<br>new protocol on 144.39 in my opinion...<br><br>Bob, WB4APR<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>In theory there is no difference between practice and theory.