[aprssig] Misunderstandings about P25
bruninga at usna.edu
Tue Aug 19 10:51:34 EDT 2008
> but if we had to write a program to decode the psk31
> varicode and pass that received data to a serial port...
> 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 already
there then that hard part is all already done. And if using
varicode is more efficient, or at most, no more than say 10%
inefficient, 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 firmware only to save 10% is not something that shold 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 (ie 7,8 or 9).
In DDMM.mmmN/DDDMM.mmmW there are 17 bytes. Here are the ones
that are not 7 8 or 9:
So XDXM.mmmX/XDDXM.mmmX or more than 25% do not 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..
Notice I have added a third decimal point in the LAT/LONG to
give 6 foot precision Of course this would be transmitted
without the decimal points and the / for a total of
34344443344344443 bits which adds up to 62 bits using varicode
compared to the 48 bits of straight binary. I don't see that
saving 14 bits is worth completely ambandonig full compatibility
with all existing PSK-31. Plus most of these 14 bits can be
saved when other fixed fields are not used. Remember that a "0"
as we will use it in varicode only takes 2 bits, instead of
straight binary of four. SO packet formats that have unused
fields will actually save many bits compared to fixed binary...
Ill have to put togetther the whole plan so you can see.
> 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.
No, the symbol table can contain up to 38 values. Because that
is where overlays are transmitted. So that takes 6 bits.
> 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
> We also need to come up with some sort of check digit at the
> end of the packet.
> 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 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.
> On Mon, Aug 18, 2008 at 6:11 PM, Robert Bruninga
> <bruninga at usna.edu> wrote:
> > I'd also like to second Scott's comment about
> > ... 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
> letters to equal 0-9 so that the average is just 4 bits
> digit when sent as varicode.
> Agree completely that straight varicoding would be dumb.
> the conversion for those fixed numeric fields to optimum
> shortened varicode symbols:
> 0 = e bits 2
> 1 = t bits 3
> 2 = n bits 3
> So any unused fields with "0" only take 2 bits and are
> than binary. And the longest (5 bit letters) are used
> which statistically do not occur in almost 20% of all of
> LAT/LONG fields. The result can be as short or shorter
> fixed field binary. And we have the advantage that
> troubleshoot it with any off-the-shelf PSK-31 receive
> Same with the callsign. Lower case is used, so that all
> advantages of compression of varicode is used. Varicode
> randomly on lower case calls takes the same average 36
> binary... Or at most 38. But the advantage is
> any PSK-31 program for troubleshooting.
> I agree about P25. Thanks for all the info!
> Now that all the P25 problems are brought out, and the
> any direct access to the digital stream, makes this a
> So hence the focus now is on the PSK-31 or other
> process to send APRS on any voice radio and repeater...
> That can be very exciting!
> Bob, WB4APR
> > -----Original Message-----
> > The latest P25 radios from Motorola include text
> > believe they have the ability to set an IP address for
> > device connected to them.
> > Other then playing with the text messaging, I have not
> > further as to whether computer to computer
> > possible
> > using the radios as modems.
> > Steve <steve.jones at rogers.com <http://rogers.com/>
> > ------------------------------
> > Please, can't we just have a fixed-length binary
> > Start using
> > varicode (or any Huffman code) and you've got to worry
> > designing
> > for the worst case data. Callsigns don't have the
> > distribution you see in natural language.
> > Stop thinking in terms of text strings, and think
> > structures.
> > Scott
> > N1VG
> > From: "Stephen H. Smith" <wa8lmf2 at aol.com>
> > >
> > P25 DOES NOT use IP over-the air (unlike Ma/Com's
> > "OpenSky"
> > digital voice radios).
> > The "virtual IP address" in a mobile is an artifact of
> > proprietary base
> > station software infrastructure (i.e. racks of
> > associated with the base station radio) that extracts
> > text payload
> > from the interleaved over-the-air data stream carrying
> > digitized voice,
> > trunking and control data, and the incidental "low
> > channel"
> > simultaneously.
> > The base infrastructure software then re-packages the
> > auxiliary data stream into more-or-less standard
> > TCP/IP telnet
> > streams. The application at the other of the Ethernet
> > "fooled" into thinking it is interacting with an IP
> > actual mobile.
> > [This is somewhat analogous to the APRS network
> where you
> > transmit data over the RF link in an oddball
> > (Mic-E encapsulated in AX25 packets), unpack it to raw
> > at the base
> > station's TNC, pass it to the Internet server system,
> > then finally
> > decode and "make sense" of the data at the other end
> > IP link in
> > the user's APRS program. ]
> > "Real" end-to-end IP (i.e. Ethernet jack on the back
> > radio) is unlikely to ever be practical in the P25
> > environment since the
> > overall transmission rate of P25 Phase I (12.5 KHz
> > channels) is
> > only 9600 BPS and HALF of that is consumed with
> > overhead and
> > massive forward error correction of the voice data.
> > throughput
> > is only 4800 bps. (Old time land-line modems
> > P25 Gen II is supposed to cram digitized voice into
> > channels.
> > One proposed approach would halve the raw data rate to
> > BPS (and the
> > net to 2400 bps). In some ways, this is similar to
> > satellite phone fiasco where the focus on
> > transmission has precluded ever using the system
> for data
> > applications.
> > BTW, the first gen 9600 BPS P25 uses 4-frequency FSK
> > states being +800 Hz, +1600 Hz, -800 and -1600 Hz from
> > center. This is a constant-power transmit mode that
> > existing class-C RF power amps.
> > The current plan for the Phase II 6.25 KHz-wide
> be to
> > maintain the current voice coding and base-band bit
> use QPSK
> > (quadrature phase-shift keying) to transmit the same
> > of data at
> > half the symbol rate. However, like PSK31, this
> > require ALL RF
> > transmit chains to replaced with LINEAR amplifiers.
> > The vender of the AMBE voice coder used in P25 now
> > their miracle
> > secret-sauce software can now shoehorn the voice
> > into only
> > 2400 bps of data, yielding a gross over-the-air rate
> > BPS. As a
> > result, the current 4FSK scheme with constant power
> could be
> > used in half the bandwidth to meet the 6.25 Khz
> > mandate, along with existing (efficient) class-C RF
> > However, this blows up the much-vaunted
> > P25 since
> > there will now be TWO different voice codecs in use.
> > adopter P25
> > jurisdictions, having spent hundreds of millions on
> digital radio
> > infrastructure and mobiles will now have to replace or
> > upgrade all this
> > stuff very soon if they want to talk to their
> > neighbors.
> > The P25 standards-setting process, never renowned for
> > making, is now hopelessly gridlocked on whether to
> > new vocoder
> > to save the existing RF hardware, or keep the existing
> > current baseband coding to facilitate inter-system
> > Stephen H. Smith wa8lmf (at) aol.com
More information about the aprssig