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

[Bob Bruninga]

>> That was the point of my post.  That is, 
>> to add an external PIC to use this "exposed 
>> information" for external displays...
>
> Then that pic should not do what you recommend 
> but implement the D-PRS translation.  

Great!  This is just what I was looking for in the first place in my original private request to you, to make D-PRS by-directional so that we could have displays for D-STAR users of local (APRS type) information.  But you said it was impossible and D-PRS (although capable) was one way only and showed no interest in persuing this any further....

> Plus, if they follow the D-PRS spec, they have 
> full APRS compatibility including bidirectional 
> operation.  However, this has nothing to do with 
> what is displayed on the radio. 

Which is exactly what I was exploring and asking... How can we display this information?..., but it got buried in all of your responses.

>> ...if some form of data is "exposed" as you 
>> suggest, then we should be able to exploit it 
>> somehow... 
>
> Be "exposed" is not the same as being "used".  
> As I stated to you privately and on this SIG, 
> the callsign and message information that is 
> present on the data port on the radio is not 
> utilized by the radio. 

Which was well understood when you said that.  Which is why I immediately shifted my focus to the SUBJECT of this thread and asked what kind of external display can we add to make this information visible.  I proposed a PIC processor to convert the data into WAYPOINT or GARMIN or AVMAP protocols so that GPS maps could display it.  Or modified HAMHUDS. 

> Then promote a standard (D-PRS) that is already 
> in existence and already compensates for issues 
> that exist on the D-STAR data subchannel. 

Which was my oriignal private request to you, about how could we make D-PRS bidirectional.  Again, just trying to find ways to make all that nice local (APRS type) information available to the D-STAR user who already has a bidirectional low speed data channel available to him.

>> And once we develop the how-to-do-it and 
>> formats, then we could approach ICOM and 
>> ask them to give us access to the displays 
>> in future models.  I like to be open minded 
>> about what can be done. If there is 
>> something in the way, then lets work around 
>> it and eventually have the goal of fixing it. 
>
> There is nothing to fix.  The radios are 
> voice radios; the specification is for voice; 
> the radios work properly to promote the 
> proper use of the D-STAR protocol.

But they have this nice low rate data channel too, so lets think of something neat (like APRS type displays not just one-way tracking).
 
> This is already being done on D-STAR forums 
> and by people knowledgeable in the D-STAR 
> protocol.  The APRS SIG is not the place for 
> D-STAR discussions which is a completely 
> different protocol. 

I dont care about the exact protocols.  That is only the delivery mechanism.  I care about the display of local information about surrounding ham radio to mobile operators. APRS has defined a set of fields (position, course, speed, altitude, frequency, PHG,  text, etc) that can be used as the basis for such displays.  SO I hope anything the D-STAR people are working on will have compatibilty as these fields cross the translation gateways.

It is that discussion I was hoping to develop so that we avoid any incompatibilities.

Bob, WB4APR