Frequently Asked Questions

You don't have to switch. FD Commander has built-in UDP listeners for N1MM Logger+, WSJT-X, JTDX, fldigi, and any logger that can send ADIF over UDP. Keep using what you like for on-air operation and FD Commander picks up the contacts automatically. It also accepts ADIF file imports if you'd rather bring contacts in after the fact. The reason to add FD Commander on top of your existing logger is everything else Field Day involves: volunteer scheduling, equipment tracking, safety checklists, guestbooks, NTS message handling, and scoring with all 18 ARRL bonus categories. If your club coordinates all of that with spreadsheets, paper sign-ups, and group texts, FD Commander puts it in one place -- and your operators never have to leave the logging software they already know.

Plenty of clubs do, and there's nothing wrong with that. But if your club has ever had duplicate contacts across stations that nobody caught until Cabrillo review, or an empty operator chair at 2 AM because two people thought the other one had that shift, or the safety checklist didn't get done because everyone assumed someone else handled it... those are the problems FD Commander solves. If none of that has ever happened to you, you're either very organized or very lucky.

No. The contact logger is one piece of it. FD Commander also handles pre-event planning (stations, equipment, schedules, safety checklists), external logger integration (N1MM+, WSJT-X, fldigi via UDP, plus ADIF file import), a visitor guestbook, NTS radiogram tracking, photo uploads, role-based access control, and live scoring with the full ARRL bonus point formula. The logging part is intentionally simple: a single-field entry flow designed for speed. The rest of the platform is what makes it different.

Operators use it from any device with a web browser: Windows, Mac, Linux, a tablet, a phone, whatever. It's just a website on your local network. The server runs on Linux, which is only one machine. That could be a Raspberry Pi, the old PC in the ham shack, or any spare box. Linux is free, runs on nearly anything, and most hams with any tech background have touched it. The deploy script targets Ubuntu/Debian and setup takes about 5 minutes.

You need to be able to clone a git repo and run a shell script. The deploy command is literally sudo ./deploy.sh --domain fd.local and it handles everything: dependencies, database, web server. You don't need to configure Apache, edit PHP files, or touch a database. But if the phrase "SSH into the Pi" makes you uncomfortable, you'll want to recruit your club's tech person.

Yes. It's been tested on a Raspberry Pi 4 with 2 GB of RAM running off a battery pack. FrankenPHP and Laravel Octane keep the memory footprint small. A Pi is actually a great Field Day server: low power draw, fits in a pelican case, and you can prep it at home weeks before the event.

Operators keep logging. If a browser loses its connection to the server, contacts queue locally on the device. When the connection comes back, they sync automatically. You don't lose contacts because someone tripped over the ethernet cable. If the server goes down entirely and you need to log on paper for a while, FD Commander has a paper log transcription feature so you can enter those contacts with the correct timestamps once you're back up. Either way, bring a spare SD card with a known-good image.

To deploy: yes. The install script downloads dependencies, so do this at home on your regular internet connection before the event.

To run: no. Once deployed, the entire platform is fully air-gapped. Zero external calls, zero cloud dependencies. This is by design. Many Field Day sites have no internet at all.

Yes. FD Commander is a full Laravel application with role-based authentication, CSRF protection, and input validation. It's built the same way any production web app is, so exposing it to the internet is fine if your setup calls for it. This is especially useful in the weeks before the event: club members can register their equipment, sign up for operating shifts, and review station assignments from home instead of waiting until setup day. During the event, people who can't make it to the site can follow the live score, and you can make the guestbook accessible from a public URL.

If you do this, use TLS. Running over plain HTTP on a LAN is one thing. Running over plain HTTP on the open internet means passwords and session tokens travel in cleartext, which anyone on the path can read. Set up a TLS certificate (Let's Encrypt is free) and make sure all traffic goes through HTTPS. The deploy script supports this. There is no good reason to skip it.

No. FD Commander is a web application, not a rig control program. It doesn't key your radio, decode digital modes, or read frequency from CAT. CAT control is a fundamentally different technology. However, FD Commander does integrate with external loggers like N1MM Logger+, WSJT-X, JTDX, and fldigi over UDP. Those programs handle the RF side, and FD Commander receives their logged contacts in real time so operators don't have to double-log. You get the best of both worlds: your preferred logging software for on-air operation, and FD Commander for scoring, deduplication, and coordination. CAT control isn't on the roadmap. Log integration is already here.

Yes. Cabrillo export is a core feature. When the event ends, you generate a Cabrillo file ready to upload to the ARRL submission page.

Import: yes. FD Commander can receive ADIF data in real time over UDP from external loggers (WSJT-X, N1MM Logger+, fldigi, and others), and it has a file import wizard for uploading .adi/.adif files with station mapping and record validation.

Export: no. FD Commander is focused on the Cabrillo format that ARRL requires for Field Day submissions. ADIF export for importing into your personal logging software is not currently a built-in feature.

Yes. FD Commander has built-in UDP listeners for N1MM Logger+, WSJT-X / JTDX, and a generic ADIF endpoint that works with fldigi and others. Enable the listener for your program, point your logger at the server's IP and port, and contacts flow into FD Commander automatically. Dupe checking, scoring, and Cabrillo export all work the same whether a contact was logged in the FD Commander UI or received from an external logger. You can also import an ADIF file after the fact through a guided wizard that lets you map stations and review every record before it's committed.

All contacts go into a single shared database in real time. When an operator enters a callsign, FD Commander checks it against every contact logged by every station on every band. Dupes are flagged instantly before the contact is saved. No post-event deduplication needed.

It's a single input field. Type the callsign, the exchange info populates, hit Enter, and you're on to the next one. Dupe checks and section validation happen as you type, not after you submit. It's not going to beat dedicated contest software at a multi-multi, but for Field Day rates it's more than fast enough.

Scoring is automatic. Each contact is weighted by mode (CW and digital are 2 points, phone is 1) and the power multiplier is applied based on your configured power source. All 18 ARRL bonus categories are built in, including variable-point bonuses like Emergency Power (per transmitter), GOTA (per contact), Youth Participation, and NTS Messages. Some are tracked automatically (like the safety checklist completion or visitor guestbook count), others are claimed manually by the event manager (like media publicity or satellite QSO). Each bonus shows its status (claimed, verified, or unclaimed) so you can see at a glance what points you're leaving on the table.

Yes. Every operator registers with a callsign and gets an account. This is how the system knows who logged what, enforces role-based permissions, and lets operators sign up for schedule slots. The admin or event manager can pre-create accounts, or operators can self-register before the event.

No. The guestbook is open. Visitors sign in with just a name and optionally a callsign. No account, no password. You can hand someone a tablet and they sign themselves in. Licensed hams and general public are tracked separately for bonus point purposes.

FD Commander supports ARRL Field Day and Winter Field Day (run by the Winter Field Day Association). The scoring, bonus categories, exchange format, and Cabrillo export are specific to those events. If you're looking for a general contest logger, this isn't it. Focus is a feature, not a limitation.

More than you'll need. The server uses persistent workers (Laravel Octane on FrankenPHP) and a dedicated WebSocket process (Laravel Reverb) for real-time updates. Even on a Raspberry Pi 4, the stack can handle dozens of simultaneous connections without breaking a sweat. A typical Field Day site runs maybe 5 to 15 stations. That's nowhere near the limit.

It's free and open source under the GPL v3 license. No paid tiers, no "premium" features, no telemetry, no accounts on someone else's server. The code is on GitHub. The catch is that it's maintained by a ham in their spare time, not a company with a support department. File issues on GitHub, and be patient.

K3CPK. Licensed for over 10 years, organizer for several Field Day events, and tired of Field Day software that felt outdated and only ran on one OS. FD Commander grew out of fdlogdb, an earlier Field Day logging tool that proved the concept but hit its limits. FD Commander is the full rebuild with everything that project taught him. It's open source and the code is on GitHub for anyone to fork, contribute to, or audit.

This is a real concern with any self-hosted open-source tool. Mitigate it: test your deployment at home well before the event, do a dry run with your club, keep a backup SD card imaged and ready, and make sure at least one person in the club is comfortable reading a log file. If all else fails, you can always fall back to paper for a while. When the server comes back up, FD Commander has a paper log transcription feature that lets you enter those contacts with the correct timestamps so nothing is lost.