[d-star] Fwd: DStar and EMCOMM

[Mark]

--- In illinoisdigitalham at yahoogroups.com, "djs13" <djs13 at ...> wrote:

This is a reply to a post in another group (original message at the
bottom. I am resending it here because you folks have a very active
group and I think the topic has come up before. I hope it has some
benefit for you folks.

Dan S
KO1D/4
__________________________________________

Les, 

I am up here in Falls Church, VA just outside of Washington, DC and 
we
have come up with a lot of applications for DStar in EMCOMM but only 
a
few have been put into practice. First thing is voice is out for
EMCOMM. There is not enough market penetration to make effective use
of voice. The focus we have determined is the 1.2GHz digital data
aspects. I want to say immediately I am not taking credit for any of
the ideas below other than the remote volunteer check-in (that was a
pipe dream that become plausible upon further investigation but yet 
to
be implemented). The rest of the ideas belong to a lot of other 
people
but they are ideas I agree with and believe in. 

We used DStar for the first time last year at the US Marine Corps
Marathon. In that setting the served agencies are the US Navy and US
Marine Corps. Our job is to work for the senior medical officer and
facilitate timely communications between the Aid Stations, mile
markers, straggler buses, water and food stops and any other location
assigned by the TOPDOC (usually a US Navy Captain.) Voice, APRS,
Packet, and DStar are all used to accomplish the mission 
requirements.

We rolled out about 9 stations supporting 7 Aid Stations, Net 
Control,
and the Command Operations Center plus an access point as part of 
what
is termed an Operational Readiness Exercise (ORE). The ORE's main
purpose was to determine if DStar DD is a feasible and practical
application for supporting the USN and USMC. Users had some training
on the units for a month before the race. The success threshold was
having reliable communications for 4 Aid Stations for the duration of
the event. The effort was led by Tom, N4ZPT as the Digital Branch
Coordinator within our ICS structure. Working with many others
including support from the K5TIT group and Icom America, a high speed
data network was developed over the course. (The course is a 26+ mile
long roughly star shape winding through portions of Arlington, VA and
Washington, DC. We dealt with concrete canyons as well as real rock
formations plus a few other aspects of 1.2GHz propagation to learn
about.) 
The primary mission of the ORE was to record and exchange data on
runners being checked into the aid stations then send that 
information
to the main medical tent for the TOPDOC. This was stored in a 
database
on a server accessible by all race officials. They also ran a chat
program for coordination between aid stations, NCS and the command
element. The backup was 1200 and 9600 baud packet. All these systems
also dumped into a main race computer that showed loved ones where
their runners were through the chips on their shoes or our updates.
Using the ORE threshold for success we were 100% successful with the
additional benefit of L Band (1.2Ghz) experience in an urban
environment. Practical applications beyond the criteria set by the 
USN
and USMC showed us with the failures including a bad path, a blown
piece of equipment and laptop configuration issues.

As a side note a couple of the aid stations had 1 DStar unit and
multiple PCs utilizing it through a hub so that if you had a huge
crush of runners come in then one ham can be the control op and 
anyone
can sit and enter the data into the database. Other sites had a 
couple
DStars set up as a digipeater to help bridge some bad paths. Future
uses may include having medical officials solicit information from 
the
database. 

Measured data rates were maxed out at around 80-90 KB/s on clear
channels. Since the server was on the internet one guy wound up
ACCIDENTALLY doing all his Windows Updates on one box that had not
been used in a while. The bad part is he also effectively timed out
the served and crashed the channel a few times before the issue was
identified and resolved.

This year we are talking about taking it up a notch and delivering
ethernet connectivity to all Aid stations. This is the 2007 primary
mission requirement for the USN/USMC. Other enhancements being
reviewed and considered include developing a web based database for
race day where ham radio volunteers register at one of 3 remote sites
and then NCS and the Command Operations Center can get a report on 
all
those who have signed in. This will let us identify holes or gaps in
our coverage and additional assets that might be reallocated for
better uses. As people are released by the TOPDOC we then log them 
out
giving us accountability of our ops. We usually need about 120+
operators to do the event who come from Virginia, Maryland,
Washington, DC and as far away as Montana, Ohio and Texas. When 
spread
out over 2 states (DC is considered a State for legislation but not
voting) it gets interesting keeping tabs on everyone. There are also
some other areas where we can provide Ethernet connectivity over wide
areas that are being considered but not mature enough in the planning
to outline here.

These principles can be applied to EMCOM (and we have begun bantering
about it) this way. There are programs used by response agencies that
can network and help manage incidents. If the infrastructure were to
all go down the thought is someday DStar DD networks may help augment
the network until it can be restored on a local level. It's not 
access
to the internet these platforms need so much as users accessing 
common
databases. The big problem here is firewalls. Up this way it is not
easy to find an IT guy willing to let a bunch of hams pop a hole in
his firewall for emergency data communications. I would say he/she is
right in that presumption and we do not argue against that ever. We
just need to figure out that if this is needed how can we do it
outside the firewall so it's safe and effective.  Again another rainy
day, way down the road chat we have to explore. 

We also are looking at how to use DStar as a way of sending shelter
information to EOCs. Again a ways off but its being pondered on what
we could do, how we could do it and why it would be needed. 

We also have talked about using 1.2Ghz as a 128kbs tcp/ip backbone
from 9600 bps gateway. Users would go in on normal packet at 1200 -
9600 baud and then it would go out on 1.2Ghz through the network to a
gateway or another packet node. This could be a way of supporting
Winlink or similar applications in the future.

I am not a computer or networking guy so my learning curve on this is
still steep and if I misspoke on terminology bear with me. I can say
though the best thing I have learned is that the DStar 1.2 GHz DD
applications can be used just about anyway you can use a wireless
network. The cons are cost, low market penetration and limited
coverage. You need a lot of 1.2 GHz infrastructure to cover some
areas. Right now there are less than 5 full stacks in the area only
one of which is fully on line. Others are either in the planning
stage, procurement stage, assembly stage (1 module at a time) or
testing stage. It's a matter of time and money frankly. 

Basically the summation is: use your imagination. Again if a wireless
network can do it so can DStar. 

Dan S 
KO1D 
Falls Church, VA 
MCM Planning Team Member 


----Original Message Follows---- 
From: "lowga" 
Reply-To: al-dstar at yahoogroups.com 
To: al-dstar at yahoogroups.com 
Subject: [al-dstar] EMCOMM Applications for D-Star 
Date: Tue, 01 May 2007 18:46:15 -0000 


I've been queried by some local emergency managers about the 
potential 
use of D-Star for EMCOMM. I'd like to hear from the group about 
current and future potential use of D-Star for emergency 
communications within the state of Alabama. 

What would you say the "Killer Application" that D-Star offers our 
state vs. our traditional analog systems or other amateur 
technology? 

73, 

Les Rayburn, N1LF

--- End forwarded message ---