Where did the year go? No, really? What happened to 2015? It will go down as being warm. Thank you El Nino for providing us with one of the warmest Christmases on record. It was quiet, from a hurrican perspective in the Atlantic basin. Again, thank you El Nino. It was, weatherwise, a very calm year.
It was also a quiet year event wise. Prince William County ARES participated on one exercise, Operation Summer Deluge and a couple of Marine Corps runs providing safety and security on the course. We will be doing it again in 2016.
We have had a couple of quiet years. It has been nice. We have added new members, and focused on beefing up our digital activities. We will move on in 2016 to increasing our use of digital systems and work with Prince William County to integrate with their systems as best we can.
Our goals for 2016?
Practice, practice, practice. There is never enough time to practice.
Traffic handling. We need to practice traffic handling, both voice and digital. Again, we never practice this enough.
BBHN. I am looking forward to seeing what BBHN can do to improve our digital connectivity.
HF Digital. I would like us to work on our HF skills, and HF digital is an increasingly popular way to do that.
MCM support. We will again be supporting the Marine Corps Marathon program office at the Crossroads 17.75 and Turkey Trot directly as well as the Marine Corps Marathon indirectly.
Practice, practice, practice. Did I mention we will be doing lots of practice?
Want to get more invovled? Our next meeting is Saturday, January 16, 2016, at 0900 at the Prince William County EOC, 3 County Complex, Prince William, VA. Hope to see you there.
On Tuesday, August 11, PWCARES participated in Operation Summer Deluge, a full scale shelter exercise at Freedom High School in Prince William County.
On August 10, 2015, the remnants of a tropical storm struck Prince William County, Virginia. The storm caused an average of five to seven inches of torrential rainfall per hour overnight, causing ground saturation and flooding. Given the expected rainfall in the next 24 hours, there exists significant probability that an overtoping event at Lake Montclair Dam will occur, which could destroy at least a dozen home and displace households withing the inundation zone. The Director of Emergency Management has authorized the opening of a shelter with an anticipated need to shelter two hundred individuals.
An overtoping is EM speak for water will overflow the dam, and that is a bad thing.
There were numerous objectives, but for PWCARES, our objectives were straight forward:
Evaluate the shelter for radio opartions
Get traffic from the shelter to the EOC (and back)
Demonstrate BBHN for use in a shelter in the event of Internet interuptions
The exercise was for both a human shelter and a pet shelter, just in time training, and to practice shift change, starting at 0900 and ending at 1500.
PWCARES had the following operators:
ECIC: David, KG4GIY
First Shift: Chuck, KA3EHL and Mary, KK4GOW at the shelter. Keith, KM4AA and Ric, KJ4ZIH at the EOC
Second Shift: Zach, K4RSU and Spenc, KG4GFW at the shelter. John, KG4LAA and Jeff, WB6UIE at the EOC
BBHN: Clarence, K4CNM and Terry, WA5NTI
We used ICS-213 as our message template and ICS-214 as our unit log.
What went right:
We got a signal out of the shelter site using an antenna and a cross-band radio
We practiced sending traffic
We practiced a shift change, which is not something we have done
We got a view of the shelter operation process
We got to demonstrate BBHN
We gained valuable exposure for our skill and professionalism
What we need to work on:
CSALTT: We need to make sure our messages contain Capability, Size, Amount, Location, FEMA Type, Time needed
We need to practice sending messages via voice
We need to work on our digital set ups. While we did not do one for this exercise, we probably could have
We need to work on our handwriting. Many of our forms have to be read by others. Some options suggested include a portable printer at each site to print off messages.
It was a good exercise, with lots of opportunities to practice. A success in all people’s eyes.
On Saturday, July 19, 2014, the Prince William County ARES cadre took to the field for a communications exercise. The exercise was centered around a recovery operation, the day after a hurricane came through the region. There were seven operational stations representing the Emergency Operation Center, the two primary hospitals in the county, two shelter locations, and two points of distribution for supplies. The exercise was designed with a mixture of message types, both voice, and digital. The messages were representative of the types of traffic that would be passed during a normal activation. There were fifteen operators acting as the various locations. It was a successful exercise with numerous lessons learned and several opportunities for improvement in the coming months.
What went right:
One of the best exercises we have done! It was one of the first blended (voice and digital) exercises we have done as a cadre and the first real exercise we have done in the last couple of years.
Everyone using digital stations did manage to pass at least one message and the messages were received by every participating station.
Voice messages were passed.
What do we need to work on:
We need to work on our voice message passing. We are out of practice. Some additional work on “prosigns” and procedure needs to be done. Eric, KK4NXU has offered to spearhead an ARES practice network. Details to come.
Digital messages are improving but there is a request for:
Another confiruation session (including some documentation). David and Chuck have volunteered to host a configuration session in August.
A useage session was also requested to go through how to do things, like send message traffic. A session for this will also be set up.
We need to start moving the stations apart and to that end, as part of the potential ARES net, we will work on voice and digital. This is also a work in progress.
A PC in the EOC will need to be configured with FLDigi and be part of the EOC network for access to WebEOC for cutting and pasting. David will take that up with Pat this week.
July is traditionally a hot month. How hot? Well, during the CW150, held the last week in July a few years ago, I seem to remember losing several pounds in water over the four days we were supporting them. Average temperatures were between 90 and 105 and I had reports of highs upwards of 120 in certain microclimates.
We had such a great turnout at our last digital exercise, I would like to try another exercise with both voice and digital on the lawn at the EOC. But, like I said, it can be hot. I think it would be a good idea. But I am willing to listen to the majority on this and do something inside.
On Saturday, May 17, 2014, Prince William ARES took to the field in the green common in front of the McCoart building at the County Government Centre for a small digital exercise. The key goal was to set up one or more FlDigi stations and pass communications between them. A second goal was to set up a broadband hamnet mesh network. And finally, it was a great opportunity for the members of PWCARES to exercise their go-kits, digital gear, and work out in the field without commercial power.
Three “station” set-ups were provided. At the height of the exercise, as many as nine stations were in operation around the perimeter of the common and two different types of mesh networks were in operation. Most operators had a standard set up of a laptop, radio, and some type of external sound card device, such as SignaLink. A couple of stations tried the “headset to mic” interface method. At the end, four stations were able to successfully pass traffic, both ad hoc messages and more formal ICS-213 messages. These stations were all using SigaLinks.
Clarence provided a traditional broadband-hamnet network, with an access point connecting the field to the Internet.
Derek set up a mesh network that was a custom set up that was not BBHN or HSMM. The equipment he brought for the mesh was three WNDR3700v2 routers . On these devices, I had loaded the OpenWRT firmware. One device ran DHCP and an XMPP server, while the other two acted simply as relays. The network was configured so the 5 GHz radio connected ad-hoc while the 2.4 GHz radio provided an AP, different name and channel from each node.
Significantly different from BBHN, the adhoc 5 GHz connections were connected with the B.A.T.M.A.N. protocol (BBHN uses OLSR). The bat0 interface thus provided was bridged with the 2.4 GHz APs. This has the effect of making the entire network link-local. Thus, wireless clients could pull addresses from the node running DHCP.
At the exercise, David KG4GIY and Keith KM4AA connected their laptops and used Pidgin to connect their XMPP accounts, while Mark Redlinger connected with his iPhone and the ChatSecure app. No downtime was noted, though use was not heavy. The ability to connect Android and iPhone devices through the second AP is a big advantage to having a dual-band radio. The clear weather and flat terrain meant all of the APs were visible from the entire area of the exercise.
Derek welcomes any questions on this topic.
We learned there were a great number of power options available to everyone. Deep cycle batteries, generators, even solar panels, which meant there was no need for commercial power during the exercise. We also discovered that a physical device between the computer and the radio worked better than other lash-ups for sending and receiving data via fldigi. Several observers were present and learned how to use the system and what value it brings. It was also a good learning experience and we need to have more opportunities. A suggestion was made to have little workshops to review settings and set ups and then have another exercise. The digital list will be used to coordinate. The mesh nodes demonstrated the ability to utilize traditional TCP/IP based technologies successfully. More research and work needs to go into establishing the best way to implement it.
Bill did a signal study during the exercise, the results of which will be provided as soon as he has completed his analysis.
Thanks to everyone for their participation!
1 – http://wiki.openwrt.org/toh/netgear/wndr3700
2 – XMPP is an instant message protocol, perhaps likened to a computerized form of the National Traffic System
On Saturday, February 14, 2014, the Digital Working Group met along with some other interested parties to discuss the current state of the digital technologies, as well as try and find a road map for implementation within the PWCARES framework. After introductions, we went through some presentations.
Evolution from a discussion about “is there a role” for digital in ARES to clearly there is, especially the farther west in the US you go.
Rick has issues getting from his home in Haymarket getting to the repeaters (WWI/OHV) on voice
EOC is currently VHF/UHF oriented
Two parts of the story – the tools (FLx) and how the PA group is using them (NBEMS)
Rick went the route of the SignaLink, but there is software that can do the same thing with your built in sound cards (mostly inexpensive)
Similar to a fax machine over a telephone line – stuck pig sounds
Multiple ways to move the noise – usually mic and speaker, with the right cables to make the connection
Ran through the NBEMS presentation
Digital is accurate in the information being transmitted
FEC in a number of them protocols
Served agencies are moving along the digital message paths
NBEMS is an application of the FLx programs
Flamp – broadcast message to all
Open Source, multi-platform
Fldigi – encoder/decoder, with multiple codex
Sometimes you need to tweak the time calibration of your soundcard
MT-63 is robust, quick, FEC, used by MARS, resistant to noise
Good for increased distance performance
Olivia is preferred on HF. Sounds like a flute in the air. Stands out
Flmsg is pre-formatted, good fill in the blank ability
Text based, self-limiting to 3KB files, with a 3 minute limit for transmission
High-speed Mobile Mesh
Now called “Broadband hamnet”
Autoconfiguation fault tolerant ham radio coverage (part 15/part 97)
Because it is mess, it it multipath
Not limited by size of file
upto 150mb/sec depending on quality
Need to flash your router with a new image, configure, put on the air
Infrastructure based set up
There is the ability to get the hook up on to the Internet…there are issues with doing this
Until you boost power, you are covered by part 15. Once you boost, you fall into part 97
Under part 97, no encryption, no WPA, no SSL/HTTPS/Encrypted chat
Coverage up to 10 miles but realistically, much more reduced
Emcomm – videos, large images, web cams
A discussion of the nuts and bolts of Internet vs Mesh set ups – ssid/esid vs IP address
David reviewed the packet and WinLink
Packet is still a viable technology, but with a high learning curve.
Some masking is done by Outpost, a Windows-based piece of software.
Store and forward as well as direct connect. Also has the ability to hopscotch from node-to-node to improve connectivity.
Heavy infrastructure requirement, most packet nodes are no longer active.
WinLink is a long running, Windows-based message service.
Many have had success with it.
After the presentations, we made some decisions. To wit:
OS: Windows (for now)
Mode: Ad Hoc
Band: VHF/UHF (for now)
With that as the preconception, the FLx stack of programs makes the most sense to implement. So:
OpMode: MT-63 2KL (2000L)
Freq: 146.475 (ARES VHF 2)
The Concept of Operations
At this point, digital messages are being utilized in experimental mode. While it is desirable to have a digital node at each location, until we are completely comfortable with operation, it may not yet be possible.
Further, these are the identified (but not exclusive) types of messages that could be passed by digital methods.
Bulletins. These are messages that are sent out from NCS regarding the state of the operation, active locations, operational period data, weather updates, etc. that are necessary for all stations but could utilized excessive bandwidth on voice.
POD Supply lists. These are lists that may include equipment and supplies needed at a Point of Distribution, either basics or medicinals.
Low priority messages. These are messages that would take up unnecessary bandwidth on voice but still need to be passed.
While these are not all the types of messages that can, or could be sent by digital, it is a good start.
While we are working through the process and procedures, there are some additional issues we need to keep in the back of our minds.
Printers? What is the need for being able to print out these digital messages? Do we need to arrange for access to printers? What sort?
Directed Net? Does digital operations require a directed net? How would that operate?
Time segments? Would it make more sense to have a time slice management plan instead of a directed net. For example, in any 15 minute segment, the first x period is reserved for priority or emergency traffic, the rest of the period is a free for all?
Can fldigi be set to auto select operational mode? If so how so?
Finally, there was a decision to try and set up smaller hands on working groups to configure and test configurations before we take it to the field. There also needs to be a separate effort to create a quick reference guide. This can be managed via the digital list or this site. If someone would like to volunteer to host a working group, please identify yourself and we will get it on the calendar.
Here is a link to the presentations and other information from the working group.
Low cost of entry. This means that whatever solution we choose, it should not cost the average operator a lot of money to participate. This means that the code needs to be open source or low cost, the hardware footprint needs to be light and it should work with the majority of radios out there.
Easy configuration. The selected software should be easy to configure and it should be easy to bring up a node without needing to be a networking professional. It would be nice if we can do the following a) have a running “full time” network and b) be able to link into that network quickly in an emergency, like the old packet system as an example.
Easy to use. At the end of the day, it has to be easy to use by anyone for sending the common message forms (ICS-213 minimum) and possibly be able to pass the message from a terminal at the “site” to the “systems” being used by the EOC (the biggest example would be a 213 cut and pasted into WebEOC).
You will note that I don’t care a lot about HF or VHF or UHF. That being said, I expect that local transmissions will likely be done by the lowest common license class – Technician, which makes HF pretty much a non-starter for emergency communications within the county. Under my desire to have a functioning full time network, HF uplinks to digital nets (like VEN/D or WinLink) would be expected, but are not a requirement at this point. Let me also say that the general rule of thumb that HF would be done by those more permanent stations is still the working model.
There are advantages to store and forward. It has been proven over the last forty years as being a stable method for passing messages. There are advantages to the fldigi model of send it once. And there are disadvantages.
If I was building it (in a vacuum) I would use a bit of both. I currently have a packet node up and running. I connect to it with a simple console connection. I would love to be able to connect to it with a terminal session from my smart phone, but so far I haven’t found a cable that will let me. I used to be able to do it with my Palm though :). I have played with fldigi/flmsg and Outpost with limited success (yes, I know they are for different purposes). I have never had a lot of success with WinLink, or D-Rats.
At the end of the day, we need to arrive at the following:
Frequencies we want to use. These are, ideally, 2m/440. We may also want to consider supporting 6m/220/1.2 and D-Star.
Protocol. What protocol will work best to ship the message and will all the software support it?
Message types. What types of messages should we expect to be sending via this model?
I think, once we define these things, the rest should at least become more clear in direction.
At one point we tested 1.2 DD with D-Star (just for grins and giggles). We actually tested the connection between a remote station and WebEOC and it worked nicely, if slowly.
Brian, myself, and others, were trained in using packet and have gear that still works with the technology. I think we could better link with other protocols to better node types (I am thinking something like HSMM and Raspberry Pis for example, that would facilitate a number of good things in a radio digital network beyond just “email”)
I would rather see a number of nodes around the county rather than trying to link two nodes from one end to the other, for redundancy if nothing else.
To that end:
There will be a voluntary meeting of the cadre on Saturday, February 15, 2014 at the EOC at 0900 for us to sit down and walk through the issues and technologies associated with using digital systems in the ARES network. This will be as much a discussion/open forum as it will be a class on the technologies.
The agenda is as follows. I need a few more presenters please (and I have probably lost a couple of emails with volunteers, so remind me if you had already put your hand up
Presentation (Talk about the tech, bring in toys, bring up sample network?)
Fldigi/msg (Rick, KJ4ZIH)
HSMM (Derek, KV4SH)
SignaLink (Rick, KJ4ZIH)
NBEMS (Rick, KJ4ZIH)
Build a concept of operations: What do we want to do with it?
Build a network, without protocol, identify locations for nodes, both desired and possible.