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

[Pete Loveall AE5PL Lists]

> -----Original Message-----
> From: Robert Bruninga
> Sent: Monday, July 07, 2008 9:35 AM
> To: 'TAPR APRS Mailing List'
> Subject: Re: [aprssig] PIC processor for APRS info for D-STAR mobiles?
>
> 1) The D-PRS engine receives GPS or GPS-A data from D-STAR
> radios and ports this over to the APRS-IS in APRS format.

Not exactly.  D-PRS is a translation algorithm that is independent of APRS-IS.  I do encourage you to read the white paper available for download at http://www.aprs-is.net/dprs.aspx  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 if the D-PRS translator is connected to APRS-IS.  This translation can be done using one of the existing applications (D-PRS Interface, javAPRSSrvr, or SmartDigi), or can be implemented directly into an APRS client by that client's author(s).

> 2) The D-PRS engine receives APRS packets via javAPRSSrvr (as
> limited by filters) and sends them back to D-STAR users via the
> low rate data subchannel for display on attached APRS clients.
> (these clients have to use D-PRS Interface and have to be able
> to connnect via TCPIP)

No, again you are trying to make this too complex.  Number one, there is no "D-PRS engine".  D-PRS is a translation algorithm which also supports formatting APRS "packets" for transport across the Icom-provided data subchannel on the D-STAR digital voice stream.  The D-STAR digital voice transmission medium is considered the same as any other RF transmission medium with regards to what gets sent over it from the D-PRS standpoint (read "IGate").

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

Again, this needs to be done within the confines of the D-PRS specification.  If you do not, you will most definitely be painting a bunch of garbage on those displays.

> 4) HAMHUD should almost be able to display this data directly
> after removing the CRC?

Only GPS-A format.  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.

> 6) Such displays and devices should also consider adding APRS
> messaging...

Within the confines of the D-PRS specification.  It is important that they do not try to manipulate the GPS mode information as it will render it useless.

> A) Is there a mechanism for the GPS and GPS-A data converted to
> APRS by D-PRS to also go directly to local APRS RF at the D-STAR
> repeater using an attached radio and TNC?  Its not yet clear to
> me how this direct transmisrion to local RF is done.

Yes, it is called an "IGate".  There are no serial ports on the repeaters.  We have made the serial data stream 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.  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.

It is also important to understand that the D-STAR transmission medium is considered a different network from the analog APRS network in the D-PRS specification.  This is why 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* (APRS-IS) network, for instance.  This is extremely important to accommodate differences in the various transmission mediums (a downside to the close-coupling of APRS with its transmission mediums but something we know how to compensate for).  Again, all of this is explained in the D-PRS white paper/specification.

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

> 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.  From a user standpoint, D-STAR is like any other amateur radio voice communications: there is no private channel.

> Please look again at the SUBJECT line of this entire thread.  It

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.  As I pointed out to you originally and subsequently, it that is not an option and you have fought that all the way.

> 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 (and possibly
> future ICOMS)..  In fact, if I understand it correctly D-PRS
> simply adds a CRC in front and then sends all of the original
> APRS formats.

For gating of APRS information and that is already take care of.  You can claim innocence in all of this, Bob, but bottom line is you still consider the D-STAR radios as data radios and they are not.  They are digital voice radios.

> protocol that carries a very low speed data subchannel..."  I
> was trying to use those words faithfully...

Well, you failed as you apparently still don't understand the concept of a voice signal that carries a control channel (that is what those bits are defined as) vs. a data channel.  You have said you "dont care about the exact protocols" but sometimes (as in this case) they are critical for understanding how to utilize the protocol's capabilities and determine what is and isn't possible.

> Sorry, I guess that is where we disagree.  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...  APRS is about display
> of local information, not just vehicle tracking...

And that is not what the D-STAR DV "extra bits" are all about.  This is a protocol issue which you have already said you "dont care about the exact protocols".

> Since ICOM is still one of the big three that does not support
> APRS directly, then I just think it is time to see what we can
> do to improve on that.

Your statements in this thread have done nothing to encourage Icom to want to work with you.  I can only hope that your comments will not set back the extensive work that many of us have put in place which has given us unprecedented access to the JARL and to Icom.

> Sort of...  I see any combination of a GPS and a RADIO as being
> a potential platform for use in the APRS system.  It seems that

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.

73,

Pete Loveall AE5PL
pete at ae5pl dot net