It took two years, but we finally managed a super reliable wireless network for our ARRL Field Day operations.

This year we will be at the same location and plan to accommodate up to five HF stations plus GOTA, VHF and, hopefully, some kind of Satellite station. Also a natural power station is planned, but will be co-located with an existing station.

The layout within the 300 meter circle will be close to what is shown in this picture…

Field Day Facility Layout

Our operation likes to keep the station operating positions seperated by hundreds of feet. In the past we typically used three single mode stations to alleviate the need for handling QSO dupe checking. However, the modern Field Day operation has site wide multi-station dupe checking with centralized and computerized logging to provide a competitive edge.

Simple Network Diagram of Field Day 2009 802.11

Features include:

• LinkSys WRT54G Wireless 802.11b and 802.11g Routers (Pre revision 6) – Alternatively you can get the WRT54GL which is the Linux compatible LinkSys product that can still accept the DD-WRT firmware.
• DD-WRT Firmware for WRT54G Routers
• MFJ-1800 2.4GHz WiFi dBi Yagi Antenna for 802.11b and 802.11g wireless networks. Includes camera tripod socket. This antenna looked pretty cheesy at first, but after using them for years, I find they work very well and are a solid, simple, useful design.
• HyperGain HG2409U Omnidirectional 2.4GHz Wireless LAN Antenna with 8.5 dBi. This sturdy antenna serves as the center point of the network with all remote yagi antennas pointing to it.
• N3FJP Field Day Network Logging Software – version 2.5 – one of many very useful and simple to use applications from N3FJP.com

Notes:

• The Blue boxes are the Linksys WRT54G routers running the DD-WRT firmware.
• The routers do not need the IP address unless you wish to access router statistics via the built-in web page feature of the DD-WRT operating system.
• The laptop PC at the VHF operating position was so close to the “server room” it did not require the features, power and external antenna features provided by the Linksys WRT54G router
• The “server room” was a small two-person back-packing tent. Its small size kept folks out to allow IT guys to debug in peace

Our transmitter stations were about as far apart as the rules allow so we used LinkSys WRT54G routers with the DD-WRT v23 software to “bridge” in the remote stations to one central unit which served as the site router. This made it easy to incorporate 2.4GHz antennas: omni on the router and those MFJ Yagi antennas on the bridges thanks to the external antenna connections. Laptops near enough to the omni router antenna needed no bridge and just connected via their internal wireless.

MFJ 2.4 GHz Yagi Antenna

The following lessons learned from 2006 and 2007 were carefully applied in 2008 resulting in almost zero downtime of the network:

1. Even if your router supports it, do not use DHCP addresses with anything other than wired or close in 802.11 PCs. Any little interruptions may cause DHCP assignments to expire creating a temporary outage; This is something the N3FJP client-server model just cannot tolerate. Use Static IP Addresses
2. Turn off 802.11 link speed autonegotiation in the DD-WRT admin settings. This will ensure the routers spend no time constantly trying to go “a little faster” resulting in short, but frequent network interruptions. These small interruptions cause N3FJP clients to lose connection to the FDNet.mdb file on the server resulting in the dreaded “unable to open database” error.
3. Use the slowest 802.11 link speed for high network reliability. Resist the temptation to use the fastest 802.11 speed available. Yes it is true you can blaze away at 54 Mbps, if the link allows it, but the best 802.11 receiver sensitivity is available if you pick a slower speed. We used 1 Mbps on our seven computer network running N3FJP with no problems at all. Within 802.11b the WRT54 receiver sensitivity for 11 Mbps is from 7-10 dB worse than 1 Mbps; 1 Mbps, which is simple BPSK, is significantly more sensitive and there is little reason not to use it. If you decide to select 5.5 Mbps in 802.11b you might consider using 6 Mbps 802.11g instead; the OFDM may prove more tolerant of multi-path effects than the CCK modulation used for the higher 802.11b modes.
4. Resist the temptation to use any kind of domain names, machine names, host names in your Field Day network. Use IP Addresses Only to keep your networking simple and straight forward.
5. If you use N3FJP FDNet 2.5 and accept “IP addressing only” is wise advice, your client computers will browse to the server’s data file like…
   • this \\192.168.2.100\directory\FDNet.mdb
   • and never ever this \\soandsosPC\directory\FDNet.mdb
6. Put your N3FJP FDNet Server Computer on the router 802.11 unit. This is the one that should have an omni antenna. It is true any station logging computer can be the server and that’s fine. However, the idea here is to make the stations all clients so if their power systems screw up, the data is safely stored on the server. Also keeping the critical server computer away from the high RF environment of a station should help reliability.
7. Whatever you do, do not connect two directional antennas to the two diversity ports of the Linksys WRT54G and point them in different directions. If you do this on your central router you will confuse local laptops with the wildly varying signal strengths. The best thing to do is leave one of those little antennas on one antenna port and cable up the after market antenna on the other port.
8. Make sure the central Omni WAN Antenna is at least 10 feet high to get over the heads of folks or you will have outages.
9. Use short, but dressable cables for the 2.4GHz signals and make sure it is the “good” stuff as ever dB matters. Make the cables long enough to allow for a trip free secure installation. Our central Omni antenna has 20 feet of LMR-400 “like” cable and works very well.
10. Consider a server only tent to act as your “server room” where “IT” folks can debug in peace.
11. Make a diode “oring” cable with a Gelcell and AC Power dongle for the Linksys routers so they stay up during generator refueling. If you don’t you might have to “re-browse” to the \\192.168.2.100\fd\fdlog.mdb file on the server computer. (We did not do this this year so we had to re-browse to the server sometimes and stop and start the FDNet program). Alternatively, a UPS on each router can work, but it may not be compatible with all generators.
12. Befriend your IT guys and buy them a dinner as navigating through the amazing mess of the many different ways Windows does networking is a total pain in the rump. Of the many laptops we had there was zero consistency in how they behaved when accessing the share on the server computer.
13. DD-WRT firmware for the LinkSys WRT54g router allows you to increase the power beyond Part 15 limits. If you exceed Part 15 power limits you are now transmitting as an Amateur Radio Operator. Obey Part 97 Identification and Power Limit Rules by putting your call-sign in the SSID of the routers and keeping the power under 100 watts (no, the Linksys cannot be set to 100 watts let alone 1 watt so you’re cool). Warning: if you raise the power in the LinkSys, it runs hotter; This could be a problem for commercial gear used outside on a hot day in June – use only the power you need.
14. Beware the dew point in the evenings. Most of our gear we take to Field Day is not rated for condensing environments. This includes the nighttime when the temperature reaches the dew point. Dew on unprotected circuit boards frequently results in circuit failure. Most ham gear and certainly the Linksys routers are designed to be inside the conditioned air space of a comfy home. There is not a whole lot you can do about this except, maybe, keep air flowing past your gear if possible. Just understand everything you take to Field Day should be considered disposable – including our radios. Sigh…

Results:

2007 was a terrific and efficient Field Day where we finally used the FDNet program the way it was intended to be used. Our 3A was comprised of SSB, CW and for the first time a multi-mode station that could do SSB, CW and Digital. The multi-mode proved priceless and various operators came and went adding CW or Phone skills. Previously we kept this third station as a Digital only station, but this time it pulled its weight nicely. Having global band-mode dupe checking is priceless.

The real-time QSO counts for CW, Digital and Phone ensured the competition between CW and Phone was kept lively.

We had a VHF station too and its computer connected via normal wireless to the server “room” just feet away.

A fellow came with a Satellite setup so we gave him an IP address and he was up and running on his internal wireless in no time.

The ability to bring additional copies of FDNet into the master log this easily (despite the Windows Share difficulties) was just too cool.

We had similar success in 2008 with a 4A deployment.

Result? – We brought the highest score in many years if not ever!

We look forward to 2009.

Java is still slower than directly compiled programs, but computers are so fantastically fast these days, this issue is becoming not an issue.

One of the participants on the Sunday Night Tech Net mentioned he is reviewing and modifying a new, too him anyway, JAVA based contest logger.

Enter JL Logger…

JL Logger is primarily a contest logger with growing support for many of the popular contents and a surprising number of State QSO Parties.

A more complete review of this package is in the plans, but for now the quick look suggests the following highlights…

• Since it runs in Java it runs on Windows, Linux, Solaris, anything that is running the JRE
• No tabbing is needed to record QSOs… just type
• Interestingly, it stores its raw data as Cabrillo QSO: lines in a text file
• Has a useful “stack” feature which allows you to “push” incomplete QSOs to a “do later” area – useful for coming back to that power house station when he runs out of pileup
• Has rig interfacing for Icom

A few concerns include…

• Some of the Cabrillo Category selections are not Cabrillo compliant
• CW interface is supported, but I saw nothing for WinKey which is, quite clearly, the way things are headed
• It, by design, does not do partial lookups – a handy thing for dupe checking in speedy contesting
• No DX Cluster Support… again by design
• Claims to be open-source and the source is there, but the license is not one of the usual open-source licenses making additions from others more difficult

JL Logger works with the very small test I performed. The real review will stuff it full of QSOs and give it a good shake down.

I look forward to seeing if a logger this streamlined can be a useful substitute to N1MM, N3FJP, etc.

This year we extensively used the “operator initials” field in the N3FJP Field Day Network 2.8 logging software package. Operators used their call-sign as their ‘initials’ while honored guests used their actual initials.

The site-wide log offered many great analysis possibilities. One particularly interesting metric we tracked this year was QSO rates. We generated graphs of QSO totals vs. Time Between QSOs. Here is an example of the entire log…

QSO Rates of Entire Club Field Day Log

We are able to further parse the QSO data by operator, mode, band and any other parameter recorded by the very nice N3FJP Field Day Network logging software.

This year was especially cool because many operators who are not regular contesters made an effort to come by and operate. This is fantastic. We had high hopes to make our 4A Field Day operation inviting to all our members young and old. Indeed young and old came out and had a great time.

What I noticed about some of the older operators was their desire to use pen and paper to record call-signs and exchange information of a QSO and then move to the computer keyboard to record the QSO. This frequently resulted in several dupes since these folks were not capitalizing on the logging computer’s instant dupe checking.

There are many reasons to not use pen and paper, but I wondered if the overall efficiency might be one of them. Since I know which operators used paper and since the wonderful N3FJP software records each operator’s identity all I did was add a field to the database and marked the QSOs initially recorded on paper.

Here is the graph of the very same Field Day results of the operators who logged straight to computer…

QSO Rates of Computer Loggers

…and here is the graph showing the performance of the paper users…

QSO Rates of Paper Loggers

It seems at least a little clear that jotting down QSO information on paper in a contesting environment places an obvious obstacle to operator efficiency. If you look at the graphs above it is clear that most of the QSOs made were not only made more efficiently, but in far greater numbers by the operators skipping the use of paper.

Many good Ham Radio Contest Logging software packages exist to help the Amateur Radio operator record those all important QSOs. Good titles to consider include N3FJP, DX4Win, Ham Radio Deluxe, N1MM. Prolog2k, Winlog32 and WriteLog. Instant Dupe Checking alone should make you want to remove paper form your logging flow.

There are many reasons why data is different between groups of attributes like paper and non-paper QSO loggers. Is it jumping to conclusions? You be the judge.