For Field Day this year, our ARES group, Amateur Radio Emergency Service of Douglas and Elbert Counties (ARESDEC) in Colorado decided to use AREDN for networking the logging PCs, using the N3FJP Field Day Contest Log software and Ubiquiti nodes. We used the TCP method in the N3FJP software, so the only setup needed was to put the IP address of the server PC in all of the client PCs. We had 5 stations setup for Field Day, so there were 5 clients connected to the server. We used a Rocket M2 with a vertical omnidirectional antenna for the server and placed the server and Rocket M2 at our communications trailer where we knew we would have an uninterrupted power source (batteries, solar panels and a generator as backup.) Since the server was co-located with the CW station, the CW station logging PC had a Nanostation M2 connected to it. The server was located in the southwest corner of the Field Day site. All of the other station locations had a Bullet M2 and Yagi pointed back to the server's omnidirectional antenna. Because Field Day setups are within a small geographic area, there was no concern regarding distance issues between nodes. The rather short distances involved resulted in solid signal strengths, as would be expected. The question was, would the TCP connections remain solid for the duration of the event? N3FJP warns about network disruptions causing issues with the logging software, and this was our first attempt at using AREDN for the networking, so the setup was tested prior to Field Day in order to gain a level of comfort that it would work okay. During testing, we repeatedly took client nodes down for a while and then brought them back up, took the server node down and brought it back up, and every time the TCP connections would re-establish and continue working with no corruption of the server's logging database. We could not get the server database corrupted no matter what we tried to do on the AREDN side to disrupt the network. And, sure enough, the network ran perfectly during the Field Day event, despite very heavy rains, lightning nearby, and high winds. The Ubiquiti nodes performed flawlessly and the AREDN mesh networking made setting up the system very easy. We have used standard WAPs before at Field Day, and that works okay if the logging clients and logging server stations are close together, but when we gravitated towards having the stations separated by greater distances within the 1000 ft diameter allowed by the rules, it can begin to stretch the limitations of a single WAP to cover that area, especially with laptops sitting inside metal trailers. Being able to easily place AREDN nodes outside of the trailers, while keeping the logging PCs and their operators warm and dry inside a trailer, eliminates any concerns with RF coverage. We could have run fiber optic cabling between the stations, but in the spirit of the radio hobby, an RF-based network seemed more appropriate, especially one conducted on amateur allocated frequencies. All-in-all, the use of an AREDN mesh setup for Field Day worked extremely well, and our group scored the highest Field Day points this year than we ever have.
Attached is a photo of the site layout.
The mesh network was established at our Field Day site in less that 15 minutes. We have a mixture of hardware nodes using a rocket,
M2/s and microrouter. All six nodes were on the latest ARDEN software. (3.21.4.0) The N3FPJ software clients were pointed to the
server using the servers ip address. All the laptops at the stations connected to the server without a problem to start with.
At this point we thought we were set and when Field Day started everything was working. However in about 3 hours the clients started to
have issues communication with the server. The clients were getting the message that the server was slow to respond. Troubleshooting
showed no network issues. Signal strengths were all good and ping tests revealed no issues. We replaced the micorouter with an M2, but
this did not solved the problem.
We had to change the N3FJP software to log locally as all troubleshoot failed to find the problem. With Field Day underway continued troubleshooting
the problem was going to cause frustration for the operators. After Field Day we merged the logs together.
Troubleshooting after Field Day.
After Field Day we set the mesh network up again at home starting with two stations connecting to the server with the merged Field Day log.
The clients immediately had the same connection issues. ( server slow to respond). Pre - Field Day testing with an empty log worked, we
cleared the log also cleared the slow server response. It should be noted that the server here was a different hardware server that used at
Field Day. Both did have Windows 10 installed. With the fresh log we were able to add client stations and log entries. The issue reappear as the
number of entries grew. Backing down to two client stations did not resolve the problem.
Solution Found:
The bandwidth on the nodes was set to 10 Mhz. Increasing this to 20 Mhz cleared the issue. We were able to import the real Field Day log and
increase the number of client stations to 6. Performance seem to improve when we added the client alias name to the node it was connected to
( example W0ERH-CW, W0ERH-Solar) which matched the client name in the N3FJP network configuration.
Our problem seem to be tied to the size of the log file. What we observed is the log is pushed from the server to each client as entries are updated.
This was noted when a client was first started ( with 10Mhz bandwidth) and it would take between 1 to 2 minutes for the log from the server
to be displayed on the client. Once the bandwidth was increased to 20Mhz this delay was not observed.
Bill (KA2FNK)
And yes, we found out the same thing with the log entries getting copied onto every client PC on the network, which I wasn't expecting. In a way, that is kinda nice in that a backup is being made on multiple PCs, but it does lead to additional traffic on the network.
Thank you for the troubleshooting info and the client alias tip. All good stuff to know for future Field Days, or for any events where we use AREDN in a similar scenario.
73,
Gary, WB5PJB
K9EI
2397Mhz - half of the bandwidth 10Mhz (since channel are on center) = 2387Mhz (outside of 2390-2450 segment)
Yes, you need to be in the ISM band or use "CH1" @ 20mhz. Otherwise you are technically out of band on CH -2 @ 20mhz.....
Matt
K9EI
The thread was originally titled 'Field Day 2021', but the discussion
was primarily about 'Contest Log software' using an AREDN network.
I don't know how AREDN served a purpose that a plain-jane AccessPoint and Clients would have not have sufficed.
The activity was Amateur Radio related and the network manager chose to use Amateur Radio frequencies.
Marvelous.
I'd like to talk about this some more. So when setting this up, we should:
1. The poster in #1 and #2 mentioned 2.4 GHz devices, so +1 with K5DLQ about 20 MHz bandwidth
is only permitted on channels 1 through 6, 10 MHz bandwidth on channels '-2', '-1', and 7,
5 MHz bandwidth on channel 8.
Note that channels '-1' (at any bandwidth) and higher are shared with part 15 devices.
2. I am familiar with using TCP .vs. UDP data packets. I never heard of a 'fileshare' data encoding.
3. I recommend that the server be on a battery UPS.
I hope this helps,
Chuck
With Field Day next week I have started getting te nodes checked out The logging software used TCP. When we had issues we tried fileshare, but did
not really expect it to work as it generates more network traffic.
The server as well as the node is on solar power. Only one of the three stations for Field Day is on generator. The other two are solar powered
I plan to use a channel in the 1 to 6 range based on how te 20Mhz look at the site
Bill KA2FNK