[CTxDSstar] A new kind of DSTAR net, news, dplus, dprs/aprs

[ke5c]

Hi All (UR=CQCQCQ)!

-----PLEASE-----

If you know a central texas dstar user who does not belong to this list, 
ask him/her to subscribe at http://www.kkn.net/mailman/listinfo/ctds - 
thank you!

-----A VERY NEW KIND OF DSTAR NET----- 

Join Robin, AA4RC, this Sunday (tomorrow) for the first multi-gateway, 
world-wide net TEST at 10 AM LOCAL TIME on K5CTX B or W5HAT B.  This 
will be a directed net, so transmit only when solicited and end your 
transmission with "over".  To participate, your radio must be 
programmed:

UR = CQCQCQ
RPT1 = K5CTX^^B (^ = space)
RPT2 = K5CTX^^G

or

UR = CQCQCQ
RPT1 = W5HAT^^B (^ = space) - the C-module will not be linked
RPT2 = W5HAT^^G

During the previous, and in my opinion mostly unsuccessful net test, an 
ICOM implementation known as "multicasting" was employed.  Each 
participating gateway set up a "multicast list" of other gateways 
participating.  Users set their UR to the list name ("/SUNDAY" if you 
participated).  Then the K5CTX gateway sent simultaneous digital voice 
data streams to each and every one of the other gateways in the list. 
This placed a bandwidth strain on many of the participating gateways, 
and a ten gateway limit is not very useful.

Tomorrow's net will BETA TEST a completely different technology. 
K5CTX^^B and W5HAT^^B will use "dplus" (more later) to send a single 
digital voice data stream to a high-bandwidth "reflector" as will all 
other participating gateways.  This high-bandwidth reflector will 
"repeat" each incoming digital voice data stream to the other connected 
gateways (and dongles - more on that later too).

Comments from the designer, Robin Cutshaw, AA4RC:  "There are a few 
benefits of linking over multicasting for this net. First, there is not 
a 10 gateway limit. We are limited by the bandwidth of the reflector. 
Second, each gateway will only need one voice streams bandwidth. 
Multicasting uses 10 voice streams worth of bandwidth for a 10 gateway 
net. Third, DV Dongle users will hear and communicate with the entire 
net. They should connect to reflector 001 module C for the net to 
minimize gateway bandwidth requirements. As Sunday will be the first 
real test of the new code and of reflector one’s bandwidth, please be 
patient if we encounter problems. I’m hoping that this will add a new 
tool to our D-Star toolbox. I could see, for example, impromptu nets for 
EMCOMM activity, city wide weekly nets, places for DV Dongle users to 
meet where there is no RF, etc."

-----AREA STATUS & NEWS-----

W5ZDN^^C Waco - Gus, KD5DZU, is working out a routing solution for the 
gateway interconnect with the public service site owner while Rodney, 
K5YKC, cheers him on.  Gus and Rodney, please encourage your users to 
join this mail list.

KE5RCS Walburg - Brad, KV5V, and Mark, NA6M, are working on site power 
distribution and metering.  Gateway software installed and ICOM 
approved.

W5KA^^^C Austin - On the air at a temporary site, no gateway 
interconnect - Jim Trulove, WB5EMI

W5HDR and W5HDT Houston - both operational but I forget which bands.  I 
heard NU5D work Alan, KB2WF, sysop/admin for both, a few mornings ago on 
both machines.  Alan - please post an update if you would and encourage 
your users to join this mail list.

CALL? - Killeen, TX (Douglas Mountain?) - constructing - James Kennedy, 
WU5E

W5HAT^^B and C Bruceville - fully operational.

K5CTX^^B Temple - fully operational.  A-module will soon return to 
operation.  C-module might appear.

KE5KAF^C Laredo - fully operational, often linked to K5CTB^^B - Aaron, 
VA6AE

-----DPLUS-----

Currently the DStar "world" encompasses two entities - ICOM's 
implementation of the JARL DStar specification and the opendstar.org 
group's dplus software and DV Dongle hardware and software.  ICOM's 
product range includes all the currently available commerical radios, 
repeater modules, controller modules, and gateway software.  Most of the 
operating instructions and manuals describe only what is possible with 
the ICOM portion of the system.

The opendstar.org group is led by Robin Cutshaw, AA4RC, and Moe 
Wheatley, Jr, AE4JY, but there are others behind the scenes.  They 
created the first non-ICOM DStar demonstration radio (which I saw and 
heard in Dallas at Hamcom last year), the dplus software which I view as 
a gateway "extension", and the DV Dongle which allows a PC/MAC/Linux 
laptop or desktop computer to talk to dplus equipped gateways.  The 
dplus software runs parallel with the ICOM gateway software and adds 
several features to the DStar operating environment, one of which is 
"linking" gateways to each other and linking gateways to "reflectors" as 
in the net announcement above.

Practically, here is how dplus may effect you.  From time to time you 
may hear messages such as "remote system linked", "remote system busy", 
"system already linked", "system unlinked", and a few others as a result 
of a gateway sysop linking or unlinking a gateway to another gateway or 
a reflector.  Hopefully the sysop will make an announcement of what has 
just happened.  Currently K5CTX^^B is often linked to KE5KAF^C in Laredo 
and occasionally to W5HAT^^B in Bruceville.

In order for DV Dongle users to talk with gateway users, gateway users 
(you) should program UR to CQCQCQ, R1 to K5CTX^^B (or A or C) and R2 to 
K5CTX^^G.  You would program for W5HAT or another gateway in a similar 
fashion.  When DStar first started, the recommendation for local 
chatting was to program UR to /K5CTX^B and leave R2 empty.  Please 
follow the current recommendations instead.  Programming UR to /K5CTX^B 
while you are on K5CTX^^B causes a peculiar audio distortion on dongles.

opendstar.org and related links:

http://www.moetronix.com/dstar/

http://www.moetronix.com/dvdongle/index.htm

http://www.dvdongle.com/DV_Dongle/Home.html

http://opendstar.org/tools/readme.txt (gateway tools)

-----DPRS TO APRS GATING-----

Brief overview - When APRS first started, APRS packet transmissions on 
VHF (usually 144.39) were received by other TNC's connected to desktop 
computers running "APRS Clients" - programs which would map the 
geographic location and/or some status information of transmitting 
stations.  The EMCOMM idea was to have a command center receiving 
location and status information from local service facilities and 
vehicles and to pass short messages.  As with other VHF activities, 
repeaters (digipeaters) soon appeared extending the possible distance 
between clients (command centers) and field users.  A number of issues 
developed and were mostly resolved with channel congestion, digipeater 
looping, etc.  The range of coverage was then greatly extended with the 
"APRS-IS" creation - APRS Internet Service.  This allowed "third party" 
transport of APRS packets over internet connections in addition to RF 
links.  A station with an internet connection and an RF connection would 
run a special program called an IGate (internet gate) to transfer 
packets received on RF to the internet and vice versa.  Igate capability 
is a feature of several APRS clients including UIVIEW, Xastir, 
javARPSSrvr, and others.

DStar radios have a low-speed data subchannel which can be used to 
transmit, among other data, GPS information.  Another gateway extension, 
a piece of software not part of the ICOM commercial offerings, called 
dstarmon adds a number of features to DStar.  This piece of software 
powers http://dstarusers.org/ which is where you can see who has 
recently transmitted on which gateway.  dstarmon (with javAPRSSrvr) also 
routes valid GPS data from the low-speed data subchannel of a GPS 
equipped or connected DStar radio to the APRS-IS just as if it had been 
heard on 144.39 coming from a conventional APRS transmitter rather. 
Thus you can go to www.findu.com and see DStar entered GPS data, e.g.:

http://www.findu.com/cgi-bin/find.cgi?ke5c

The raw packet:

KE5C>APDPRS,DSTAR*,qAR,K5CTX-B:!3104.33N/09723.58W>235/000 
JOHN at KE5C.NET/A=000600

is read as KE5C transmitted a DStar originated posit report (APDPRS) via 
DStar (DSTAR*), and the posit report was entered into the APRS internet 
service (qAR) by a verified client, K5CTX-B.  The packet payload is 
KE5C's latitude, longitude, course, speed, message, and altitude. But 
what if the Temple Bicycle Race command center has volunteers with DStar 
radios rather than APRS setups, and the command center has only an RF 
connection and thus cannot receive DStar posit reports from the 
internet?  The answer to that situation is to "gate" the DStar posit 
reports not only to the APRS-IS but also to RF on 144.39 FM.  Both W5HAT 
and K5CTX do this with the co-located IGates W5NCD-15 and KE5C-15.  Here 
is an example of that in action:

packet received by dstarmon from a DStar GPS connected ID-800H:
AD5RS>APDPRS,DSTAR*,qAR,K5CTX-B:!3104.32N/09723.58W> MATT/A=000604

packet transmitted on RF:
KE5C-15>APJI23,W5NCD-15:}AD5RS>APDPRS,TCPIP,KE5C-15*:!3104.32N/09723.58W> 
MATT/A=000604

is read as KE5C-15 transmitted via a javaprssrvr IGate a packet with an 
RF routing of via W5NCD-15.  The packet is a "third-party" packet 
because KE5C-15 received it via the internet.  The payload is simply the 
original packet.  All common APRS clients map third party packets just 
as if they were heard off-the-air.

related links:

http://www.aprs-is.net/DPRS.aspx

http://www.aprs-is.net/javaprssrvr/

73 - John