VHF June 2008
A few notes from the June 2008 VHF Contest. As usual, I try to take advantage of the field operations to test several technologies at once. This makes for a lot of preparation, but in general, is worthwhile. This time, I spent a lot of time on the wireless technologies and basic infrastructure components. Much of this architecture could be used in a field deployment for other activities. (e.g. emergency operations, incident commands, etc.)
We used several wireless technologies on the Mountain this year.
915 MHz Link
This was a point to point link between the top of Flagpole Knob and Harrisonburg, VA. (28.46 KM) We used 915MHz this time because previous 2.4GHz 802.11b links were unreliable. (They worked, just not all the time.) The link was SOLID!
The link was formed using a Netgate router (ALIX embedded computer), Voyage Linux, RFLINX 2W Amp and a 13dbi yagi. (drawing) The radio cards were XR9's from Ubiquiti. (http://www.qsl.net/kb9mwr/projects/wireless/plan.html for some info about using wireless cards under part 97)
We had solid connectivity for the entire contest - while the equipment was powered. The linux tools reported -55dbm signal levels and -85dbm noise floor. (30db gain margin) The STA was located in Harrisonburg and the AP was on the MT. Using iperf between the nodes reported about 2MBps (bytes) from FP to HB and about 200 KBps from HB to FP. I'm not sure why the bandwidth was asymmetrical, but it makes some sense because download speeds were faster FROM the AP TO the STA.
The equipment (Ranger, Tick, AP, Amp, WX equipment and the Cisco WLC w/AP) drew about 100 Watts. We used a 400W DC inverter connected to the RV batteries.
SUMMARY: Not so good
Tested a 1.2M Tachyon Auto Deploy system. We weren't able to make this work. There were three main issues. 1) This unit was BIG! It took 4 guys to move. 2) User error led to improper deployment, which took several hours to resolve. The feed point arms weren't extended as they should have been. The instructions were confusing. 3) The network configuration didn't work. We were able to ping from the admin gui, but we were not able to use a PC or network behind the satellite router.
We tested the smaller version several years ago and it worked great. Given the size of this unit and the success of our 915MHz link, we will probably not conduct any further tests. I have confidence we could have made this system work. The key lessoned learned is: test the gear before bringing it to the field.
802.11g Hot Spot
Used a Cisco AP1510 and 2600 Wireless LAN controller. This system provided excellent coverage. Every user in Camp was able to access the network. We had no technical difficulties other than forgetting to save the configuration changes so they survived rebooting.
After testing WPA2 w/AES, we opted for an open AP to cut down on tech support issues. ;)
We used an embedded computer to provide routing functions. (PC Engines WRAP) This unit worked great! It was low power, had no moving parts and was quiet. Routing was accomplished using a combination Voyage Linux and Quagga OSPF. The router functioned as a DHCP server, DNS server, time server and firewall. Administration was accomplished via SSH. Firewall rules were installed using Firewall Builder on a Linux (Ubuntu) laptop.
Descriptions and notes for the applications we ran on the Mountain. Most of these applications were run on a small VIA 400MHz computer running Ubuntu Linux. Users on the local LAN (except the contest stations) had unlimited access to the Internet. They could check e-mail, browse the web, etc.
Squid Caching Proxy
We installed a Squid caching proxy server to help with a flaky wireless link. First - since the 915MHz link worked so well, we didn't really need this proxy. Second - I was able to configure the automatic discovery features for IE and Mozilla. I tried using DHCP to hand out option 252, but it didn't survive the WLC DHCP relay. (Need to verify with packet sniffer.) Instead, I used a DNS entry to point to the wpad.dat (same as proxy.pac) file on the web server. Using this method is the best way to handle transparent proxies.
SUMMARY: OK - Need more use
I configured Apache to serve web pages to the LAN. I gathered useful links, but I did not advertise this site to the Camp. I also installed mediawiki, in case a local wiki was needed. Not sure this was useful, yet. The WX links, especially to Wundermaps, were important. I used them constantly.
We used Xastir running under Linux. This was mostly a bust. It wasn't possible to identify rover stations, so it wasn't used. However, we did experiment with transmitting local beacons from the camp to the APRS radio before the contest. The APRS radio was an Alinco DR-135 coupled to the linux server (Ranger) using a home made interface. We used the soundmodem TNC software.
The server was activated so a Windows APRS system could be tested. We used UI-View with precision mapping software. (pserver) UI-View does a better job of filtering the data. It provides the ability to filter very specific ICONS, whereas Xastir is a little 'too smart.' For example, only stations with reported speed values are classified as 'mobile' in Xastir. This meant that stationary stations (e.g. rovers) wouldn't be displayed if Xastir was used.
We also tried listening to HAMIM frequencies. (147.585) But didn't hear anybody.
SUMMARY: Excellent (depending on perspective)
To protect the integrity of the contest stations, we used an iptables based firewall on Ranger. This blocked all access to/from the contest LAN. We opened the firewall during preparations to download new versions of N1MM. (8.6) While this cut down on the 'fun factor' during the contest (i.e. web browsing), it sufficiently protected the computers and the integrity of the contest.
SUMMARY: OK - needs improvement
We connected a Peet Brothers weather station to the APRS computer. It was great to have live WX reports about the temperature, wind, humidity and barometric pressure. Since APRS was a bust, I think we look at making this data available on the web. We also need to make sure the data is collected 24x7.
The highest speed wind gust I recorded was 25 MPH. The RV started shaking around 15 MPH.
I need a Windows based server for VWS. The Linux version of Weather Display is terrible.
We used the web for real time weather reports. The Wundermaps proved most valuable and interesting to watch.
SDR Flex 5000A
SUMMARY: OK - worth trying again
We used the Flex 5000A and a transverter on 222. I thought this was great! However, general consensus in the Camp was that it was too complicated to operate If I had a K3, I could try Telepost's LP-PAN Adapter, which would give us the best of both worlds. (http://www.telepostinc.com/)
- The pan adapter allowed me to search and pounce. While a different concept to 'running,' I was able to work several stations that I would have missed by staying on a single frequency. This alone makes this worth pursuing!
- Sensitivity - no need for the mast mounted preamp!
Not So Great:
- A single mouse and keyboard made it difficult to enter data into N1MM because the windows 'focus' was in the SDR software. Several times, operators accidentally changed the radio by typing QSO data.
- Recording DVK files was difficult because the only way to make this work was to use the SDR monitor button. There is a delay between the operator's voice (about 300ms) and the sound in the head phones.
- The software has too many options exposed. We need a 'contest' mode, with limited buttons.
Other Random Thoughts
A couple of notes about other things.
SUMMARY: OK - worth doing again
I liked using the Trailers. I felt like the equipment was more protected and the power set up was easier. Having pre-wired AC, with appropriate grounding helped get things up and running quickly.
The low clearance between trailers was a safety hazard.
I didn't like operating next to the 'main' door because there wasn't a lot of room. I suppose this was mostly a factor during set-up.
Skipping lunch was a great idea. The meals were fabulous - especially the steaks, salad and wine.