[aprssig] PIC processor for APRS info for D-STAR mobiles?

[Robert Bruninga]

> Unfortunately, this just shows your ignorance of the 
> D-STAR protocol and how the Icom radios utilize it.
> ... there is no GPS "protocol" ...  When GPS data is 
> transmitted as the radios are designed, when the 
> operator is talking, then the information is 
> complimentary; not in conflict.

I use the term "protocol" to mean the mechanism by which a GPS
capable D-STAR radio transmits the GPS information.  My
understanding that in GPS mode, the data transmitted by a D-STAR
GPS radio (which I was referring to as a protocol) consists of
just about all the same information we convey in an APRS packet
too.  Callsign, position, course, speed, altitude, date, time
and some free text as shown here.

$GPGGA,...
$GPRMC,...
MYCALL I,[20 bytes of TEXT..]

> This is an example of you wanting to put a square peg 
> in a round hole.  

Yes, I do want to figure out how to put a square peg (A D-STAR
mobile user) in the round hole of visibility to local real time
HAM radio information around him.

> This is the same misbegotten attitude which keeps APRS 
> from becoming more usable (your "new paradigm" still 
> insists on trying to source route AX.25 which is terribly 
> abused world-wide, usually unintentionally).

See Response in separate email... So  as not to get us off
track...

> "Digital" does not mean data.  The radios do 
> not work the way you want them to and they simply don't 
> communicate that way.  Unfortunately, your misdirected 
> post will cause someone to pursue this without any 
> knowledge of how the D-STAR protocol works or the ill 
> effects their efforts will have on the D-STAR network.

I'm just trying to have an open dialog to find a way to work
around these limitations, and how to plan for a future that will
include D-STAR users in the local ham radio information highway
(APRS).  That is, local display of local information of value to
the mobile operator.  IF there is a low speed channel in these
radios that has some exposure to the user, I think we are clever
enough to figure out how to use it for display (in an addon box
for now, but maybe in the radio later...)...  But we have to do
the thinking now if we want to lead ICOM to where we want to
go..

The 2820 radio already has a compass rose to point in a
direction, and can display the 20 bytes of TEXT and plenty of
display area.  I assume the radios are flash upgradeable.  SO if
we define what we want, then maybe they will help?  Since 20
bytes is what we use in APRS to convey the text information for
all digipeaters, frequency objects, traffic objects, echolink,
irlp, and WINlink and others due to the same 20 byte limitations
of the D7 and D700, it seems all the pieces are almost there in
the ICOM too.  We just need some ideas and a plan...

If it cannot be done in the existing D-STAR protocol, then lets
figure out what is needed to make it so that it can?  Then we
approach ICOM and ask for it.

Bob, WB4APR

> 
> > -----Original Message-----
> > From: Robert Bruninga
> > Sent: Friday, July 04, 2008 10:21 PM
> > To: 'TAPR APRS Mailing List'
> > Subject: [aprssig] PIC processor for APRS info for D-STAR
mobiles?
> >
> > D-PRS by Pete and D-GATE by Rich have done a wonderful job
of
> > bringing D-STAR mobiles over onto the APRS maps.  I am
starting
> > to see more and more of these mobiles on APRS.
> >
> > But now as Yeasu joins Kenwood as anotehr TWO-WAY APRS
radio,
> > displaying local information to the front panel for the
mobile
> > operator, I am wondering what we can do for displaying
useful
> > local info to the D-STAR operators?
> 
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>