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.