[aprssig] PIC processor for APRS info for D-STAR mobiles?
Pete Loveall AE5PL Lists
hamlists at ametx.com
Sun Jul 6 13:00:47 EDT 2008
> -----Original Message-----
> From: Bob Bruninga
> Sent: Sunday, July 06, 2008 10:51 AM
> To: TAPR APRS Mailing List
> Subject: Re: [aprssig] PIC processor for APRS info for D-STAR mobiles?
>
> 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....
Bob, that is flat out false! I told you that D-PRS is bidirectional for APRS clients. I also told you factually that the D-STAR radios do not use the callsign,message line for display on their front panel and the user does not have access to that front panel display from the data port. Finally, I told you factually that the GPS string transmission of the Icom radios is not a protocol and does not provide the ability to convert from APRS to those strings for display on the Icom radios. Finally, I did not "show no interest" in pursuing this any further. 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 is exactly what I was exploring and asking... How can we display
> this information?..., but it got buried in all of your responses.
No, it was there privately, on the web site, and elsewhere: any APRS client can implement the published spec or use a converter such as D-PRS Interface and Smartdigi to display this information. 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).
> 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.
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.
> 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).
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. 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, you may consider that an irrelevant distinction, but it is critical to the effective use of the D-STAR transmission medium.
> I dont care about the exact protocols. That is only the delivery
Obviously.
> 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.
Nope. 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. 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. It is, as I have said, a difference in how the D-STAR designers look at communications and how you look at communications. Their view is just as valid (if not more so) as yours. And this is where you and I have a strong disagreement. You look upon D-STAR radios as "limited" and needing to be "fixed" because they don't display or work they way you want. 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 available).
73,
Pete Loveall AE5PL
pete at ae5pl dot net
More information about the aprssig
mailing list