Friday, November 13, 2009

Software testing on 20m

I have had the K3 listening on 20m since after breakfast this morning to test the new PSK31 propagation spotting capability I have programmed into KComm. I also spent an hour or so around lunch time making some PSK31 contacts. Conditions didn't seem too bad. As you can see from the Propagation Reporter screen grab my PSK31 signals propagated right across North America. Not bad for 40W to a dipole that is bent to fit into a loft space 18ft (6m) wide!

Note that the big balloons are reports from people who spotted me; the small "pins" are stations whose signals I heard.

I would have bet that KG6MZS, the station in California who spotted my signal, was using a beam on a tower. But according to his QRZ.com page, he is using a dipole up at 50 feet. Who needs a beam?

My main aim now with KComm is to fix the little details that only become apparent when actually using the software on the air. I've also been experimenting with parsing received text directly into the log. I got this idea from developing the PSK31 spotter.

In digimodes or CW the word 'DE' is usually followed by the sending station's callsign. If you receive DE xxxxx xxxxx and the xxxxx is the same in both cases, the chances are you have decoded the callsign correctly. This is how I identify calls to spot to the PSK Reporter website. If I receive this on the frequency I am actively listening on then I can put this in the call field in the log as well. This saves valuable seconds in replying to someone if I just catch the end of their CQ call.

The same principle can be used to look for other log fields. When sending their name, people usually send NAME IS xxxxx xxxxx. In this case, NAME is the flag, IS is something that can be discarded if present, and the name is the next word that is sent twice. RST and grid square can be grabbed in the same way.

QTH is a bit more problematic. It can consist of more than one word, for example QTH IS NR CHIPPING SODBURY or QTH IS 30K W OF CARLISLE. Not everyone sends it twice and even if they do they may not send it twice in exactly the same way. So at the moment I can only grab the town if someone sends QTH {IS} {NR} xxxxx where IS and NR are discarded if present. Still, every little helps.

It isn't a huge step from this to developing a robotic QSO maker, though one should not underestimate the brain's ability to figure out what someone's name or QTH is when a few of the characters are garbled. The simple parser I've described falls down quite often as people, being people, can be quite creative in how they send information. But a robotic beacon that people could call using a fixed format to get a confirmation of contact would not be a difficult programming exercise.
Post a Comment