Building comms for Battle Mountain

Shortly after returning to Sonoma county, I got in touch with a friend
from my IHPVA/WHPVA, Steve Delaire of Rotator Recumbents. Though no longer in the recumbent business, Steve is still active with IHPVA.

From what I can tell IHPVA now pretty much just does one thing– they run a one-week speed event outside Battle Mountain, Nevada.
Speed events are fun but I have always been more interested in practical applications of human power, like commuting by bike.

Still and all, Steve told me he had volunteered to work on communications for the event.  Providing communication support is
interesting to me. So I signed on to help.

There is no cellular network out there in the middle of Nevada, so mobile phones are useless. They’ve already tried handy talkies, which do not have enough range.

There is a nearby 2m repeater, so my first idea was to enlist local
ham radio people. Turns out that approach had already been tried and they are not interested in helping.

Steve’s idea was to use WiFi and smart phones. I am not convinced this is the best approach but it is certainly interesting to me, so it’s
what we’re trying. Steve still has more optimism than I about the
limitations of WiFI in smart phones. 🙂 My experience indicates that
you need a good antenna to make wifi work over more than about a hundred feet and I’ve never seen a smart phone with a good WiFi antenna.

But I love working with all these goodies, so I dove in.

Requirements

The course is a total of about 6 miles end to end. It’s a straight line. It’s flat.  It’s in the middle of the desert, so there are no trees or buildings. So we don’t need to worry about obstructions other than the ground. (It gets into the Fresnel zone.)

There are road closure points at each end of the course, and at two side road crossings.  There is a launch area, a long run up stretch for bikes to come up to speed, timing traps, a coast down stretch, and a landing zone where the bikes are caught (the catch area)

The most important communications links are between the course management area at the catch area and the launch area. Bikes stack up up in the launch area. A message to launch a bike has to come from course course management when the course is clear.

Roads have to be closed when bikes are on the course, and the maximum closure is 30 minutes to allow stopped cars to get through, so there is also a need to talk to people at the closure points.

Design

I have been working with Ubiquiti and Mikrotik wireless equipment at my current day job with CDS Wireless in Santa Rosa. Based on brief experience there I chose Ubiquiti as the supplier for the radios.

Our Ubiquiti dealer, Streakwave, put us on the right track by suggesting radios and antennas to use, and how to configure them to work in mesh mode.  In this configuration the radios will act like access points to allow smart phones (and any other WiFi devices) to participate in one network. Mesh (“AP Repeater”) mode means that the three radios will pass packets along; in other words, we can put the three radios in a line along the course and the one in the middle will repeat any packets it sees so that the traffic can get from one end of the line to the other. If we need more range we can simply add more radios to the line.

WiringSchematic

GIS

This project seemed to call for a map, so I made one.

BattleMountain_BlogMap

I used DEM data (elevations) to discover there is a small hill at the north end of the course and a grade at the south end.  We might take advantage of the elevations next year to get better placement for the radios.

Tests with no Server

Our first test were done to confirm we could set up a network and send traffic over it without worrying about the application software.

Steve wants a solution that only uses apps, no server. I think this would be great, but all the communications apps I have seen so far though that “don’t require a server”, really do. They use a public server based on the Internet, and we don’t have any Internet connection.

highway37test

Addition of server

I tested several handie talkie style “push-to-talk” apps but have not found any that work without either an Internet connection or a proprietary ($) server. I solicit your suggestions!

We also wanted to be able to send text messages, same story there. You need a server.

I fell back on VOIP and XMPP. I have experience using Asterisk phone systems and XMPP chat systems.

The first ‘server’ we tried used a BUFFALO WZR-HP-G300NH2 gateway router hacked to run OpenWRT.  This is capable of doing almost everything we need. But it will not support conference calls!  Mass communications is a cornerstone of making this system work.

I also want a nice web-based account management tool (based on LDAP) so that staff can add or remove users easily. I don’t have that going yet.

So I borrowed an old laptop, installed Xubuntu 14.04 on it, and installed Asterisk (PBX server) and Openfire (XMPP server). While I was at it, I added a wiki so that I could easily give Steve some project documentation and tie everything together via web browser. The laptop does DNS name serving and is the network DHCP server. The laptop can also function as a router when the system is connected to the Internet. (So few words to describe 2 weeks of work!)

Testing

Long experience has made me conservative on projects like this. I’d normally do testing at each stage to make sure I had a solid foundation to work on as we added complexity. Doing this builds confidence and helps catch problems early on when fixing them is still cheap and easy.

In this case, I had to keep reminding myself this project is really just for fun and so I relented to Steve’s desires to push ahead with minimal testing. “Failure is always an option.” 🙂

We did one range test to confirm that two of the Ubiquiti radios can talk at about a 3 mile range over open ground. (It is hard to find open, flat ground in Sonoma county! Too many trees here!)

During the range test we got the phones to connect with VOIP software, and they worked fine.

Ship it!

Here is what got shipped out today. (9/5/14)

Three tower radio stations, each with

  1. Ubiquiti Bullet M2-HP access point, equipped with 12 dBi omni antenna (M2 = 2.4 Ghz band, HP is “high power”)
  2. 20′ tower made from steel and PVC pipe (Steve’s contribution; I am not sure how he will anchor the towers)
  3. POE injector + 50′ shielded CAT6 cable to send power up the tower.
  4. 24v converter, to help keep the radios operating even when battery level drops and to compensate for voltage drop on the wire.
  5. 12v volt gel cell battery

At the control table,

  1. A server built on a laptop (Dell Vostro 1500 upgraded with a 60GB SSD)
  2. An inverter to allow running the laptop from the battery.
    (DC to AC conversion is inefficient, but the laptop is on loan. Next year we should eliminate the inverter and use a dedicated 12v laptop power supply for the server.)
  3. RigRunner 4004USB and a connectorized volt/amp meter to facilitate testing power draw. USB connectors on the
    RigRunner can be used to recharge / power smart phones from the 12V battery.
  4. The laptop ethernet plugs into the LAN jack on the Ubiquiti POE injector.

All the DC connections are made via PowerPole connectors for maximum flexibility.

We tested apps and the plan is that Steve will tell participants what
to load and configure when they are at the event hotel, where Internet access is available.  For VOIP communications, we settled on Media5-fone, which works on both iPhone and Android.  I have tested Xabber as an XMPP app for Android. As I write this, I have not heard what iPhone app Steve has chosen.

Conclusions

I would have spent another week just doing range testing and testing the WiFi to phone connections.  I did a bit of that on my own, I remain convinced that will be the biggest problem. I think the phones will drop off the network if they are more than about 100 feet from a tower. This means they will probably be adding three more towers next year.

I provided all the pieces they need to do both voice and text communications.  They will need to experiment to figure out good protocols to use these tools.  I am hoping they really give it a try; there is a lot going on out there but they really need good communications.

Problems I anticipate and what to do about them

1. Smart phone batteries go dead too quickly. Fix: carry extra batteries.
2. Laptop and smart phone screens are invisible in desert sun. Fix: canopies? Broad brimmed hats?
3. Smart phone wifi range is bad. Fix: add more towers.
4. People can’t figure out how to use the apps on their phones. Fix: provide advance training (web site?).
5. Staff will have problems understanding how to operate the server software. Fix: Write better software!

Alternatively, scrap the whole concept and use real radios. 😉

Next year

  • Find good PTT (push to talk) apps
  • Find the best SIP apps
  • Complete the LDAP integration and implement a simple account management page.
  • Reader board on web page. Staff could update a reader board after each run so everyone could monitor results in real time.
  • Can we use voice over XMPP instead of Asterisk for conference rooms?