Category: Nets

This is the second part of a post about the SnoVARC mini-exercise held on 24-FEB-2021. This time I will attempt to stay on the original topic that started the post.

In the previous post I went into a bunch of things that are generally good practices during EMCOMM nets. A bunch of good information and things that most operators don’t think about while sitting on a net or prepare for. So If you have not read the post yet, I encourage you to spend a minute or two and absorb it.

A quick review of the drill–explained much more completely in the previous post–the area has received an uncharacteristic large amount of snow and a net has been established to gather information and status from team members. There are seven items of interest (again refer back to the previous post for what they were) that each station needs to report and we want to do this in an efficient manner.

So lets think for a moment about how to organize and record information while the net is occurring. One needs a way to organize and quickly record information from the net reports.

To the right is a copy of the page I put together during the mini-exercise. It is slightly disorganized because it was being constructed as the mini-exercise was being laid out for us.

It is organized with the stations that check into the net followed by a quick summary of the scenario as portrayed by net control. Following that is an index of the 7 items that each station will report with. Finally a matrix of all the reports with a column for each of the 7 items. Organizing information in this way allows the reports to be collected much easier than writing out the reports in long hand.

The mini-exercise went well and afterward there is a bit of a hot-wash to discuss the experiences and learn from one another. It was a very good discussion and many good points were made by all involved. There was one topic that came up that was a little bit controversial for the group and it dealt with how to efficiently send the traffic to net control.

So let me start with how net control communicated how transfer the traffic. I also want to be very clear here that the following should not be construed that net control is/was wrong. Net control has to run the net the way that they are comfortable with and maintain control of the net. I am providing this contrast of sending traffic to allow net control stations and the greater EMCOMM community to think about what and where efficiencies can be made in moving traffic (BTW the National Traffic System has solved some of these problems decades ago and streamlined moving messages). There is one case where how net control requested and moved the traffic does make sense and that will be discussed toward the end of the post.

So here is now a typical message was sent during the mini-exercise:

NCS: WTØF, do you have commercial power?
WTØF: Affirm
NCS: Natural gas or propane?
WTØF: Negative
NCS: Running water?
WTØF: Affirm
NCS: Working internet?
WTØF: Affirm
NCS: Phone service?
WTØF: November alpha     (not-applicable)
NCS: Zip code
WTØF: 98027

A few notes about the above exchange. First there is a lot of back and forth going on. The mini-exercise was done over a repeater so there is a bit of turn around time between transmissions. On one of the exchanges net control and the reporting station where keying up so close to each others transmission that the courtesty tone was making the responses almost unintelligible. At best I was getting half of the response and trying to determine if it was a yes or a no.

Now consider if you have a station reporting in over an Allstar or Echolink connection. That turn around time on the repeater just got a lot longer. It is not impossible to transfer the traffic mind you, but both operators have to be a lot more disciplined to keep the flow going.

During the hot-wash, net control told of working a bike rally where this sort of protocol was used for moving traffic and it was a very fast transmission. One significant difference there being that the net for the bike rally was simplex rather than being on a repeater. So, yes, I can see some advantage when on a simplex frequency.

Another thing I want to point out is the terminology I used. Some of the participants stated in the hot-wash they did not like the affirm / negative terms vs. the yes / no that everyone else was using. Were they wrong? No, it is purely a preference or an opinion. But I would like you to consider a couple things as to why sometimes the affirm / negative terms are better. Yes / no are very short words and any noise or dropouts on the repeater can kill the response which means that there is more back and forth trying to get the correct response. Also, affirm / negative are very distinct words that are hard to mix up even with some noise or interference (in my opinion very necessary on EMCOMM HF communications). I should also note that affirm should not be pronounced as ‘ah-firm’ but ‘ay-firm’. The high A at the beginning makes it much more distinct even if the second half of the word gets wiped out.

So what am I suggesting for transferring the traffic? Consider the following exchange:

NCS: WTØF, please send your report
WTØF: Power affirm, natural gas negative, water affirm, internet affirm, phone november-alpha, zip code 98027

Much more succinct and faster to transmit. Lets just say for the sake of argument that net control was not able copy (for whatever reason) the responses for water and phone service. How would the exchange look then?

NCS: WTØF, please send your report
WTØF: Power affirm, natural gas negative, water ______, internet affirm, phone _________, zip code 98027
NCS: WTØF, please repeat water and phone
WTØF: Water affirm, phone november-alpha

This also works if the reporting station does not come back with all the items in their initial report. Does this work for all situations? No, there are times when this would not work well.

But first, I want to tell you where this exchange came from. It was back in May 2020 when the Washington State EMD sent out some training for the ISNAP form (page 5). The ISNAP form has 39 boxes. The training for the form demonstrates the exchange with the back and forth just like the mini-exercise. That is a whole lot more back and forth. If you look at the form the top half is collecting information about the incident (that is 9 boxes). The bottom half of the form is a collection of 10 topics being collected that can be transmitted with less back and forth as shown above.

So I hope you can start to see that much of the time many exchanges can be much more efficiently transmitted and that will result in less operator fatigue and more throughput of messages. Especially in high stress situations.

Note: I was just referencing this post and re-reading a portion of it to send to a fellow ham and I had to make a comment or two on the paragraph above. When I wrote this post, I should have added these comments. I was a little glib with the last sentence and it has to be noted that in a high stress environment things will naturally go sideways and out of control. The way to combat increasing the chaos is to train a lot and get the operators to consistently do the same thing. This is part of what I was discussing in the first post of this series. Even with operators that are very knowledgeable with working within a net, a high stress situation will/can still cause things to go sideways, but it will be less likely and usually a much smaller disruption. 

OK, so when does this not work well? There are primarily two cases. One is when the reports are coming in staggered or when the reporting stations have joined the net at different times and may not be on the same page with what items need to be reported on. This adds an additional dimension where net control may need to periodically announce the items to be reported on. If after reading the previous post about preparing for events in you area and you have done the work to prepare standardized status reports, then this should limit the amount of work that net control needs to do to inform stations what items to report on. This also means that your team needs to practice the reporting regularly so that know what needs to be done when an incident occurs.

The second case is when you have inexperience operators or operators that are not familiar with the status reporting that your team has in place. In this case net control pretty much has to lead the station through the reporting process like how it was done in the mini-exercise. One thing for your net control station to be vigilant about, especially with inexperienced operators, is that as they report each item there is a tendency for the operator to start giving more information or to start telling a story. Net control needs to be prepared to cut the operator off and instruct them to respond with the applicable responses.

Alright, there is a lot here to process. There was certain a few more things that came out of the mini-exercise hot-wash. This posting is already long enough I am not going to go into other items now. Many of these items keep coming up in a variety of exercises, so there is plenty of opportunity to discuss them in the future.

73.

This past Thursday evening the Snoqualmie Valley ARC (SnoVARC) held another one of their mini exercises. The mini exercises are held once a month on the third Thursday of the month and attempt to provide teaching opportunities for emergency communications.

With the snow that hit Seattle this past weekend–yours truly received 8.6″ of snow which is not as much as I used to receive in Maine, but if you have seen my driveway then you know this was not a trivial amount–the premise of the drill was to quickly and efficiently report ones current status to the net. In addition, WA7TBP wanted to add to the pressure by “throwing people under the bus” where everyone would need to track all the information and be ready to assume net control.

I especially like this last point as it is similar to things I have done on EMCOMM training nets. It is a wonderful thing mid-sentence during the middle of the net to just stop transmitting and see what happens. It clearly shows who is on the ball and who your best communicators are. But those are stories for another time.

So WA7TBP took a quick roll call to see who was participating and then gave a list of questions that each station needed to report in with. The information to report with was

• Callsign
• Do you have commercial power?
• Do you have natural gas/propane?
• Do you have commercial water?
• Do you have internet?
• Do you have phone service (twisted pair)?
• Zip code you are reporting from

Pretty straight forward and easy to report. There was about 5 of use participating in the exercise and everyone performed flawlessly. GREAT! We are all ready for Armageddon to arrive and can perfectly move traffic without introducing any errors! OK, I hope everyone can recognize that is pipe dream and things are never so simple in a real world scenario.

There are a couple of things I want to highlight from this mini exercise that I think can help a lot of other communicators.

First thing is to start planning now. No, I mean NOW. Stop reading this, grab some paper and start planning the mostly likely events that you may have in your area. OK, continue reading but put it on your calendar to have some drafts of a plan in the next couple of days.

Much of this planning comes in the form of what sort of events can be anticipated and what information is vital during the event that needs to be gathered or disseminated. Here in the Pacific Northwest we focus on floods, wind storms, earthquakes, and volcanoes. Although I hate to say it civil unrest is inching up the list (I am 15 miles or so from Seattle). Other areas need to focus on tornadoes, hurricanes, ice storms, heat waves and several more that I can not think of right now. So get your top 5 events, start putting a standard set of questions together for the status report and get that distributed to other members of your group. Having members of your group ready to go in an event is half the battle. Of course your group needs to practice the reporting structure periodically to keep everyone in a ready posture.

Another thing to think about is how to organize the information collected. You want something simple and quick to update. I am including a photo of the notes/log that I took during the exercise to give you some ideas how this can be done. You don’t want to have to be writing things out in long hand or digging around looking for that one form. You want something that can be constructed on the fly and readily marked up.

If this was a real event I would probably be working off of about 3 separate pages. One would be a log of who has checked in/out, times and other important traffic. Another page would be the consolidated page of reports. The final page would be a collection of notes concerning outstanding or significant reports (e.g. down trees, closed roads, injuries, collapsed buildings, etc.)

Another thing you want to establish is to have everyone tracking the same information. I say everyone but the reality is that there will probably be some people in the field that won’t have the capabilities to record and track the information. For those stations (usually fixed) that are on the net and are capable of logging the traffic, they need to do so. At any moment the net control station may go dark and another station may need to assume control. If the fixed station are not also tracking the information then it becomes a cluster you know what trying to regain control of the net and needing to gather all the information again. And by the way half the stations have gone away to handle other tasks and you can not gather their information.

Your group may want to collectively decide to have a hierarchy of stations that assume net control functions. Or the group may decide to leave it to the situation and who has the abilities to function as net control. Personally I like to ad hoc aspect the stations in the net electing/commandeering net control as it adds self-organization and self-repair aspects to the net. Neither way is right or wrong, but the group needs to practice it and feel free to experiment with them to find what works and what does not work. A lot of it depends upon the operators and their capabilities.

Well, I have gotten off the topic I really wanted to hit and this post is getting a bit long, so I will continue the original topic in another post.

73.