<div dir="ltr"><div>Bob, with all due respect, you make an interesting point for using a standard PSK31 varicode decoder to troubleshoot the packets, but if we had to write a program to decode the psk31 varicode and pass that received data to a serial port, we may as well use a binary coding system instead of varicode.  Many psk31 programs are public source code, so we are free to modify them to decode any format we dream up.  It would seem very easy for a programmer to include a GUI that would allow us to see what was going on anyway.  Even the nue psk device is open source.  <a href="http://www.nue-psk.com/">http://www.nue-psk.com/</a>  .  So it would be possible to make a hardware device that would decode any format of psk data we see fit as well.</div>

<div> </div>
<div>Thing is, I can't see where any number (ie 0) would be more common than another number (ie 7,8 or 9).  Even the letters in our callsigns are statistically spread out.  All letters have even odds of appearing.  (of couse in America A-N-K-W have greater odds hihi)  The only exeption I can see in this is the mic-e format where we could say that most people live >28 <55 latitude and prioritize the characters which comprise those latitudes.</div>

<div> </div>
<div>In this suggested system, what do we do about specifying an icon? symbol table?  We have really only two symbol tables, so that only takes one bit anywhere in the packet... a spare bit somewhere.  </div>
<div> </div>
<div>I'd like to say we could pack callsigns into smaller spaces.... using 6 bits for example.  8 characters would be 64 bits in ascii, but only 48 bits in as "packed".     8 ascii characters would allow for 6 chars of callsign and 2 characters for a hyphen and hexadecimal ssid.  Ideally, I'd like to use 7 chacters for callsign/ssid, but it would cause us ot break out of the 6bit to 8bit packing.  aha!  the 7th ssid character needs only to be 4 bits.  So we could have 6 char's x 6 bits, plus 4 ssid bits.  40 bits = 5 ascii characters.  It comes out as a round number of 8 bit characters.</div>

<div> </div>
<div>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?  We need 9 bits for CSE in one degree increments.  If we lump together three 8 bit characters (24 bits), we could use 9 for CSE and the remaining 15bits for speed up to 32,000knots.</div>

<div> </div>
<div>We also need to come up with some sort of check digit at the end of the packet.  As much as I'd love to see some sort of FEC, but a simple two digit checksum like NMEA uses would seem to be fine.  As I am keyed down talking, my subaudible packet would repeat every 2 seconds. So if there's a dropped bit, it'll come around again real soon.  Of couse knowing my luck, I'd drop a bit each time it as sent.</div>

<div> </div>
<div>I think with this format, we can forget status texts.</div>
<div> </div>
<div>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.</div>
<div><br clear="all">Wes<br>---<br>Our lives begin to end the day we become silent about things that matter<br><br><br></div>
<div class="gmail_quote">On Mon, Aug 18, 2008 at 6:11 PM, Robert Bruninga <span dir="ltr"><<a href="mailto:bruninga@usna.edu">bruninga@usna.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> I'd also like to second Scott's comment about varicode.<br>> ... varicode is great for written text...<br>
> LOUSY for callsigns and numbers.<br><br>My proposal was to use fixed fields.  Numeric fields such as the<br>LAT/LONG/CSE/SPD fields would use the 10 most used lower case<br>letters to equal 0-9 so that the average is just 4 bits per<br>
digit when sent as varicode.<br><br>Agree completely that straight varicoding would be dumb.  Thus<br>the conversion for those fixed numeric fields to optimum<br>shortened varicode symbols:<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 "0" only take 2 bits and are better<br>than binary.  And the longest (5 bit letters) are used for 7,8,9<br>which statistically do not occur in almost 20% of all of the<br>
LAT/LONG fields.   The result can be as short or shorter than<br>fixed field binary.  And we have the advantage that everyone can<br>troubleshoot it with any off-the-shelf PSK-31 receive program...<br><br>Same with the callsign.  Lower case is used, so that all the<br>
advantages of compression of varicode is used.  Varicode<br>randomly on lower case calls takes the same average 36 bits as<br>binary... Or at most 38.  But the advantage is decodablity on<br>any PSK-31 program for troubleshooting.<br>
<br>I agree about P25.  Thanks for all the info!<br><br>Now that all the P25 problems are brought out, and the lack of<br>any direct access to the digital stream, makes this a dead end.<br>So hence the focus now is on the PSK-31 or other sub-audible<br>
process to send APRS on any voice radio and repeater...<br><br>That can be very exciting!<br>Bob, WB4APR<br>><br>> -----Original Message-----<br>><br>> The latest P25 radios from Motorola include text messaging and<br>
I<br>> believe they have the ability to set an IP address for an<br>external<br>> device connected to them.<br>><br>> Other then playing with the text messaging, I have not looked<br>any<br>> further as to whether computer to computer communications is<br>
> possible<br>> using the radios as modems.<br>><br>> Steve <steve.jones at <a href="http://rogers.com/" target="_blank">rogers.com</a>><br>><br>> ------------------------------<br>><br>><br>
> Please, can't we just have a fixed-length binary message?<br>> Start using<br>> varicode (or any Huffman code) and you've got to worry about<br>> designing<br>> for the worst case data.  Callsigns don't have the sort of<br>
letter<br>> distribution you see in natural language.<br>><br>> Stop thinking in terms of text strings, and think about data<br>> structures.<br>><br>> Scott<br>> N1VG<br>><br>> From: "Stephen H. Smith" <<a href="mailto:wa8lmf2@aol.com">wa8lmf2@aol.com</a>><br>
> ><br>><br>> P25 DOES NOT use IP over-the air (unlike Ma/Com's proprietary<br>> "OpenSky"<br>> digital voice radios).<br>><br>> The "virtual IP address" in a mobile is an artifact of<br>
> proprietary base<br>> station software infrastructure (i.e. racks of computer<br>controllers<br>> associated with the base station radio) that extracts the<br>> text payload<br>> from the interleaved over-the-air data stream carrying<br>
> digitized voice,<br>> trunking and control data, and the incidental "low speed data<br>> channel"<br>> simultaneously.<br>><br>> The base infrastructure software then re-packages the<br>extracted<br>
> auxiliary data stream into more-or-less standard Ethernet<br>> TCP/IP telnet<br>> streams.  The application at the other of the Ethernet link is<br>then<br>> "fooled" into thinking it is interacting with an IP address in<br>
the<br>> actual mobile.<br>><br>> [This is somewhat analogous to the APRS network structure<br>where you<br>> transmit data over the RF link in an oddball quasi-proprietary<br>format<br>> (Mic-E encapsulated in AX25 packets), unpack it to raw text<br>
> at the base<br>> station's TNC, pass it to the Internet server system, and<br>> then finally<br>> decode and "make sense" of the data at the other end of the<br>> IP link in<br>> the  user's  APRS program. ]<br>
><br>> "Real" end-to-end IP (i.e. Ethernet jack on the back of the<br>mobile<br>> radio) is unlikely to ever be practical in the P25<br>> environment since the<br>><br>> overall transmission rate of P25 Phase I (12.5 KHz digital<br>
> channels) is<br>> only 9600 BPS and HALF of that is consumed with handshaking<br>> overhead and<br>><br>> massive forward error correction of  the voice data.  The net<br>> throughput<br>><br>> is only 4800 bps.     (Old time land-line modems anyone???).<br>
<br>><br>> P25 Gen II  is supposed to cram digitized voice into 6.25 KHz<br>> channels.<br>> One proposed approach would halve the raw data rate to 4800<br>> BPS (and the<br>><br>> net to 2400 bps).   In some ways, this is similar to the<br>
Iridium<br>> satellite phone fiasco where the focus on very-low-bit-rate<br>voice<br>> transmission has precluded ever using the system effectively<br>for data<br>> applications.<br>><br>><br>> BTW,  the first gen 9600 BPS P25 uses 4-frequency FSK with the<br>
four<br>> states being +800 Hz, +1600 Hz, -800 and -1600 Hz from the<br>channel<br>> center.  This is a constant-power transmit mode that can pass<br>through<br>> existing class-C RF power amps.<br>><br>> The current plan for the Phase II 6.25 KHz-wide channels would<br>
be to<br>> maintain the current voice coding and base-band bit rate but<br>use QPSK<br>> (quadrature phase-shift keying) to transmit the same amount<br>> of data at<br>> half the symbol rate.    However, like PSK31, this will<br>
> require ALL RF<br>> transmit chains to replaced with LINEAR amplifiers.<br>><br>> The vender of the AMBE voice coder used in P25 now claims<br>> their miracle<br>> secret-sauce software can now shoehorn the voice information<br>
> into only<br>> 2400 bps of data, yielding a gross over-the-air rate of 4800<br>> BPS.  As a<br>> result, the current 4FSK scheme with constant power carriers<br>could be<br>> used in half the bandwidth to meet the 6.25 Khz<br>
channel-splitting<br>> mandate, along with existing (efficient) class-C RF<br>amplifiers).<br>><br>> However, this blows up the much-vaunted "interoperability" of<br>> P25 since<br>> there will now be TWO different voice codecs in use. Early<br>
> adopter P25<br>> jurisdictions, having spent hundreds of millions on new<br>digital radio<br>> infrastructure and mobiles will now have to replace or<br>> upgrade all this<br>> stuff very soon if they want to talk to their late-adopting<br>
> neighbors.<br>><br>> The P25 standards-setting process, never renowned for timely<br>decision<br>> making, is now hopelessly gridlocked on whether to adopt the<br>> new vocoder<br>><br>> to save the existing RF hardware, or keep the existing vocoder<br>
and<br>> current baseband coding to facilitate inter-system<br>interconnect.<br>><br>> Stephen H. Smith    wa8lmf (at) <a href="http://aol.com/" target="_blank">aol.com</a><br>><br>><br>><br><br></blockquote>
</div><br></div>