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

[Gerry Creager N5JXS]

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 manufactures 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 much
>> more compatible (and simpler to implement) if the clients think they 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.  In
>> 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 through a 
> TNC.  Today, I am not aware of anyone using this.  But, what I would 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 correctly.

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 (think, 
"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 alternate 
> processing by the software on the receive side of the DSTAR link.  In 
> particular, it could be used to say "just send this to RF" instead of 
> "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 to do APRS by 
> hooking up their GPS through a little PIC assistance device 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 alternatives. 
  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 useful."

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