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

[Robert Bruninga]

OK, I will substitute your words for mine, and merge all of this
information so that we end up with a summary of this process
that we can both agree on...  Then we can use that as the
baseline for progress.

> 1) D-PRS is the translation of Icom GPS or GPS-A 
> information into a format usable by APRS 
> clients (APRS in TNC2 format).  These clients 
> may be locally attached or via APRS-IS...
> See http://www.aprs-is.net/dprs.aspx  

> 2) D-PRS ... also supports formatting APRS 
> "packets" for transport across the Icom-
> provided data subchannel on the D-STAR 
> digital voice stream.

>> 3) We need PIC processors connected to the 
>> data subchannel of the D-STAR radios to remove 
>> the [D-PRS GPS-A mode] CRC and take this APRS 
>> data and convert to the WAYPOINT, or GARMIN or 
>> AVMAP protocols for best display on those GPS units.

>> 4) HAMHUD should almost be able to display the 
>> [GPS-A] formats directly after removing the CRC?
> 
> If the HamHud group fully implements the D-PRS 
> specification, then it would be able to properly 
> display both GPS and GPS-A formats and that would 
> be a welcome addition to the D-PRS/D-STAR world.
> 
>> 5) For those GPS units that can also display 
>> text messages (I think the NUVI?) we need the 
>> PIC converters to parse out and display the 
>> valuable 20+ bytes of APRS text information for
>> display..
> 
> No, because this is not "valuable" 20+ bytes 
> of APRS text information.  This is a preprogrammed 
> message in the sending radio that contains the D-PRS 
> information and a short "salutation".  This is all 
> well defined in the D-PRS documentation.  It is a 
> mistake to confuse the term "message" in the Icom 
> documentation with what those 20 bytes really 
> are: a preprogrammed salutation.

Yes, and I am not talking about those.  I am talking about the
leading 20 characters of free format text that is included in
almost all APRS position reports that contain the free field
textual information that makes APRS an information system
instead of just a vehicle tracking system.  So you
missinterpreted my use of the term "valuable 20 bytes"..  So
when D-PRS sends out a GPS-A formatted APRS packet, I want
whatever displays we come up with to display at least 20, (28 is
better) or the full 37 (best) of the original APRS spec for that
text field.
 
>> 6) Such displays and devices should also consider 
>> adding APRS messaging... [within the D-PRS spec]

>> A) The mechanism for the GPS and GPS-A data converted
>> to APRS by D-PRS to also go directly to local APRS RF 
>> from the D-STAR repeater/gateway to an attached radio 
>> and TNC is called an ["IGate".  There are no serial 
> ports on the repeaters.  The serial data stream is 
> available to javAPRSSrvr(s) running on the gateway PCs 
> to provide D-PRS reporting.  

> Again, this has nothing to do with APRS and should 
> be (and is) discussed on more appropriate D-STAR 
> forums.

But that is an important point of this discussion.  How does the
local D-STAR mobile position data, get back to the local
surrounding APRS users?  Sure it gets to the APRS-IS and the
world, but it should more importantly be injected into the local
APRS channel directly on RF...  APRS is a local RF system (which
just happens to have global visibility)...

> Rich's SmartDigi does this same IGate function 
> using a D-STAR radio and a analog radio tied 
> together (the 2820 can be configured to work with 
> the SmartDigi in this mode using both "sides" of 
> the radio).  This, however, is not done at a 
> repeater site for numerous reasons.

OK, so that is the function I was after.  It takes the local
D-STAR mobile data and gets it to local APRS RF channel?  If so,
that's good.  That's half the funciton I am after. 

> [On] the D-STAR transmission medium... we require 
> the path for GPS-A mode to include DSTAR* and 
> "packets" generated from the GPS mode to APRS 
> translation also carry that as the path. This 
> denotes the D-STAR network as the origin vs. 
> the TCPIP* of the (APRS-IS) network...

>> B) How is this APRS data that is transmitted 
>> from the D-STAR/D-PRS gateway timed or metered 
>> onto the low data rate sub-channel so it does 
>> not interfere or tie-up the channel for
>> voice users?
> 
> It is not.  It is called an IGate and performs 
> exactly as such.  Because it is a voice medium, 
> it should not be viewed as a data medium and bulk 
> gating to a D-STAR channel will interfere with 
> voice communications.  

Which gets us back to square one.  The last paragraph of the
Introduction in your paper says that the "bridge can also pass
APRS packets via the D-STAR DV low-speed channel in TNC-2
format."  It is the display of those local APRS packets that I
want to enable for the D-STAR mobile operator via GPS, or HAMHUD
or any others simple displays...

> GPS information is provided by Icom on their radios 
> as an adjunct to the primary voice communication, 
> not as a replacement for voice communication.  This 
> is a key point that you seem to continue to not 
> comprehend or ignore.

No, I am confused since I want to use this bidirectionality of
the D-PRS  translation to send limited local APRS position and
other information to the D-STAR mobiles for display.  It seems
that to fit in the narrow confines of this DV low-speed channel
that there has to be some kind of filtering or metering to
restrict this information only to APRS packets of immediate
local value to the D-STAR mobile operator.

>> C) Do all D-STAR radios that are monitoring that 
>> D-STAR repeater pass this same low rate data to 
>> their clients, or are there addressing issues?  
>> In otherwords, is it a broadcast for everyone 
>> on the channel at the same time.?
> 
> Please refer to the D-PRS white paper and to 
> D-STAR documentation.  You are now off-topic as 
> you are asking D-STAR specific operational questions.  

I have.  I cannot find any mention in that paper about what
kinds of APRS packets will be translated by D-PRS back to the
D-STAR mobile via the low rate DV channel.  It is the nature of
those packets, how are they filtered to contain only local
information, and how we are going to display them that I am
interested in.

> From a user standpoint, D-STAR is like any other 
> amateur radio voice communications: there is no 
> private channel.

Good, so therefore any D-PRS translated APRS packets that get
sent back out to the D-STAR mobiles via the DV low rate channel
will all be able to display this information.

>> Please look again at the SUBJECT line of this entire thread.
>
> Bob, the subject line is only part of what started
> this thread.  You have consistently asked for the 
> modification of the Icom radios (to "fix" their 
> "limitations") and that was an integral part of your 
> original post.

Yes, and once you pointed out that the radios cannot display any
GPS or APRS information I immediately shifted the SUBJECT to a
Pic Processor and external displays for D-STAR mobiles over 20
messages ago.  Please lets just focus on that for now.

>> It is the display of APRS type of information 
>> that I want to see consistently displayed to the 
>> mobile operator independent of whether it comes 
>> to him via APRS on a Kenwood or Yeasu, or via
>> D-PRS and an add-on display to the D-STAR user...
> 
>> Sorry, I consider anything that can carry "extra 
>> bits" (or a low data rate subchannel) to the mobile 
>> operator as having the potential for compatibilty
>> with display of APRS type information...
> 
> And that is not what the D-STAR DV "extra bits" 
> are all about.  

But why not?  You have made D-PRS bidirectional so that it can
send APRS information back to the D-STAR users on that DV low
rate channel.  It seems like all we need to do is figure out the
filtering mechanism so that this channel (via the add-on PIC
processors, and map display GPS's and HAMHUDS) can send back
only immediate local APRS information that the mobile user
should see on his GPS map and his HAMHUD or other PIC derived
display...

>> Sort of...  I see any combination of a GPS 
>> and a RADIO as being a potential platform for 
>> use in the APRS system....
> 
> But sometimes they aren't because their design, 
> intent, and transmission medium are not designed 
> to be use that way.  At that point, don't demean 
> their designs (as you have in this thread) because 
> they don't fit your concept of how radios 
> should be used.

I am sorry you read my efforts as demeaning.  They are not.
They are trying to see what we can do to display the local APRS
information to the D-STAR mobile operator.  It seems all the
pieces are there:

1) D-PRS is bi-directional
2) GPS's and HAMHUDS can display lots of APRS information
3) The D-STAR DV low rate channel can carry D-PRS translated
packets

Im just trying to get us to agree on how to glue this together.
It seems the missing element, but the one I have aluded to, is
simply how to filter down the APRS stream so that only APRS of
immediate local interest in the vicinity of the D-STAR repeater
are sent back to those users.  And it seems that this can be
done simply by the application of the existing filtering options
in your various software..

Something like that.

Bob, WB4APR