Support for Beaglebone Black running Ubuntu 13.04

I’ve been very pleased with the performance and support for the HSMM-Pi project on the Raspberry Pi platform, but have been curious to know how well it would work on other platforms. I received my Beaglebone Black (BBB) board in the mail on Friday and didn’t waste any time installing Ubuntu on it. The BBB is a small single-board computer similar to the Raspberry Pi. One of the compelling features of the BBB is that it has 2GB of onboard flash memory in addition to the memory card slot. I can see this bringing the cost and complexity down in an installation with several BBB nodes. You can install and run the OS from the onboard flash memory which is much faster than the SD memory card. It’s also easy to reflash the OS onto a BBB node; just pop in a memory card with the OS, hold down the Boot button while applying power, and the BBB gets re-flashed. It’s also got a 1GHZ ARM processor that is noticeably faster in comparison to the Raspberry Pi. And being priced at $45, it will be a strong competitor with the $35 version B Raspberry Pi. Lastly, the ARM processor features an open-source design that is preferable to the closed design of the Broadcom processor used on the Raspberry Pi.

I installed the Ubuntu 13.04 flash image dated 2013-08-24. The installation was pretty straightforward: write the image to an SD card, insert the card into the unpowered BBB, hold down the boot button on the BBB, apply power, then wait till the 4 surface-mounted LEDS are lit.

Once Ubuntu was installed, I SSH’d into the BBB and began installing HSMM-Pi. This was the first time I’ve tried the installation of HSMM-Pi on a clean Ubuntu system other than the Rasbian distribution meant for the Raspberry Pi. I encountered a few surprises:

  • The chkconfig utility to enable/disable system services is not available on Ubuntu 13.04. The sys4-rc-conf program should be used instead.
  • The make utility for processing Makefiles is not installed by default. That was a shocker.
  • There was one spot in the install script where the ‘pi’ user account was referenced, but that account is obviously not present in a non-Raspbian distribution.
  • The Beaglebone uses the ARM CPU architecture which supports position-independent code (PIC). The OLSRD codebase generated some compilation errors related to the use of PIC. I resolved this by changing the OLSRD build steps in the HSMM-Pi install script to pass the -fPIC flag to gcc while compiling.
  • Must include an explicit ‘auto eth0’ statement in the network interface configuration file to ensure that the Ethernet adapter starts automatically on boot.
  • The resolv.conf file is actually a symbolic link to a file in the /run ditectory. The link had to be replaced with a regular file that could be managed by HSMM-Pi.

I have corrected all of these issues in the ‘install.sh’ script that is checked into the HSMM-Pi Github repository. This means that HSMM-Pi is available for use with:

  • Raspberry Pi nodes running Rasbian (based on Ubuntu 12.04)
  • Beaglebone Black nodes running Ubuntu 13.04

This is great news for HSMM, as well as the HSMM-Pi project. More device platforms and versions of the Ubuntu OS should give people more options for building HSMM mesh nodes with versions of Linux that will be supported well into the future.

Advertisements

Building Dissent Networks

Here’s an interesting video about the design challenges associated with dissent networks built using mesh networks. Dissent networks are usually built using a mesh networks, and are often built in response to the censoring or limiting of Internet access by oppressive governments (think Egypt during the Arab Spring protests in 2011). The video suggests that there’s no silver bullet for building a mesh network that’s difficult to disrupt while also providing good performance. For example, using directional antennas improves signal range and reception, but it also makes the network more conspicuous and easier to trace; on the other hand, using omnidirectional antennas leads to a more robust network that is harder to jam, but it also leads to a lot more transmission collisions that decrease the network efficiency.

HSMM-Pi Node as a Network Time Server

Last week I received an excellent suggestion from Drew Wood/KF5MMW to have a GPS-equipped HSMM-Pi node serve as a network time server (NTP server) on the mesh network.  The GPS signal includes high-precision date/time information, in addition to the geographic location data we’re all familiar with.  The HSMM-Pi mesh node runs a daemon called ‘gpsd’ when configured to use a GPS device for location info.  The ‘gpsd’ service can provide time information to the ‘ntpd’ daemon that runs on all mesh nodes.  The ‘ntpd’ daemon is responsible for keeping the system clock synchronized in relation to reference clock.  You can have the ‘ntpd’ daemon on the Pi use the ‘gpsd’ time signal as a reference clock.  It’s also possible to have other mesh nodes in the network synchronize against the ‘ntpd’ daemon on the GPS-equipped mesh node.  The following steps will show you how.

GPS-equipped Mesh Node

1) Configure the HSMM-Pi node to use a GPS device:

GPS-1

2) Reboot the HSMM-Pi node and verify that it acquires its location using the GPS receiver.  Go to the Status page and verify that a globe icon appears to the right of the node name:

GPS-2

HSMM-Pi Node without a GPS Receiver

You might also want to have an HSMM-Pi node that doesn’t have a GPS receiver to synchronize its time to the mesh node equipped with a GPS receiver.  This, too, is pretty easy:

1) Configure the HSMM-Pi node to use the GPS-equipped mesh node as an NTP server.  Go to the Admin->Network section, and then select the ‘Time’ tab.

2) Specify the IP address of the GPS-equipped mesh node in the NTP server field.  I recommend using the IP address (i.e. 10.201.5.3) instead of the hostname (i.e. KK6DCI-3.local.mesh) because the hostname might not be resolvable at the time the Raspberry Pi boots up, and I’ve noticed that the ‘ntpd’ service ignores unresolvable NTP servers.

GPS-3

3) Reboot the Pi as suggested, and that’s it.  You can verify that the Pi is getting it’s time from the other node by running the ‘ntpq -p’ command from a shell:

GPS-4

The NTP server on every HSMM-Pi node can function as a server for other devices on the network.  This should make it easy to synchronize a large network using just a single GPS-equipped HSMM-Pi node.  Pulling the time from a GPS signal would be extremely useful in a scenario where Internet access isn’t available (i.e. natural disaster).

Compatibility with HSMM-Mesh/Broadband Hamnet v1.0.0

This evening I upgraded my Linksys WRT54GL router to the latest Broadband Hamnet release version 1.0.0.  After configuring the SSID and channel to match those used by my HSMM-Pi nodes, it joined the mesh and worked just as it did with HSMM-Mesh 0.4.3.  The Broadband Hamnet distribution does not have the secure plugin for OLSRD, so you will not be able to the secure feature present in HSMM-Pi when deployed alongside Broadband Hamnet nodes; the OLSRD secure plugin is a wonderful feature, but is probably not needed in most HSMM mesh deployments.

Please let me know if you find any incompatibilities between HSMM-Pi and Broadband Hamnet, and I’ll do my best to get them resolved quickly.

Platform support beyond the Raspberry Pi

I designed the HSMM-Pi project with the Raspberry Pi in mind. It’s a cost effective, compact and powerful platform. However, there are no specific ties to the Raspberry Pi in particular. You should be able to install it on any Debian-based system.

I’d love to hear from anyone who has installed the HSMM-Pi project on a Ubuntu/Debian system using a device platform other than the Raspberry Pi. I’m interested in the Beaglebone Black and PC platforms in particular. I’ll probably conduct my own tests soon, but figured I’d throw this out in case someone has done it already.

Please comment on this post with your findings. Thanks!

New HSMM-Pi Videos Up

I’ve posted two new videos related to the HSMM-Pi project.  The first one show is a screencast that shows the location features in HSMM-Pi (sending mesh node coordinates through the network) and service forwarding.

 

The second video shows a tabletop demonstration of some of the mesh node hardware:

Node Location Data in the Mesh

In the last couple days, I added support for distributing mesh node location (latitude, longitude) throughout the mesh.  You can specify the lat-lon explicitly through the HSMM-Pi web application, or configure the node to pull the lat-lon from a GPS device.  If using GPS, then the device must be supported by the GPSD service.  I used the GlobalSat BU-353 receiver (Amazon) and it worked flawlessly; the receiver is priced reasonably at just $32 USD.  The HSMM-Pi node will read the lat-lon information at 1-minute intervals and transmit it throughout the mesh network.  This greatly simplifies the tracking of a mobile mesh node in case it’s carried on a vehicle or person.

The HSMM-Pi node will distribute the location info through the mesh network using the OLSRD nameservice plugin.  When viewing the status page of a node, you’ll see a globe icon adjacent to nodes for which location information exists.  Clicking on the globe will result in a map being displayed with the node location marked.  This could be very useful in deployments with a large number of nodes over a large geographic area.

 

Screenshots

Status page showing node location map links:

Node Location in Status

Map displayed for a given node:

Node Map

Location Settings with a fixed location:

Location-Fixed

Location Settings with a location pulled from a GPS receiver:

Location-GPS