[aprssig] PIC processor for APRS info for D-STAR mobiles?
bruninga at usna.edu
Mon Jul 7 09:34:33 CDT 2008
OK, now that we have all that out of the way, Is this then a
summary of what is involved to accomplish the objective of
displaying local APRS information for the D-STAR mobile
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.
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)
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.
4) HAMHUD should almost be able to display this data directly
after removing the CRC?
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
6) Such displays and devices should also consider adding APRS
Now for the things I am still not clear about:
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.
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
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.?
>> Great! This is just what I was looking for in
>> the first place in my original private request...
>> to make D-PRS by-directional so that we could
>> have displays for D-STAR users of local (APRS type)
> I explained that the radios and the protocol do
> not support what you desire (modifying the front
> panel from the data port) by design and that was
> not going to change.
Which I understood and then shifted to an external display
concept, and later, the idea of approaching ICOM and seeing if
they would consider adding this display capability once we
worked out what we wanted...
> ...It just isn't going to the front panel of
> the radios which has been the entire thrust of your
> communications (to "fix" the Icom radios).
No, that was the initial question about 50 emails back. But
once you said it was impossible, I then moved on to work around
that.... See subject line of this thread.
> No, you wanted D-PRS to convert to the GPS
> strings for display on the D-STAR radios
> which it does not do because that is not
> supported in the D-STAR protocol or Icom's radios.
Please look again at the SUBJECT line of this entire thread. It
does not say "for display on D-STAR -radios-. It says "for
D-STAR -mobiles-" which I intended to mean for the person who is
operating the D-STAR radio. It is that -person- that I am
trying to find a way to display APRS type information, no longer
via the radio front panel...
> As I have reiterated many times to you:
> that is being done already by individuals
> familiar with D-STAR and does not
> belong on an APRS list.
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
> And, by the way, it is not a "nice low rate data
> channel". It is a voice transmission that
> carries extra bits. As I also told you...
Sorry I must have missinterpreted your message of 4 July at
11:59 when you said: "The D-STAR DV protocol is a -voice-
protocol that carries a very low speed data subchannel..." I
was trying to use those words faithfully...
> .... As I said before: D-STAR digital voice
> is not a data protocol and the specification
> does not include any level of compatibility
> with APRS.
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 the D-STAR specification is done, not
> something being worked on. And you are coming to
> the table a few years late in your desire to
> have APRS built into the Icom radios.
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.
> You look upon D-STAR radios as "limited" and
> needing to be "fixed" because they don't display
> or work they way you want.
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
if ICOM is going to promote a radio that transmits GPS, it seems
that it should also display the positional information of
surrounding other stations... Not just be another transmit-only
> The D-STAR designers and the Icom engineers
> look upon their radios as outperforming their
> expectations and providing an exemplary
> platform for digital voice and high speed
> digital data communications (high speed digital
> data (DD) is the 128 kbps Ethernet bridging
> capability for bands where the bandwidth is
I am sure it is. There is great potential for this high speed
data communications. Im just looking for a way to display local
APRS information to the mobile operator in the meantime while
using D-STAR voice mode without having to require an APRS laptop
in the front seat. I think my proposed use of PIC processors to
convert for display on existing GPS's and HAM HUDS is a first
start in that direction.
I'm hoping we can all work together on this.
More information about the aprssig