I suggest two additions to the current Ham Radio portfolio:

[1] An open-source gateway to connect Part 15 devices to existing Ham Radio Networks. This would allow low data rate IoT networks and text-based messaging to pass from their local networks through ham radio to other local networks or a central server.

[2] A local server running a web server and database which would log all local traffic, synchronize relevant information to other servers and allow local traffic to exchange information with the web server.

This would give Ham Operators the opportunity to serve their local communities by providing network service and in turn allow local community members with an interest in the IoT/STEM experiments a way of stretching their skills. Rather like the old days of running a phone patch, this would generate a new image for Ham Radio, get our spectrum used by the general public and provide a reason for the current Ham Radio networks to remain and even grow.

Potential Advantages

I suspect I am not alone in having deployed systems such as AREDN or Winlink but ended up abandoning them because I couldn’t find anything interesting to use them for. If Ham Radio can get positioned as the intermediate carrier for the upcoming and growing experimenters of the IoT and included in STEM like projects, we have the potential to generate a lot of traffic. This would position Ham Radio as a growing relevant hobby, perhaps ensuring it has a next generation and that many of the currently underused frequencies remain ours to use by becoming active again.

Anybody reading my Ham Radio bio will see that as a rather lost and shy 14yr old my imagination was kick started by single UK Radio Amateur. I hear similar stories from my generation but am not so sure that the trend is continuing. The world has changed, what was exciting in my day is history today. But there are new challenges occupying the youth of today and new engineering hobbies thriving. Linking some of the new hobbies and trends through Ham Radio seems like an opportunity to bring new life and operating procedures to current Hams.

If critical mass can be achieved, there will be many opportunities for contests and awards for both the Ham operators and connected community. Potentially there is a new infrastructure waiting to be packaged as kits, commercial products, and new developments.

As a group, Hams have a well developed structure of instructors, examiners and clubs. Many of these have the bandwidth and opportunity to open their doors to the potential uses of the new Emergency Ham Network Services.

Likely Problems

Likely this idea will never get beyond a few readers of this website. But if the message resonates with a few perhaps they will help mold it into something that will develop. Or, it might just be a bad idea.

There will be cries that it is not legal, encryption constraints, fear of adults working with children, questions about who pays for the service and who will develop the software.

The availability of the Internet and its ease of use is a major concern, yes everything I propose and more can be done today through the Internet—when it is working.

To all of the above and many things I have not listed I say: Where is the fun in letting it all slip away, the fun is in the challenge and doing something that has not been done before.

Next Steps

I have set myself the modest target of 100 members by this time next year, if that happens this becomes my prime focus, if it does not then I can legitimately move on knowing I tried. Right now, we have about ten members. I am an optimist; I think we can get there.

So, please help spread the word, become a member or just comment on what you think, perhaps your contribution might be that needed spark.

I purposely wanted to avoid trying to design the system because this should be a collective task for a group of interested people each with their own skills and perspective. However, it seems that some form of design is needed to better communicate what this is all about. So, here goes:

Formally a Digital Network is defined as a network incorporating both digital switching and digital transmission. It is easy to get bogged down in the various definitions which change depending on the use case. In the more common seven-layer OSI model of computer networking, the network layer is layer 3. This network layer is responsible for packet forwarding including routing through intermediate routers.

In my case I use the term loosely to represent the transmission of data using digits across many different link layers in such a way multiple services can use it to communicate. ARDEN acts like a network layer with the capability to support IP, a protocol. Services like APRS use other protocols, I believe APRS uses x.25 which is perfectly capable of being transported over a digital network. Many of the HF systems use a modem to provide the network like communications, allowing the services like WinLink to communicate.

So, when I say a digital network across America operating 24/7 I am suggesting the interconnection of thousands of locations using a variety of links but with sufficient abstraction to allow routing to each location of a variety of services. In urban areas, like where I live, UHF links supporting IP would be fine, but in rural areas some form of HF link would be used and that may not support IP. Add to this mix, satellite links, LoRa spread spectrum and you begin to see that such a network rapidly becomes complicated so requires coordination and standards. I do not believe this is available today although I do believe there are some strong candidates that could be expanded. Most likely the network will have multiple parts connected together with gateways.  

My expectation is that such a network will allow many of the services we use today, I am slowly covering some of them in my blogs. Such a network could be used for sending data to places not currently well served and to be able to do this 24/7 without operator intervention.

If we get this right, we will specify various components that can be connected together to suit a specific location. These would, as seamlessly as practicable, expand and bridge the network for that location.

The specific hardware could be a small server running on a PI4, an antenna mounted UHF TX/RX on the roof, perhaps more than one TX/RX including a HF link. For those better located, a dedicated link to ARDEN. For those unable to do anything outside, perhaps a LoRa link.

Running 24/7 and presumably most having a MESH style of connectivity, these nodes would receive, store and forward packets. Although most of the packets might have no value to any given location, each location will play its part in providing the network. Collectively the network would be capable of sending and receiving messages to anywhere there was a active node. A given operator would have the satisfaction of knowing their node was part of a bigger picture, be able to see how it was performing and be able to connect to their server for any services they require.

Now, bandwidth is an issue. In my lifetime I do not think we will see speech being supported. I suspect we would be averaging Kb/s for most nodes. But this is enough since it operates 24/7.  

Many people like to see a diagram. Since this project is at such an early stage, not even a proof of concept – more a cry for existence, there is no design to draw.  

But it is reasonable to expect some generic diagrams that help explain the functionality. Here I detail two components, a basic end node and a bridge node. These would likely be the most popular components and illustrate much of the basic operation. Unfortunately, the more complex and interesting components: the switching, location, registration and database design are not so easy to represent as generic diagrams, these will have to wait for hard requirements to be created first.

Basic End Node

The end node would only connect to the EHN, it would only connect to the network through one connection. The network would see this as a single address representing its location/owner. It would likely connect through a simplex radio link as a slave to a master station, most likely a time division multiplexed single frequency. A good example on UHF would be the NPR-H Packet Radio system. This allows a master to support several end points, deals with the timeslot management and allows new stations to join on the fly. Overall, a good fit for this application. 

The Basic End Node could be a portable system, separate or in a car so that it could serve a remote area or special need. A scouting weekend or similar might be an appropriate use.

Data from the network would be passed to the server, most likely a Raspberry pi 4 or similar. This would allow interfaces to the required service applications. Perhaps supporting APRS, Winlink or DAPNET but also a general interface for the Internet of Things (IoT).  There may well be a low data rate EHN webserver providing registration and status support for the network, I believe passwords are not considered encryption so such an admin style would be practicable.

Optional, but shown on the diagram, is the firewalled link to items using Part 15 communications. WiFi and LoRa are the items illustrated, but other systems like GoTenna could also be supported. The firewall would be responsible for removing any encryption from messages into the EHN and adding it for use under Part 15. Such a system would allow messages to be sent over the EHN perhaps by using APRS, Winlink or DAPNET.  When used at the edge of National parks or wilderness areas, this link between Part 15 devices particularly MESH networks is attractive and offers real value. The Basic End Node could include a web server for the WiFi and this could relay messages and important information to the Part 15 users.

Basic Bridge Node

For locations capable of linking to a more capable node a bridge node is proposed. This has the added capability of lining to several end points and bridge their traffic into the EHN.

The link to the EHN could be another UHF simplex link, useful when there is a need to link two small islands perhaps to get around terrain issues but will be more effective if a duplex higher data rate link can be used. Equally in rural areas with small populations the link could be a HF link.

There is more processing and admin associated with a bridge. Most likely a database will be needed to store logs and to register the end point users, how the registration and geographical switching will be achieved is still up for discussion, but a store for local users seems like a good bet and would be capable of routing at the local level.

After these two nodes it should be easier to imagine combinations and additional links to form bigger nodes. There should be the possibility of links into ARDEN and Satellite uplinks.