All posts by David Lane

Upcoming Events – Volunteers needed

MCM 17.75 April 12

Route for the 2014 MCM 17.75
Route for the 2014 MCM 17.75

The Marine Corps Marathon office is going to be running their 17.75 run on April 12. The operation begins at 0600 and should be complete no later than 1400.  The race begins at 0800. This years route is a circle (yay). We need at least 16 operators, and more would be helpful because we know that when race day arrives, we tend to have a bit of attrition.

Final communications plan and volunteer paperwork will be sent out closer to the event. A mobile with an antenna is usually sufficient. As with all Marine Corps events, it is rain or shine, hot or cold.  If you can participate, please email David Lane, KG4GIY directly, then go out to the MCM site and register.

24 Hour Run 2014 May 2 – 4

Example 2011 setup for the half-way point
Example 2011 setup for the half-way point

Woodbridge ARC will be supporting the 24 hour run in Prince William Forest Park. They will be using 147.240 + as the repeater in the park with 147.525 as the simplex backup.  There will be operations on HF, VHF, and digital as well.

A minimum of two stations are needed to be manned during the entire event.  The weather can vary from very nice to very un-nice. Past history has warm days and cool nights to pouring down rain and snow.

The operation begins at 0630 on Saturday morning and concludes at 1000 Sunday. The actual race is from 0700 Saturday through 0700 Sunday and occurs in the dark of the night as well.  Nothing more exciting than watching runners in headlights at 2AM!

Please contact Rob Williams, KJ4LWN directly to volunteer.

Compiling fldigi on the Raspberry Pi

Why, one might ask, would one want to run fldigi on a raspberry pi? Perhaps you want to get familiar with Linux before sacrificing a larger system to it.  Maybe you feel like you need practice compiling software. And maybe, you are like me, and when asked I said, “Because I can?”

Whatever your reason, the raspberry pi is not the ideal platform to run fldigi on, but it is not a bad platform for demonstrations, and testing.  But getting from here to there is not straight forward.

Now, you don’t have to compile the code.  You can pull a version from the repos with:

sudo apt-get install fldigi

But the version you are grabbing may not be the most recent one, and there are occasionally some issues with backwards compatability.  I did try downloading the precompiled binary but at least for version 3.21.78, the binary did not run on the pi, even though it ran without issues on Ubuntu on my netbook.

Which leaves the tried and true method. Compile the code from scratch.  And I thank the developers for providing the source code that allows me to do this.

But, like most software, when you start down the path of compilation, you occasionally have to make a detour (or three) to get it working right. So I will help here by taking you down the road I went, but I don’t guarentee you will get there from here.  This is just what I did, and what I wrestled with getting there.

One thing I will point out is that this is a long process, partly because of the number of packages that need to be fetched and installed and partly because of the capabilities of the pi.  Can you do it all in one sitting? Yes. But you might want to plan to take a couple of breaks along the way.

Ready?  Here we go…

In the beginning

Before you begin, you need a running Pi. I am going to assume you have already installed the software, and performed the inital configuartion, but not much more. If it has been a bit since you lastupdated your Pi, you might want to do that first. By the way, I will assume throughout that you are connected to a live Internet connection and have already figured out how to log in. Most of the following commands are excuted at the command line.

  • Update the repository on your Pi:
sudo apt-get update
  • Actually upgrade the Pi:
sudo apt-get upgrade

It might take a couple of minutes for this to grind through all the packages it needs to get, and then update.

Although you do not have to reboot the pi, if you got a new kernel during your update, it will benefit you to reboot and make sure the new kernel is working properly before you dive into the next part.

To reboot, you can issue this command:

sudo init 6

You can also issue this:

sudo shutdown now -r

Now that the software is up to date, and the kernel is good, we can get serious!

Prerequisits

Before you can begin, you should grab all the files you will need. I find it easiest to put all my downloads into a single place, called source, so I can find them when I am looking for them later.

mkdir source

Depending on how you download your code, you can open a browser and download it (suggested because how often fldigi changes) or you can use wget.  Grab the files you want from the fldigi download site. You will also need some other files.

  • Install the X11 development libraries (we will do that in a minute)
  • Install the libpng development libraries
  • fltk. I used version 1.3.2 (http://www.fltk.org/software.php)
  • Python Setup Tools (incl Easy Install)
  • Secret Rabbit Code. I used version 0.1.8. You need this for the samplerate python code (http://www.mega-nerd.com/SRC/download.html)
  • scikits.samplerate. I used version 0.3.3. (https://pypi.python.org/pypi/scikits.samplerate)

Install the development libraries from the repositories:

sudo apt-get install libx11-dev libpng12-dev python-setuptools python-dev python-numpy python-scipy libblas-dev liblapack-dev

It will ask to install some additional dependancies. Say yes and let it go.

Compile the fltk toolkit

  1. Chage into the source directory.
    cd source
  2. Untar the source file (I will only document this once – I will assume you can follow along after this).
    tar zxvf fltk-1.3.2.tar.gz
  3. Change into the fltk directory.
     cd fltk-1.3.2
  4. Configure the source tree and makefile (note the dot before the slash – you have to do that or it will error out at you).
    ./configure
  5. Compile! (and grab a snack…took about 15 minutes).
    make
  6. Install the software.
    sudo make install
  7. With luck, there are no errors and the software is installed.  I did get a few errors about depricated code in the X11 libraries that the fltk program warned about, but did not error out at compile time. You can safely ignore those sorts of errors.
  8. You are done with this step.

Compile the samplerate toolkit

  1. Chage into the source directory, untar the file and move into the directory.
  2. Configure the source tree
    ./configure
  3. Take note of the compiling information
    Compiling some other packages against libsamplerate may require the addition of "/usr/local/lib/pkgconfig" to the PKG_CONFIG_PATH environment variable.
  4. Compile! (It takes a bit to compile this code, be patient)
    make
  5. Install
    sudo make install
  6. Update the package configuation path (PKG_CONFIG_PATH) – command is all on one line.
    export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
  7. Move into the scikits.samplerate directory
  8. Python programs are or can be a bit tricky.  When in doubt, alway review the README to make sure nothing has changed.  You may need to do this first:
    sudo easy_install -U distribute
  9. Move into the scikits.samplerate directory and run setup.py
  10. python setup.py
  11. You will get a menu like this:
    pi@jake:~/source/scikits.samplerate-0.3.3$ python setup.py
    ========================================================================
    Starting interactive session
    ------------------------------------------------------------------------
    
    Tasks:
      i       - Show python/platform/machine information
      ie      - Show environment information
      c       - Show C compilers information
      c - Set C compiler (current:None)
      f       - Show Fortran compilers information
      f - Set Fortran compiler (current:None)
      e       - Edit proposed sys.argv[1:].
    
    Task aliases:
      0         - Configure
      1         - Build
      2         - Install
      2 - Install with prefix.
      3         - Inplace build
      4         - Source distribution
      5         - Binary distribution
    
    Proposed sys.argv = ['setup.py']
    
    Choose a task (^D to quit, Enter to continue with setup):
  12. Choose 0 to configure, then press Enter. It will dump you at a “press Enter to close.” Go ahead and press enter.
  13. Start it again, select 1. Press Enter and it will start building (you might get a few warnings). Press enter to be returned to the command line.
  14. To install the packge, start it again, with sudo:
    sudo python setup.py
  15. Press enter to return to the command prompt. You are done with this step.

Comple fldigi

  1. Change directory to the source directory and untar fldigi, then move into the fldigi directory.
    cd ~/source
    tar zxvf fldigi-<version>.tgz
    cd fldigi-<version>
  2. Configure the software source tree and makefile.
    ./configure
  3. Compile! And grab a snack…it takes a bit and maxes out the CPU.
    make
  4. Install
    sudo make install
  5. And that is that. You can now fire it up by opening up and testing it. The most straigtforward way is to click on the bird-like icon on the far bottom left corner, which brings up a pick list. Slide up to “Internet” and Fldigi is on the list. Click on it and it will start. (Fldigi does not like running through vnc).
  6. Now on to the other software! (What you thought you were done?)

Next, we will compile and install flmsg.

 

 

Outbrief – 15 Feb 2015 Digital Workshop

On Saturday, February 14, 2014, the Digital Working Group met along with some other interested parties to discuss the current state of the digital technologies, as well as  try and find a road map for implementation within the PWCARES framework.  After introductions, we went through some presentations.

The Presentations
Rick, KJ4ZIH
  • Evolution from a discussion about “is there a role” for digital in ARES to  clearly there is, especially the farther west in the US you go.
  • Rick has issues getting from his home in Haymarket getting to the repeaters (WWI/OHV) on voice
  • EOC is currently VHF/UHF oriented
  • Two parts of the story – the tools (FLx) and how the PA group is using them (NBEMS)
  • Rick went the route of the SignaLink, but there is software that can do the same thing with your built in sound cards (mostly inexpensive)
  • Similar to a fax machine over a telephone line – stuck pig sounds
  • Multiple ways to move the noise – usually mic and speaker, with the right cables to make the connection

NBEMS

  • Ran through the NBEMS presentation
  • Digital is accurate in the information being transmitted
  • FEC in a number of them protocols
  • Served agencies are moving along the digital message paths
  • NBEMS is an application of the FLx programs
  • Flamp – broadcast message to all
  • Open Source, multi-platform
  • Fldigi – encoder/decoder, with multiple codex
  • Sometimes you need to tweak the time calibration of your soundcard
  • MT-63 is robust, quick, FEC, used by MARS, resistant to noise
  • Good for increased distance performance
  • Olivia is preferred on HF.  Sounds like a flute in the air. Stands out
  • Flmsg is pre-formatted, good fill in the blank ability
  • Text based, self-limiting to 3KB files, with a 3 minute limit for transmission
Derek, KV4SH
HSMM-MESH/Broadband
  • High-speed Mobile Mesh
  • Now called “Broadband hamnet”
  • Autoconfiguation fault tolerant ham radio coverage (part 15/part 97)
  • Because it is mess, it it multipath
  • High bandwidth
  • Transmits IP
  • Not limited by size of file
  • upto 150mb/sec depending on quality
  • Need to flash your router with a new image, configure, put on the air
  • Infrastructure based set up
  • There is the ability to get the hook up on to the Internet…there are issues with doing this
  • LinkSys, Ubuiquiti brand (www.ubnt.com)
  • Under 1 watt of power out of the repeater
  • Until you boost power, you are covered by part 15. Once you boost, you fall into part 97
  • Under part 97, no encryption, no WPA, no SSL/HTTPS/Encrypted chat
  • Coverage up to 10 miles but realistically, much more reduced
  • Emcomm – videos, large images, web cams
  • A discussion of the nuts and bolts of Internet vs Mesh set ups – ssid/esid vs IP address

David, KG4GIY

  • David reviewed the packet and WinLink
  • Packet is still a viable technology, but with a high learning curve.
  • Some masking is done by Outpost, a Windows-based piece of software.
  • Store and forward as well as direct connect. Also has the ability to hopscotch from node-to-node to improve connectivity.
  • Heavy infrastructure requirement, most packet nodes are no longer active.
  • WinLink is a long running, Windows-based message service.
  • Many have had success with it.

The Direction

After the presentations, we made some decisions. To wit:

OS: Windows (for now)

Mode: Ad Hoc

Band: VHF/UHF (for now)

With that as the preconception, the FLx stack of programs makes the most sense to implement. So:

OpMode: MT-63 2KL (2000L)

Freq: 146.475 (ARES VHF 2)

The Concept of Operations

At this point, digital messages are being utilized in experimental mode. While it is desirable to have a digital node at each location, until we are completely comfortable with operation, it may not yet be possible.

Further, these are the identified (but not exclusive) types of messages that could be passed by digital methods.

  1. Bulletins. These are messages that are sent out from NCS regarding the state of the operation, active locations, operational period data, weather updates, etc. that are necessary for all stations but could utilized excessive bandwidth on voice.
  2. POD Supply lists. These are lists that may include equipment and supplies needed at a Point of Distribution, either basics or medicinals.
  3. Low priority messages. These are messages that would take up unnecessary bandwidth on voice but still need to be passed.

While these are not all the types of messages that can, or could be sent by digital, it is a good start.

While we are working through the process and procedures, there are some additional issues we need to keep in the back of our minds.

  • Printers? What is the need for being able to print out these digital messages? Do we need to arrange for access to printers? What sort?
  • Directed Net? Does digital operations require a directed net? How would that operate?
  • Time segments? Would it make more sense to have a time slice management plan instead of a directed net. For example, in any 15 minute segment, the first x period is reserved for priority or emergency traffic, the rest of the period is a free for all?
  • Can fldigi be set to auto select operational mode? If so how so?

Finally, there was a decision to try and set up smaller hands on working groups to configure and test configurations before we take it to the field. There also needs to be a separate effort to create a quick reference guide. This can be managed via the digital list or this site.  If someone would like to volunteer to host a working group, please identify yourself and we will get it on the calendar.

Resources:

Here is a link to the presentations and other information from the working group.

NBEMS

Broadband-hamnet

 

 

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!