<div>Can you explain it to me? I really have no knowledge of how dstar works, except that in low speed mode, 3600bits/s is voice and 1200bits are for "data". Can this data be GPS NMEA data? I have heard thru the group in Charleston SC that this data is only sent once per keydown, so continually streaming GPS data into the serial port while keyed down talking won't actually send data continuously.... my understanding such that when you first keydown and start talking, data is sent alongside the 3600bits of voice until that data has been sent (is it 128bytes?), and after that only the voice is sent leaving 1200bits unutilized. Is this correct? Is this data sent to all stations? Does it appear on their serial ports? </div>
<div> </div>
<div>*IF* what I'm thinking is correct, what would be wrong with sending a full text version of an aprs packet into the serial port while tx'ing voice? I know that using a conventional TNC, I only send the "data" portion to the tnc, and the tnc pre-pends my callsign and path to that data as a part of ax.25. But the fulltext would be to send the whole aprs packet, source callsign, path and data all at once. Like the aprs-is stream. I realize that this is a kludge and that there's a lot more to the dstar protocol, but icom doesn't let us play with the rest of dstar, so work with what we've got, right?<br>
</div>
<div>*IF* what I'm suggesting would work, yes there would be a certain degree of redundancy. Dstar would have my callsign embedded in it's data (which you say we can't see anyway), and my callsign would also be in the aprs data that I'm sending using the 1200bits. And then there'd be the chance that I'd set my callsign on the radio differently than the aprs data indicated.</div>
<div> </div>
<div>Can data appearing on this port cause the radio to keyup and autotx?</div>
<div> </div>
<div>Will dstar dv pass through most 2m analog repeaters? (completely off subject, but FWIW, we can send 1200baud packet through analog repeaters provided the TXdelay is long enough, but not over IRLP due to the audio compression)<br>
</div>
<div>Do the icom HT's have a serial port? Do the icom mobile units have a serial port?</div>
<div> </div>
<div>Wes</div>
<div> </div>
<div> </div>
<div class="gmail_quote">On Sat, Jul 5, 2008 at 6:52 AM, Pete Loveall AE5PL Lists <<a href="mailto:hamlists@ametx.com">hamlists@ametx.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">So the group understands, the D-STAR protocol is not made available to radio users. A TNC makes the AX.25 protocol fully available to a user so things like APRS can be implemented. The reason is AX.25 is a -data- protocol and the TNC is simply a modem with some extra logic to simplify access to the AX.25 protocol.<br>
<br>A D-STAR DV (digital voice) radio uses the D-STAR protocol to provide reliable -voice- communications between radios. The protocol overhead such as the RF header is not made available to the user as it is integral to the proper operation of the radio. Icom allows a user to preprogram a message into a radio that will display every time the user transmits. This message is displayed on the remote radio's front panel IF the remote radio has this ability enabled (and IF it is capable). What Bob refuses to accept is the fact that this information is not carried over the portion of digital voice stream the user has access to. It is completely hidden. The radios in GPS mode also expose this information (callsign and canned message) over the user accessible data portion of the digital voice stream, but the radios do not use this exposed information. The radios continue to use the hidden transport mechanism for displaying callsign and this canned message.<br>
<br>This significant difference in the protocols and how they are exposed is why trying to use the radio's display for 2-way communications is not only futile, it is misguided and exhibits is a strong lack of understanding of how the D-STAR protocol is designed and how Icom implemented their -complimentary- data capabilities. Bob approached me on this subject over a week ago and I provided this same information. Unfortunately, he refuses to understand the fundamental differences in the protocols and the radios as demonstrated by his post to this group. I am sorry that someone who this group highly respects would push logic and understanding aside to pursue something that has already been explained to him why it does not work that way.<br>
<div class="Ih2E3d"><br>73,<br><br>Pete Loveall AE5PL<br>pete at ae5pl dot net<br><br></div>
<div>
<div></div>
<div class="Wj3C7c">_______________________________________________<br>aprssig mailing list<br><a href="mailto:aprssig@lists.tapr.org">aprssig@lists.tapr.org</a><br><a href="https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig" target="_blank">https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Wes<br>---<br>Where there's silence, there is no Hope.