[aprssig] Misunderstandings about P25

[Robert Bruninga]

> 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.

Bob, Wb4APR

 
> 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
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 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, Robert Bruninga 
> <bruninga at usna.edu> wrote:
> 
> 
> 	> 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.
> 	
> 	Agree completely that straight varicoding would be dumb.
Thus
> 	the conversion for those fixed numeric fields to optimum
> 	shortened varicode symbols:
> 	0 = e bits 2
> 	1 = t bits 3
> 	2 = n bits 3
> 	...
> 	Etc.
> 	
> 	So any unused fields with "0" only take 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 almost 20% of all of
the
> 	LAT/LONG 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 troubleshooting.
> 	
> 	I agree about P25.  Thanks for all the info!
> 	
> 	Now that all the P25 problems are brought out, and the
lack of
> 	any direct access to the digital stream, makes this a
dead end.
> 	So hence the focus now is on the PSK-31 or other
sub-audible
> 	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
messaging and
> 	I
> 	> believe they have the ability to set an IP address for
an
> 	external
> 	> device connected to them.
> 	>
> 	> Other then playing with the text messaging, I have not
looked
> 	any
> 	> further as to whether computer to computer
communications is
> 	> 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
message?
> 	> Start using
> 	> varicode (or any Huffman code) and you've got to worry
about
> 	> designing
> 	> for the worst case data.  Callsigns don't have the
sort of
> 	letter
> 	> distribution you see in natural language.
> 	>
> 	> Stop thinking in terms of text strings, and think
about data
> 	> structures.
> 	>
> 	> Scott
> 	> N1VG
> 	>
> 	> From: "Stephen H. Smith" <wa8lmf2 at aol.com>
> 	> >
> 	>
> 	> P25 DOES NOT use IP over-the air (unlike Ma/Com's
proprietary
> 	> "OpenSky"
> 	> digital voice radios).
> 	>
> 	> The "virtual IP address" in a mobile is an artifact of
> 	> proprietary base
> 	> station software infrastructure (i.e. racks of
computer
> 	controllers
> 	> associated with the base station radio) that extracts
the
> 	> text payload
> 	> from the interleaved over-the-air data stream carrying
> 	> digitized voice,
> 	> trunking and control data, and the incidental "low
speed data
> 	> channel"
> 	> simultaneously.
> 	>
> 	> The base infrastructure software then re-packages the
> 	extracted
> 	> auxiliary data stream into more-or-less standard
Ethernet
> 	> TCP/IP telnet
> 	> streams.  The application at the other of the Ethernet
link is
> 	then
> 	> "fooled" into thinking it is interacting with an IP
address in
> 	the
> 	> actual mobile.
> 	>
> 	> [This is somewhat analogous to the APRS network
structure
> 	where you
> 	> transmit data over the RF link in an oddball
quasi-proprietary
> 	format
> 	> (Mic-E encapsulated in AX25 packets), unpack it to raw
text
> 	> at the base
> 	> station's TNC, pass it to the Internet server system,
and
> 	> then finally
> 	> decode and "make sense" of the data at the other end
of the
> 	> IP link in
> 	> the  user's  APRS program. ]
> 	>
> 	> "Real" end-to-end IP (i.e. Ethernet jack on the back
of the
> 	mobile
> 	> radio) is unlikely to ever be practical in the P25
> 	> environment since the
> 	>
> 	> overall transmission rate of P25 Phase I (12.5 KHz
digital
> 	> channels) is
> 	> only 9600 BPS and HALF of that is consumed with
handshaking
> 	> overhead and
> 	>
> 	> massive forward error correction of  the voice data.
The net
> 	> throughput
> 	>
> 	> is only 4800 bps.     (Old time land-line modems
anyone???).
> 	
> 	>
> 	> P25 Gen II  is supposed to cram digitized voice into
6.25 KHz
> 	> channels.
> 	> One proposed approach would halve the raw data rate to
4800
> 	> BPS (and the
> 	>
> 	> net to 2400 bps).   In some ways, this is similar to
the
> 	Iridium
> 	> satellite phone fiasco where the focus on
very-low-bit-rate
> 	voice
> 	> transmission has precluded ever using the system
effectively
> 	for data
> 	> applications.
> 	>
> 	>
> 	> BTW,  the first gen 9600 BPS P25 uses 4-frequency FSK
with the
> 	four
> 	> states being +800 Hz, +1600 Hz, -800 and -1600 Hz from
the
> 	channel
> 	> center.  This is a constant-power transmit mode that
can pass
> 	through
> 	> existing class-C RF power amps.
> 	>
> 	> The current plan for the Phase II 6.25 KHz-wide
channels would
> 	be to
> 	> maintain the current voice coding and base-band bit
rate but
> 	use QPSK
> 	> (quadrature phase-shift keying) to transmit the same
amount
> 	> of data at
> 	> half the symbol rate.    However, like PSK31, this
will
> 	> require ALL RF
> 	> transmit chains to replaced with LINEAR amplifiers.
> 	>
> 	> The vender of the AMBE voice coder used in P25 now
claims
> 	> their miracle
> 	> secret-sauce software can now shoehorn the voice
information
> 	> into only
> 	> 2400 bps of data, yielding a gross over-the-air rate
of 4800
> 	> BPS.  As a
> 	> result, the current 4FSK scheme with constant power
carriers
> 	could be
> 	> used in half the bandwidth to meet the 6.25 Khz
> 	channel-splitting
> 	> mandate, along with existing (efficient) class-C RF
> 	amplifiers).
> 	>
> 	> However, this blows up the much-vaunted
"interoperability" of
> 	> P25 since
> 	> there will now be TWO different voice codecs in use.
Early
> 	> adopter P25
> 	> jurisdictions, having spent hundreds of millions on
new
> 	digital radio
> 	> infrastructure and mobiles will now have to replace or
> 	> upgrade all this
> 	> stuff very soon if they want to talk to their
late-adopting
> 	> neighbors.
> 	>
> 	> The P25 standards-setting process, never renowned for
timely
> 	decision
> 	> making, is now hopelessly gridlocked on whether to
adopt the
> 	> new vocoder
> 	>
> 	> to save the existing RF hardware, or keep the existing
vocoder
> 	and
> 	> current baseband coding to facilitate inter-system
> 	interconnect.
> 	>
> 	> Stephen H. Smith    wa8lmf (at) aol.com
<http://aol.com/> 
> 	>
> 	>
> 	>
> 	
> 	
> 
> 
>