Hi Phil, I am not sure if I understood you correctly, but when I am spotting on SOTAwatch, there is no possibility to spot 7033.1, you have to make it with the point like 7.033.1 for example. Have a nice Sunday. Fritz HB9CSA/DL4FDM
HI Fritz
Leave out the second decimal and send 7.0331 and there is no problem. If you add the extra dot the cluster reads the frequency as 0.0
How about the parser ignoring any punctuation after the first decimal point?
It seems like the cause is the silly radio displays, not wilfully stupid operators. I never noticed it until now, but the KX3 also does the double-decimal thing.
In a recent related thread Andy posted âOnly one dot or you donât get a spotâ !
I thought that was ridiculous. Anyone who has a clue what a decimal point represents would NEVER use two. I donât care what some radio manufacturer thought was most expedient.
Well, it seems people actually are ridiculous, and then they expect computers to think for them so they donât have to.
As far as rejecting or accepting incorrectly formatted frequencies, it makes no difference to me. I donât own a âsmartâ phone, so the only way I know a spot went up is that I start making contacts. if nobody comes back, I look at a copy of the SMS text I just sent. If I see a problem, I send it again correctly. Learn how to use your tools just like you learned how to use your radioâŚ
No Iâm not. We all passed an exam to get our licences, therefore we should all know what represents a valid Amateur Radio frequency. There is enough âdumbing downâ of stuff on the Internet without us adding more in what is supposed to be a technical hobby about âself training in the use of radioâ.
And before you spout a lot of nonsense about how computers should do things - remember computers are a tool to help humans. I spent all my working life programming computers for human safety critical applications - I do know what Iâm talking about.
Of course youâre right - we all should, and indeed do, know this. But people, including our good selves, occasionally make mistakes when entering data into computers or smartphones or whatever. No amount of knowledge can make up for this basic fact about people: to err is human, etc. And, as others have pointed out, when a SOTA activist is on a cold, wind-swept hill and trying to tap characters into a smartphone with cold fingers, even more opportunities for errors present themselves. There are also those who type such things as â7.033.1â into an entry field because theyâve seen that others have done the same; or maybe theyâre unsure as to what exactly should be entered into the appropriate field (VERY few people read the help or popup hints!), or perhaps they think that â7.033.1â is a really cool way of expressing a frequency, or⌠and so on.
As you must surely know, programming is not just about writing a set of processes which react correctly when a button is pressed, or writes successfully to a database, or looks nice on the screen; itâs also about the interaction between the processes and a person. A good programmer should understand right from the start when writing a program that âbadâ data can and will be input by a user of the program, and that he/she should ensure that sufficient measures are taken in the code, or hints/error messages/help systems given to the user, to minimize the eventual propagation of such errors into a back-end system. A program which is written to accept any and all human-input data without demur is a poorly-written program.
So, a little understanding - psychology if you will - of âthe userâ is required by a programmer, in addition to the purely mechanical/technical knowledge required to create the nuts and bolts of a program destined to be used by us hapless, error-prone bipeds.
Well, I am prone to spout all kinds of things, nonsense included, so you might consider wearing a heavy raincoat and souâwester when conversing with meâŚ
To be fair, that principle is not universally accepted as being a good thing. It can cause a lot of trouble. Each case needs to be looked at on its merits.
Iâm sorry my thread was blown up out of all proportion! Is this due to winter weather cabin fever amongst chasers / activators or pure pendancy I wondered. I just want the spots to simply appear on the MM0FMF cluster as a frequency. The best way is for users just to use the single decimal point in the right place, simple as that. No need to over complicate matters guys!
Just to note that the frequency sent as 7,158 ssb by IN3EBZ just now (note the comma) came out on the cluster perfectly. So the cluster will recognise some imperfections but not others.
Your thread has a lot of validity though Phil. It will crystalise some people into better spotting.
We could tighten the processing on SOTAwatch but a lot of spots would get rejected. They may be invalid from being considered a valid frequency but are immediately understandable from a human view. Given time people would learn to enter sensible data. But I donât want to be the person who doesnât get spotted when the weatherâs bad as people learn they have to type a valid number.
I could enhance my parser but frankly I got bored. Every time I thought I had something which was fool proof another fool would come along and prove me wrong. Thatâs the problem with fools, theyâre so ingenious! So I handle the simple things and to hell with the ingeniously wrong numbers.
Perhaps you could automatically send the spotter an email when you detect a badly formatted spot pointing out their error and suggesting that in the future such spots might get rejected.
This thread prompted me to check what I had done with my APRS2SOTA system.
APRS2SOTA will try to send an error message back when it does not find a valid frequency in the information it received.
APRS2SOTA expects the frequency to be a decimal number consisting of a number with up to 6 digits before and at most 7 places after the decimal - that should cover most bands (I doubt anyone would really want to give the Frequency for a Microwave band contact in kHz) - only one decimal point is allowed and no commaâs are allowed.
Unless the units (kHz, MHz, GHz) are included (without any spaces after the numbers) it tries to decide itself from the value given if the frequency is in kHz, MHz or GHz - clearly there are some limits to how well this works as some numbers could be valid for two (or more bands) - i.e. 10.101 could be 10.101MHz or 10.101 GHz (it should assume itâs 10.101 MHz as that is the one checked first).
The Frequency is then formatted to MHz with at most 5 decimal places being shown for posting to Sotawatch.