Implement field day support

[johnsonm]

Implements #19

I have tried to implement a Field Day mode that follows the existing patterns. I have tested it on Firefox and Chromium on Linux, and on Firefox and Chrome on Android. I have deployed a version for others to use to prepare for Field Day as well as to test for this PR.

I'm happy to take feedback.

[johnsonm]

Mashing state and section together was bad. I just added section and class as two new UI fields in the latest version. Note the use of klass internally is necessary because of class being a reserved word. An alternative would be to call it fdclass or something like that.

After uncommenting the debugging log to make sure that my code copy is correct, I can confirm that the exchange follows the pattern that I have been told is common for field day. (I'm a new ham trying to prepare for my first field day, which is why implementing this became urgent for me. ☺)

[johnsonm]

Added the missing line to the README in the last push. I am willing to improve this more if needed, but believe that it is otherwise ready to merge.

[johnsonm]

The most recent push stopped double-sending the local call sign in the exchange.

I have a build posted using github pages at https://johnsonm.github.io/morsewalker/ so folks can try this out easily before such time as you are comfortable merging, as Field Day is getting close. ☺

If you like @jhollowe 's suggestions for weights, it might make sense to implement selections from weighted lists, so that for any list in stationGenerator.js you can list tuples of (value, weight) where the weights affect how likely each entry is to be chosen. But that would probably be useful beyond Field Day, and I wanted to keep this simple for now.

[ny4i]

Nice work!

Sorry but I could not finmd a place to comment about this version. I tested it and there is one thing that seems strange in the random section selection. Non-VE stations will send Canadian sections like ONN. I know it should be just copy what you hear but it did cause me to think a bit as inevitably one has an expectation.

I also wonder if the class and section could be combined into one dialog and have the parser figure it out.

Lastly, I did notice that on some calls, when I hit enter after sending it, nothing happens. I had to hit the Send button. The call was correct in the call box.

I post here just in case you have any thoughts on the Field Day PR. If there is an issue tracker for your version, I can post this there too. But I did not see one on your fork (maybe that is not a thing and I am mis-remembering).

[johnsonm]

I post here just in case you have any thoughts on the Field Day PR. If there is an issue tracker for your version, I can post this there too. But I did not see one on your fork (maybe that is not a thing and I am mis-remembering).

This is exactly the perfect place to comment on my PR. Thank you! The only reason I'm running a separate deployment is to enable testing and drill for this year's Field Day, until such time as Henry is comfortable accepting this PR, or implements an equivalent he likes better than my code.

I also wonder if the class and section could be combined into one dialog and have the parser figure it out.

You mean when copying? All things are possible, but I was trying to follow the upstream pattern and be as close to W6NYC's design as much as I could, and it looked like keeping them separate was more aligned.

What would make you want them together? (Real question, not rhetorical!)

Lastly, I did notice that on some calls, when I hit enter after sending it, nothing happens. I had to hit the Send button. The call was correct in the call box.

This won't be specific to my branch, which doesn't touch that code.

It is possible that you are sending before Morse Walker counts the other side's transmission as done. If that's not the case, please see whether you can reproduce this in one of the existing modes at https://morsewalker.com and file a separate bug report for W6NYC — this is outside my area of expertise, to be completely honest.

I tested it and there is one thing that seems strange in the random section selection. Non-VE stations will send Canadian sections like ONN. I know it should be just copy what you hear but it did cause me to think a bit as inevitably one has an expectation.

Yeah, I get the same jolt when I'm drilling QSOs in IZ2UUF on my phone and copy WX SNOWY TEMP 38C or WX RAINY TEMP 3F or MY QTH 30MILES SE PARIS FRANCE = MY PWR 1K = MY RIG BOATANCHOR = MY ANT DOUBLET = SOTA HBO/LI-012

This is like @jhollowe's comment about unrealistic class numbers, which is equally legit.

There could be lots of logic more generally around, for example, making the US call signs more likely to have an area number appropriate for their state, weighting the states by approximate number of real hams in that state, weighting the names by frequency of licensed hams with that name, expanding the list of names based on lists of names of actual hams, etc. But I think that adding that complexity to station generation should probably be considered separately from basic Field Day support.

[johnsonm]

Ugh. Unlike the US, Canada still enforces area, so to get section corresponding to canadian call sign would require mapping all the ARRL sections to area numbers.

I'm not going to try to get that right, but I can at least align call signs and sections by country. And I can produce all the Canadian prefixes, at least for Field Day.

I realized that there is already a nice function for weighted collections, so I'm going to bias toward class A, and a bit more D. The weights can be adjusted; I am just guessing for initial values. I also realized that I missed generating class AB and BB responding stations, so fixed that too.

And I spent enough time copying large numbers while testing that I'm trying a simple power function to make lower numbers more common.

[johnsonm]

Now updated to support DX stations as well. Assumes that Canada will have an outsized representation, though, in the ARRL/RAC Field Day.

[johnsonm]

I've been thinking about potential enhancements.

I think that I could tweak the US/CA/DX balance for a slightly more accurate representation of this primarily US/CA activity. Probably 80% US, 15% CA, 5% anywhere. The goal wouldn't be to be perfectly representative.

I might want to make the exchanges a bit less formulaic, to better represent actual traffic.

Instead of always starting their exchange with R, sometimes send RR or QSL and sometimes leave out the acknowledgement.

Instead of always ending their exchange with TU, also sometimes leave it out, or send TNX, GL, 73, or 72.

[johnsonm]

I have now learned that the B battery modifier for classes A and B is not sent over the air, so I have removed them from the responses.

[johnsonm]

@sc0tfree I haven't gotten any more feedback about necessary changes since the most recent changes. I think this is ready for your review. I'm happy to squash if you'd like.

[ny4i]

I like the changes and additions. It makes it a nice tool which I'll be hitting more this next week.

[johnsonm]

@sc0tfree, Now that I have actually worked CW on Field Day, I would love a conversation about future plans.

if you are interested in merging this, then your preferences regarding complexity are most important.

If you decide you want to take a different route to supporting field day, that won't hurt me any.

I could add more variation to the simulation, like making the hunting station repeat the calling station's call as another variation on R/QSL before the hunting station's class and section.

It would be valuable for real experience to support asking for repeats of the exchange information. Is that something you think of as out of scope? I assume that if you wanted it at all, you'd want it to be implemented in a general way that would apply to other simulations like POTA as well. It would start to exceed the reasonable change in a single PR, probably.

Similarly, and much larger implementation effort, for each type of operation, it would be useful to be able to work the hunting direction as well. Since a new operator will usually start with hunting, it would be a great way to learn how to hunt.

Anyway, I'd value a conversation about your intentions regarding this work and possible expansions.

[johnsonm]

I'll note that with the ARRL finally having gotten around to releasing this year's rules, there are no changes to the rules or to the sections for 2026, so no changes are required to the simulation either.

[ny4i]

I had fun going in a slightly different way with this for Field Day. Since the ARRL publishes the results from 2025 (and other years) in a CSV file, I added code to read that data file and use it as a source of calls. You can even tell it to only use stations that made CW contacts last year (again based on the CSV results file).

This made the sections and classes much more realistic with the callsigns since they are from the actual past event logs.

I also added support for a single exchange field as that emulates our club's contest logger (TR4W). All of those changes are options.

It is all in my fork at @ny4i

[johnsonm]

This made the sections and classes much more realistic with the callsigns since they are from the actual past event logs.

I really like the idea of loading real calls. That's been the most frequent complaint against my version. I want to make use of that.

I also added support for a single exchange field as that emulates our club's contest logger (TR4W). All of those changes are options.

I think it would be possible to make class work as "class plus section" without having to have UI to select it. Type both into the first box, or separate them, depending on which logger you want to emulate.

It is all in my fork at @ny4i

It looks like you started from my work (I recognize some of that code) but just copied rather than actually forking from my work, which will make it non-trivial to merge any of your work into mine.

Also, you added a CLAUDE.md file folded into the commits instead of as a separate commit, too. I don't know whether @sc0tfree intends to come back to this project, but I do think that a CLAUDE.md file should be a separate PR that he can consider separately.

Therefore, I think I'll feel free to plunder from your branch (thank you!) as I think you did from mine, but not merge your commits into mine. (If you didn't intentionally plunder, maybe claude did it on your behalf... 😁) I'll plan to credit you in the commit history somehow.

[ny4i]

Hi.The intention was to give the original projects whatever they wanted. I didn't realize by severing the upstream I made that challenging. I can certainly add that as its own PR to the origin project.

[ny4i]

Oh and yes the Claude.md should not have been there. It might make sense to just cherry-pick what you need.

I do believe two exchange fields that can take both class and section would be visually confusing. Hence the option. But go with what works for you.

I'm getting great use out of it this week to practice.

[ny4i]

Oh and I show my repo as a fork of yours. I severed the origin as to not do PRs but this is definitely based on your fork.

[johnsonm]

@ny4i I am sorry, I think I misunderstood what I saw the github UI — I should have looked more closely before responding. My fault! I'm sorry! I thought it was showing me your work relative to @sc0tfree's work. (I use github more or less every day at work, but we don't work in forked repositories, so what I see day to day is a little different.)

I'll still cherry-pick given CLAUDE.md.

I've seen a few loggers that have separate boxes, but also will just parse what you enter normally correctly, a la TR. I'll think more about the exchange encoding.

[ny4i]

No worries. The code I committed handles the class and section in either order as that's what TR4W does.

I will get the Claude.md out of there.

Tom