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.