Category Archives: Digital

NBEMS? Why don’t we just call it what it is?

While getting ready for this weekend’s discussion, I stumbled over a new acronym, NBEMS. It really is not new, but for those that have not encountered it, here is what it means:

Narrow Band Emergency Messaging Software (NBEMS) is an Open Source software suite that allows amateur radio operators to reliably send and receive data using nearly any computer (Windows, Mac, and Linux) and any analog radio without requiring a dedicated digital infrastructure or specialized modem hardware. (ARRL)

“Oh, interesting,” thought I until I dug into it more. NBEMS is simply the passing of ICS documents via FLDigi. The ARRL (and others) have created an acronym for … a mode of passing traffic…

I would encourage you to visit the NBEMS page though for only one reason – there are two lovely presentations about how to set up FLDigi for this use! And if, like me, you have been frustrated by how hard it seems to be to get bi-directional traffic flowing as well as a starting point for a “standard,” then take a look at these two presentations.

The Goals for a Good Digital Solution

Here are my goals:

  1. Low cost of entry.  This means that whatever solution we choose, it should not cost the average operator a lot of money to participate. This means that the code needs to be open source or low cost, the hardware footprint needs to be light and it should work with the majority of radios out there.
  2. Easy configuration. The selected software should be easy to configure and it should be easy to bring up a node without needing to be a networking professional.  It would be nice if we can do the following a) have a running “full time” network and b) be able to link into that network quickly in an emergency, like the old packet system as an example.
  3. Easy to use. At the end of the day, it has to be easy to use by anyone for sending the common message forms (ICS-213 minimum) and possibly be able to pass the message from a terminal at the “site” to the “systems” being used by the EOC (the biggest example would be a 213 cut and pasted into WebEOC).

You will note that I don’t care a lot about HF or VHF or UHF.  That being said, I expect that local transmissions will likely be done by the lowest common license class – Technician, which makes HF pretty much a non-starter for emergency communications within the county.  Under my desire to have a functioning full time network, HF uplinks to digital nets (like VEN/D or WinLink) would be expected, but are not a requirement at this point. Let me also say that the general rule of thumb that HF would be done by those more permanent stations is still the working model.

There are advantages to store and forward.  It has been proven over the last forty years as being a stable method for passing messages. There are advantages to the fldigi model of send it once.  And there are disadvantages.

If I was building it (in a vacuum) I would use a bit of both.  I currently have a packet node up and running. I connect to it with a simple console connection.  I would love to be able to connect to it with a terminal session from my smart phone, but so far I haven’t found a cable that will let me. I used to be able to do it with my Palm though :).  I have played with fldigi/flmsg and Outpost with limited success (yes, I know they are for different purposes).  I have never had a lot of success with WinLink, or D-Rats.

At the end of the day, we need to arrive at the following:

  1. Frequencies we want to use.  These are, ideally, 2m/440. We may also want to consider supporting 6m/220/1.2 and D-Star.
  2. Protocol. What protocol will work best to ship the message and will all the software support it?
  3. Message types. What types of messages should we expect to be sending via this model?

I think, once we define these things, the rest should at least become more clear in direction.

Additional Background

At one point we tested 1.2 DD with D-Star (just for grins and giggles).  We actually tested the connection between a remote station and WebEOC and it worked nicely, if slowly.

Brian, myself, and others, were trained in using packet and have gear that still works with the technology. I think we could better link with other protocols to better node types (I am thinking something like HSMM and Raspberry Pis for example, that would facilitate a number of good things in a radio digital network beyond just “email”)

I would rather see a number of nodes around the county rather than trying to link two nodes from one end to the other, for redundancy if nothing else.

To that end:

There will be a voluntary meeting of the cadre on Saturday, February 15, 2014 at the EOC at 0900 for us to sit down and walk through the issues and technologies associated with using digital systems in the ARES network. This will be as much a discussion/open forum as it will be a class on the technologies.

The agenda is as follows. I need a few more presenters please (and I have probably lost a couple of emails with volunteers, so remind me if you had already put your hand up

  1. Presentation (Talk about the tech, bring in toys, bring up sample network?)
    1. WinLink
    2. Fldigi/msg (Rick, KJ4ZIH)
    3. Packet
    4. HSMM (Derek, KV4SH)
    5. SignaLink (Rick, KJ4ZIH)
    6. NBEMS (Rick, KJ4ZIH)
  2. Build a concept of operations: What do we want to do with it?
  3. Workshop
    1. Build a network, without protocol, identify locations for nodes, both desired and possible.
    2. Map concept of operations to network

Everyone is welcome. Feel free to bring gear!