Love what I see of HAMRS so far as a noob. Tried to search this question up, both here and the QRZ forum, with no obvious results even though it’d seem somebody must have asked before me.
If I talk to someone for example on 28.3725 - which does happen, not usually at my instigation - I get the red flag “Freq outside ITU range”. And if I leave it and select the band with the pulldown option, I get “Band does not match freq”.
Can I leave these values as they are?
Will the frequency still port out accurately to 4 places for an .adi file if I do?
Is there a common practice in the alternative to, for example, round up as a workaround?
Would QRZ then mismatch the frequency for the QSL if I did?
Not sure if it’ll let you complete the entry if it doesn’t see the frequency as valid. You can try, then create an .adif, then use ADIF Master to open the file and see if it took the frequency. If it didn’t you can change it in ADIF master, then upload to QRZ. I know it seems like a lot of work but if it doesn’t happen too often it shouldn’t be too bad.
Appreciate the advice, went kind of in that direction.
Decided to try it like you described despite the red warnings, and it retained the value below. Maybe it’s analogous to the “callsign not found” warnings - you plug in the odd obscure DX sign anyway, and the record will still generate.
I had hesitated because a friend had said that ADIF specified field lengths, which I was worried might then be universal, therefore assumed to be 3 decimal places, therefore possibly truncated, but it seems not.
That individual mentioned ADIF Master also, but I opted to test further down the chain by porting the .adi into QRZ anyway and confirming the records appeared. Not only did they, but the new entries included at least one validated 4-decimal record (though the visible part specifies band only, not freq), so apparently the longer field value did not undermine the association to an existing record.
So the answers to my questions it turns out are (1) yes, (2) yes, (3) not needed for ADIFs, and (4) probably not, but not a concern. I mostly wanted HAMRS so I wouldn’t have to double enter for both a Winter Field Day upload and QRZ, though it’d be nice to activate POTA sometime too . Memo to self, make the PayPal donation.
On the plus side, this thread will now hopefully appear in search results for the next person talking to some 7.xxxx with the same concerns that I had
Also note that QRZ, LoTW, most contests, and presumably other logging systems, do not use the exact frequency to match QSOs. Most use the band instead. So you don’t really need to log to fractions of a kHz.
Interesting. I may still keep noting it for accuracy of record for my own purposes, but good to know it won’t have negative effects.
Out or curiosity, I just used Notepad to open the adi file, and the relevant field for the frequency read “<freq:7>28.3725” - but another with one less decimal read with an extra zero at the end as “<freq:7>28.3800” and a third was “<freq:5>7.230”.
The 7 and the 5 are string lengths for the value following, and I at first guessed the .3800 example was either a norm or an effect of the existence of the value with 4 decimals instead of 3 - but the existence of the third example suggests maybe not, it looks like it’s described case by case, depending on the length for any individual record.
. Memo to self, make the PayPal donation.