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.
TLDR;
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/.
More Details
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 WWA/king.yaml.
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.
73.