One of the minor projects that I have been working on for a while now is to produce a Winlink form template for the weekly Winlink net. I have the first version of the forms completed and they are ready for download. You can find a description of what Winlink forms are and the download link here.
Information related to Ham radio nets
SnoVARC Mini-Exercise, Part 2
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
negative terms vs. the
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
negative terms are better.
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,
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.
SnoVARC Mini Exercise
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
- 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.
Something I have been working on for quite a while now is a easy to manage list of Ham radio nets. Now I am ready to reveal to the world the work that I have been doing and allow people to start to consume it.
The nets are organized as a set of YAML files that describe each net. You can find the YAML files here: https://gitlab.com/wt0f/ham-radio-calendars. Each time a change is made to the files a new set of iCalendar files are generated. The iCalendar files can be subscribed to at https://nexus.wt0f.com/service/rest/repository/browse/calendars/.
I started thinking about the fact that there was not really a good catalog of nets or a way to stay up to date with the changes of nets. I liked what WA7BNM has done for contesting with making schedules available as a calendar file. That made sense to me given that one could have a list of nets but it gets hard trying to visualize when the nets occur or where there may be conflicting schedules. Hence I started building a catalog of nets.
Certainly this catalog is not complete. Even for the Seattle area, this is really just a subset of nets that occur. I have tried to include all the ones that I could find out about but I am sure that there are many more that occur that are not listed anywhere.
I have tried to organize the nets in a reasonable way that can be extended to support other areas and most situations. Although I expect that the structure of the files will change over time as others contribute to the effort.
Oh, yes, did I not mention that this is a cooperative effort? This is not just the nets that I want to track or publish–this allows anyone to contribute to the catalog of nets. This could be adding a new net (or one that is currently not listed) or updating information about a net that is not correct. This is accomplished by one of two methods. More on that in a bit.
Structuring the nets
I am not going to really talk about the YAML format for describing the nets here. You can find more information (which should stay pretty much up to date) at the GitLab repository that has all the files. Look at the README.md file for a pretty good description of the format. For those that are not familiar with the YAML format, it is a format that is easy for computers to process and equally easy for humans to digest. For an introduction to YAML look at https://www.redhat.com/sysadmin/yaml-beginners.
The net catalog is being organized into files that are broken down by counties and in some cases cities (for large cities–think Los Angeles, Dallas, Boston, etc.). These files are stored in a directory named after the ARRL section. So for example, the nets that occur in the city that I live in (Issaquah, WA) would be stored in
I think this provides a pretty reasonable compromise between the geographical location of the net and the grouping of the nets. In other words, there is not a huge file listing hundreds of nets which becomes cumbersome to manage and keep up to date. Conversely there is not a thousand little files that need to be kept up to date. In either of these extreme cases, it is not terribly difficult to duplicate information because the number of things to look at is just too large.
This scheme will cover North America pretty well. But what about other areas of the world? Well, I am not opposed to moving things around to extend where in the world the schedules represent. So without hardly any trouble at all, it would be pretty easy to add say a directory level for the continent and maybe a second directory level for the country. It is just not needed at this time, but it is easy to grow file structure to accommodate more schedules.
Now you may be asking what to do with nets that cover more than just a geographical region? These nets tend to be organizationally driven or using communications technologies that link over the internet (like DMR, Allstar or D-STAR). Right now I have been starting to organize these schedules in separate files and I figure that many of them will be in a directory at the top level called
organizations. The idea here is that there would be a file for Allstar nets, American Redcross (national nets), NAQCC to name a few.
Again, this is subject to change in the future as the needs to organize the schedules becomes more complicated. But others will also have a say in how everything gets organized also.
Now It Is Your Turn
So how can you contribute? As I stated above there are two ways that anyone can contribute schedules or updates to existing schedules.
The first is to fork the repository (https://gitlab.com/wt0f/ham-radio-calendars) into your own GitLab account. If you don’t have a GitLab account, you can get one for free at https://gitlab.com/users/sign_up.
Once you have logged into your account you want to navigate to the repository. Then it is as simple as clicking the “Fork” button in the upper right corner of the repository page. Below is the top of the repository so you can see the Fork button.
This will create a copy of the repository in your GitLab account. With those familiar with Git, you are probably all set and don’t need anything else. If you have never touched Git or not even sure what it is, you can use the Web IDE that GitLab provides. In your copy of the repository you can click on the Web IDE button and this will allow you to make changes to the files.
Now that you have changes to the schedules, you want to commit the changes back to your local copy of the repository and create a merge request back to the original repository. The merge request then gets looked at and is either approved or provides a way to have a discussion about the changes so that all can agree that the changes should be made. Once approved that changes get applied to the original repository and a few minutes later the iCalendar files get updated.
The alternative way to get changes made and this is primarily for those that don’t quite understand how that darn YAML thing works. Visit the original repository and create an issue where the changes can be described. This will generally take longer as I need to collect the issues and then go make the appropriate changes in the repository.
I hope that many Hams out there will find this a valuable resource to keep track of nets and discover new ones. If you have any questions or comments, please feel free to hit me up.
Weekly Winlink Net
I have been thinking for several weeks of starting a Winlink net to get more involvement in the local ARES/RACES group. Starting for the new year I sent the following to the group. The response has been good and with any luck it will be a success.
I am wondering if doing the net every week will become tiresome, but I figure it will be good to get started and it can be dialed back if the participation starts to fall off. It may also transform into a monthly net and the remaining weeks will be other methods of communicating. It has been a long, long time since we held a voice net, so maybe it will change to a schedule of Winlink one week, a voice net another week and other weeks have other types of nets.
Here is a copy of the email that I sent to the group to announce the net. If you are not in the City of Issaquah, you are still welcome to participate. We just like playing with others, so everyone is always welcome.
Happy New Year to everyone!
Something I was thinking about during the month of December is to start a Winlink net. This will start as using only Winlink, but there maybe occasions where other protocols/technologies are used to keep a variety and keep things interesting. Even with introducing other protocols this will remain primarily a Winlink net.
So how does a Winlink net work? I am going to model the net after the original Winlink Wednesday net that was started in Virginia. So on Wednesday between the hours of 0800 and 2000 (PST) you would send a Winlink message to check in to the net. We will start with a basic check in and later on add a bit more variety by posting a question for the answer to be submitted with the check in.
So the basic Winlink check in is simple. Compose a message to K7ISQ and on the first line of the message include the following:
callsign, first name, city, county, state, connection type
So for me I could checkin with something like:
WT0F, Gerard, Issaquah, King, WA, VHF
If you are traveling that week, then you would check in with the current city, county, state that you are currently in. Or lets say that you are at work when you send the Winlink message, use the city that you are in when you send the message. The last item (the connection type) is generally optional for many nets, but I think it would be a nice thing to add. Generally the options for the connection type are HF, VHF, telnet. I think as we go forward this list will get extended to include if the connection is over 9600 baud or a P2P connection or even a VARA-FM, ARDOP or other unique connection is being made. But for now lets keep it simple.
While I am thinking about it, check ins are welcome to come from any source. So you can use any of the Winlink RMS nodes–so don’t feel that you have to use my nodes for the check in–or a Pactor station if you want to practice sending over HF. Quite honestly if all you have available is a telnet connection over the internet, then that is sufficient. The purpose is to exercise the use of Winlink and getting used to using it periodically so that everyone is familiar with it and it is ready to go at a moments notice. My suggestion is that people should be using various RMS nodes so that they have a good understanding of what nodes they are able to normally hit and know what alternative RMS nodes can be used when the one that is normally used is out of commission. Maybe that will be a bit of a contest one week–who is able to hit the furthest node from their station. Get those Yagis tuned up
I plan on producing a Winlink form template for the net and the variations to the net that will develop. So stay tuned for where you can get that and use it to construct the check in message.
So you send a message to check into the net, what happens afterwards? At about 2000 PST or some time afterward, I will collect all the messages sent to K7ISQ and respond to all the check ins to acknowledge that the check in was received. Sometime around the beginning of the week I am planning on sending Winlink messages to all the stations that checked in the prior week (and probably for some amount of weeks after the last check in) with any information that would be useful for that week’s net. This might be simply a reminder of the type of net that will be functioning that week or a question to be answered in the check in for the week. It is my hope that this will provide a moderate amount of Winlink messages back and forth to insure that everyone’s Winlink setup gets exercised enough to find any issues with stations on a regular basis and not just during drill time.
As the net develops, there will be other things that are brought in such as a week that the ICS 213 form is used or using P2P connections for the net. I have also started to build a list of questions to use for some nets to add something more than just a simple check in. I would also like to get the net to the point where there is a couple of people that act as net control and that it can be moved around.
Finally, while I am sending this notice out to the ICST members, it is by no means that the net is restricted to just ICST members. Anyone is welcome to participate in the net no matter where they are located. So, if you have friends that may have an interest and want to work with Winlink, feel free to forward this email and invite them to participate.