Format of SOTA Spots - the errant decimal point - SOTA Cluster does not like it

DL4FDM / HB9CSA Fritz said:

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

73 Phil

2 Likes

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.

wunder

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…

How very true…

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.

Some aren’t bright enough to be ridiculous…

2 Likes

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…

Rob

Jon Postel’s Robustness Principle is “Be conservative in what you do, be liberal in what you accept from others.”

wunder

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.

So this will be post No. 30 I believe…

BUT that is not an imperfection; that is custom and practice in mainland Europe.
73,
Rod

1 Like

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.

2 Likes

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.

Not only true for spoting and SOTA, but also in a broader sense…
Heinz

145:400 fm = 0.0

Just seen now…

Colons must be an imperfection unless someone knows better…

Phil

:cry:

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.

I withdraw the comment, but you also misquoted Colin’s suggestion as mine

Whoops! - you’re right, I’ll change that right away - just got up and still groggy…

Thank you.

Credit where credit is due, as they say.

I’ve deleted my post