[aprssig] Did ICOM DSTAR ever take off ? can it be used for APRS ?

Tue Jun 21 09:59:30 CDT 2005

Hey, if you take this off the list how about CC me
(christensene at mail.ecu.edu) on your discussions, please.


-----Original Message-----
From: aprssig-bounces at lists.tapr.org
[mailto:aprssig-bounces at lists.tapr.org] On Behalf Of Gerry Creager
Sent: Tuesday, June 21, 2005 10:30
To: gregg.wonderly at pobox.com; TAPR APRS Mailing List
Subject: Re: [aprssig] Did ICOM DSTAR ever take off ? can it be used
for APRS ?

More'n likely we're gonna have to take some of this off the main
list; it's about to go real technical.

DStar uses ATM instead of (a)x.25 for its primary Layer 2/3 protocol.

It's a nailed up connection for data, through the network using a
"permanent" virtual circuit, so both ends know who is talking.  Use
of ATM for this sort of thing isn't necessarily the most ingenious
thing for wireless telecommunications, but there are some reasonable
reasons to go there.

Gregg Wonderly wrote:
> AE5PL Lists wrote:
>> No, it is not "8 bit clean".  The radios use Xon/Xoff flow control

>> and use CR/LF as line terminators for position reports.

I should know more after FD weekend.

> Okay, that's unfortunate that it does that.  The devices that you 
> would connect to the other end in text mode already do line 
> termination.  I'm curious if its not the GPS's CR/LF that you are 
> seeing.  The use of inband flow control is a problem as well.  They

> should have used out of band signaling.  Seems like the
> still haven't looked at the commercial RF network equipment such as

> that of FreeWave or others which provide an 8bit clean transport.

Would have required another PVC and the additional overhead.

>> While some clients do not support direct KISS interfaces, to my 
>> knowledge all do support TNC2 format interfaces.  It is actually
>> more compatible (and simpler to implement) if the clients think
>> are looking at a standard TNC2.
> The problem is that this mode does not include a from call in the 
> packet.  With KISS, the transported data is identified with a from 
> call and a PATH so that it can be routed.

The PVC connection takes care of this.

>> Also, the D-Star radios don't allow RF routing as you describe.
>> fact, there are no connections made with regards to this type of 
>> operation (broadcast, just like APRS was designed to use).
> What I'm refering to is that in the KISS frame there is a 'source' 
> device byte.  This can be used to allow multiple devices talk
> a TNC.  Today, I am not aware of anyone using this.  But, what I
> use it for is sending APRS vs GPS vs Weather packets through an
'APRS box'
> to a computer application that would then process the data

However, this isn't (a)x.25 OR IP, although they do employ "classical
IP" over ATM... but the services for broadcast and unknown hosts
"arp") aren't there.  That's a limitation of ATM... or a feature if
you are an ATM fan.  There's some work about to start looking at this
and its mitigation.

> In the case of the DSTAR system, it could be used to select
> processing by the software on the receive side of the DSTAR link.
> particular, it could be used to say "just send this to RF" instead
> "read my path and do what it says".
> I am thinking that this would be a form of DSTAR digipeating.  
> Everyone in an area could use DSTAR radios instead of radio + TNC
> do APRS by hooking up their GPS through a little PIC assistance
> that wrapped the data into a KISS frame (like the HAMHud does).
> But, if it is not 8-bit clean, then KISS is not a choice and thus 
> everyone can't share a single DSTAR receive site as a 
> digipeater/translator.

However, accumulating ideas of this sort may lead to other
  It's a new product.  It wasn't designed with APRS as a primary
function, but more as "Hmmm. We could add this... It might be

Gerry Creager -- gerry.creager at tamu.edu
Texas Mesonet -- AATLT, Texas A&M University	
Cell: 979.229.5301 Office: 979.458.4020 FAX: 979.847.8578
Page: 979.228.0173
Office: 903A Eller Bldg, TAMU, College Station, TX 77843

aprssig mailing list
aprssig at lists.tapr.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3116 bytes
Desc: not available
URL: <http://lists.tapr.org/pipermail/aprssig/attachments/20050621/090f5b47/attachment.bin>

More information about the aprssig mailing list