I enter nominal frequencies of operation rather than just band for my own log completeness (e.g. 14320 and auto-ID 20m band). When exporting a log I copied from POTA to SOTA templates, the resulting .ADI resulted in an upload to SOTA showing everything as “band: microwave”. Going back through the .ADI and adding a period to freq:5 so they’re all in MHz rather than kHZ resulted in the upload working correctly.
Is this an issue with copying the log, the template/export, my data entry, or something else?
I think data entry? I could be wrong, or misreading what you’re saying. HAMRS expects (but does not enforce) MHZ, and will populate the band for your accordingly. Does SOTA also want frequencies in MHZ or KHZ?
SOTA wants MHz, as I presume is standardized by ADIF. While I think the prior feature suggestion to accept kHz and calculate band correctly when unambiguous is handy (I obviously used it), not converting a detected kHz entry into the correct units for the ADIF is additionally confusing (I ran into this problem).
It would help to, say, change the units indicator to a red kHz with the tooltip like “this frequency has been detected as a valid amateur frequency in kHz, however this value will be exported without conversion and will not match the ADIF standard when checking against the Band field” would help avoid this outcome. Either that, or have MHz/kHz entry be detected and flagged in the database so that only MHz will be exported in the ADIF.
Then, I suppose, I will amend this report: entering a valid frequency in kHz should not correctly be translated to the band or such a frequency should set the frequency field units to kHz when detected. Since I hand-log in kHz and entering a kHz value in the MHz field selected the correct band for me, I presumed this was being handled correctly.
The frequency and band don’t match if a frequency is accidentally entered in kHz. Example is attached. 7225 MHz is actually approx 4 cm. But HAMRS chooses 40 m which creates a disconnect for other logging apps and services, and the HAMRS user isn’t warned of the error. The user made a mistake, but so does HAMRS when it converts the illegitimate frequency to the incorrect band.
A cross-check to protect the user from their own mistakes might again be useful here. Several other HAMRS users have reported confusion when their logs were rejected by LoTW, only to discover later that they, too, didn’t enter the frequency in MHz.
@jarrett, here’s a recommendation: If the frequency (accurately entered in MHz) falls anywhere within the ITU frequency allocation range (Wikipedia has a good list, or you can use those published by the ITU – just remember to include the full range for all regions for max flexibility), HAMRS could choose the appropriate band. If it doesn’t, flag it as an error. Technically the band is undefined.
Another enhancement, which could be done in parallel, would be to allow the user to toggle between entering the frequency in kHz or in MHz. Tap the label and it would change. You would obviously have to convert it to MHz to match against the ITU band listing.
Here’s a screen shot depicting selection of the wrong band:
I would greatly appreciate having the Frequency field units be toggle-able, as would the other requester for kHz.
For reference, it appears that POTA and LOTW both ignore the (wildly) incorrect Frequency field in preference for the Band field. POTA doesn’t need it and LOTW simply clears the incorrect Frequency. SOTA presumably accepts Band, but does a conversion from Frequency to Band when the Frequency is provided.
In addition, testing again, this seems to “look correct” entering kHz rather than MHz because the Band field only auto-updates when a valid MHz frequency is entered. So you get:
“7” → “40m”
“7123” → [no change, stays 40m]
Similarly up a couple bands:
“1” → [no change from last entry]
“14” → “20m”
“14234” → [no change, stays 20m]
“146” → “2m”
“146520” → [no change, stays 2m]
In these cases, and just as a general improvement, have a “null band” and generally filling “microwave” above the 23 cm band would cut back on missing that the frequency field is technically invalid.
@trm@jarrett To be clear, this isn’t entirely correct though. The band isn’t always converted to its correct kHz equivalent.
Try entering 7025 kHz (gives 4m, which would actually be a UK band of 70 MHz) or 5332 (gives 6m, e.g. 53 MHz). Likewise, 1800 assumes 17m and not 160m. The conversion is ignoring length and trailing zeros. It appears to be parsing the string left-to-right until it finds a match.
It would be easier, IMHO, to convert to a float and compare to a numeric range instead to (1) validate the frequency in the chosen units and (2) convert to the correct band.
This check would also need to be accomplished when copying QSOs from the POTA spotting page. POTA.app does no range validation at all and it asks for frequencies to be entered in kHz. However, it seems to be pretty common for spotters to enter half kHz increments without the decimal. 14.0455 MHz, aka 14045.5 kHz, sometimes gets posted as 140455 kHz. As we know, that is close to the 2m band but not a ham frequency. Filtering the spots by the 20m band will rightfully exclude that spot.
Indeed. Optimally would be selection of kHz/MHz → float → store as MHz → compare against a known band range list. That would cover all the cases.
I also cherry-picked the common bands that create these false responses. Your examples are correct in failing to identify some other bands’ prefix frequencies and either identifying something different down the line or just staying stuck.
Validating other data. . . well, oof, always a problem. If hunting P2P, that might be a case of copying the band and highlighting the frequency field (in red?) to cue the operator to find the spotted station and then enter the correct frequency from their rig.
So looking into this last night, there was a definitely a bug that, if the frequency input received null back from the function I wrote to covert a frequency to a band, it wouldn’t update the band field, and would leave the last known band in there. That’s been fixed, and will come out soon.
As far as entering Kilohertz goes, it’s possible to allow you to toggle khz/mhz. My concern is the converting back and forth - the ADIF schema, which is the underlying schema I use in HAMRS, requires MHz - I could allow you to store whatever you want, and when exporting make sure everything is converted to Mhz.
Basically what I need to write is the following:
Allow users to choose between kHz and MHz
Persist that choice
Ensure that the automatic band function works with kHz
When exporting, detect non-float frequencies and convert them to MHz to ensure a valid ADIF file
To keep the internal representation consistent, I think users getting to choose if the Frequency field displays as kHz is a fine setting. Then it’s just a matter of *1000 or /1000 to move data in/out of the field in kHz mode and all data for band detection, internal database, and ADIF export are valid MHz all the time.
@jarrett, I think that would do it. However, if your coding structure allows it, I would always recommend storing the frequency in MHz, and if the user toggles to kHz, convert it immediately and display that frequency field in kHz. But the data stored in the database would still be saved in MHz.
So if the user enters 7.045 MHz and then presses the button to convert to kHz, the displayed frequency in that field would immediately be shown as 7045. Toggle it back and it would revert to 7.045. But 7.045 is what is stored.
My rationale for suggesting this approach is simply to account for the possibility that the user may enter one QSO in MHz and another in kHz. (Why they would want to do so is beyond me, but guaranteed some will do it…). Toggling the units should display and validate the frequency in those units for every subsequent QSO and when editing all prior QSOs, but if you save the frequency selection as a single unit intended to apply to the entire log, your ADIF export would be wrong.
There are two ways around that: Either (1) do what I propose above and always store in MHz and convert real-time for display/editing/validation when units are toggled, or (2) associate the units selection with every single QSO. The latter would require your ADIF export to check and convert each QSO record individually based on the associated units.
Personally, I think the primary near-term need that should be addressed is to restrict frequency entry to ones that are valid ham frequencies in MHz and to convert them properly to the correct band. Adding a toggle between units might take a bit longer to flesh out.
ADDED: Just saw @trm’s suggestion above. I think we are both making the same recommendation. I would add an ITU frequency validation to your band conversion as well.
Correct. Error check (protect the users from themselves!) IMHO should be the first priority, followed by adding ease-of-use feature to permit toggling between units.
The 1.0.4 behavior looks good and will keep ol’ kHz me from messing up future logs with the correct band and 1000x the frequency! Now just to let it get through G-Play.
