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

[Robert Bruninga]

>> 3) There is no inherent displays on D-STAR radios 
>> of any of this information
> 
> Correction
> - ID-800 and IC91-AD will display positions 
> (latitude and longitude) when they hear 
> GPS messages (only the "original" GPS, 
> not GPS-A). Very crude, ... but it's there.
>
> - IC-2820 and IC-92A will additionally 
> display the distance and bearing of the 
> received position relative to their own

Which gets me back to square one which I was after all along...
I wanted to use this original D-STAR GPS capabilty for example
to display something like the location of an APRS object such as
the local AARC club meeting tonight using this format:

$GPGGA,... 
AARC    ,Mtg tnite on HF @8PM

Where the GPGGA would contain the position of the clubhouse and
the callsign AARC and the text "Mtg tnite on HF @8PM" would show
up on the radio.  And on the 2820 it whould show the distance
and bearing to the meeting.  But I interpreted what Pete says
there was no such display capability...

>> 4) An external display system could be 
>> developed to display this information
> 
> There is already such a system. D-PRS (*) provides 
> the required translation to make this data readily 
> available to any APRS client. 

But I don't want to have to carry around a laptop just to
display the simple APRS object showing that there is a meeting
tonight and its location which seems like I should be able to
display on the radio the way it is already...

> (*) http://www.aprs-is.net/DPRS.aspx
>     http://www.aprs-is.net/images/D-PRS.pdf

These are not working right now for me, so if there are images,
then that too was what I have been interested in seeing as well.

>> 2) Something in those bits to carry a MUTE signal 
>> telling the user radios that there is no VOICE 
>> and to keep the speaker quiet.
> 
> Although it's not a MUTE signal, speaker remains quiet 
> at the receiving end when a D-Star radio sends data. 

But I assume if there is any garbling of the data under weak
signal conditions, than then the silence is no longer silent but
can contain garbled sounds...  If that is correct, then that is
why I thought that a more robust mute might be required..

Thanks
Bob