brainwagon

I’ve got quite a bit going on lately, which is why I haven’t been posting all that much. For some reason, I’m back in a bit of a ham radio kick. I noticed that my license had lapsed, and so I renewed and then felt like doing some monitoring of the local repeater action. But really, I’m most interested in digital communications. A mode which has intrigued me for some time is PSK31, a 31.25 baud protocol for keyboard-keyboard transmissions, now gaining quite a following on 20m. Some time ago, I was working on my own code to demodulate the signals (in principle, not that difficult. but with a few subtlties) and am trying to dust it off. In the mean time, here’s a cool applet online to let you know what it is like:

PSK31 Web receiver
To see the picture, you need to get a browser that supports Java. Basically, this is a subset of the 20m band for ham radio. The spectrum is broken into red, green and blue sections. PSK31 signals appear as horizontal lines over time. Below the window, you can select to zoom in on either, the red, green or blue sections, or view all three side by side. If you see a signal, zoom in on the section its in, then position the arrow to the right of it, right in the middle.

Voila. The decode should appear right below.

From the receiver’s position in Kiev, I’ve seen strong signals using twenty to thirty watts from as places as far away as Spain. I’ve seen relatively little DX from the U.S. thusfar, but that might be a timing thing: I’d have to work out when the propagation works out the best. Still, very neat!

[tags]PSK31,Amateur Radio[/tags]

P.S. PSK31 is a nifty protocol, but it suffers from what I feel are a couple of short comings. The most annoying is the variable length character coding they use. Instead of coding 7 bit ASCII directly (say, with a start and stop bit), PSK31 encodes each character as a varying number of bits, each beginning with “1” and up to ten digits long, but with no code patterns that have two adjacent zero bits. Characters are separated by two or more adjacent zero bits. Thus instead of characters being encoded by constant 9 bits, we get a variable encoding of between 3 and 12 bits. It probably does save a tiny bit of bandwidth, because common characters are encoded in less space, but I suspect the savings are minor due to the stilted distribution of characters in your typical QSO. (QSOs aren’t English, which varicode is obviously derived from). But you’ve bought this marginal increase in efficiency at the price of having to create a rather intricate state machine to pack characters. I’m using it as an exercise in programming, dusting off my knowledge of finite automata and trying to write a program which generates the code for the state machine directly from the specification. But (for instance) this added complexity means that you have to work harder, which isn’t bad if you are using a laptop, but might be less than optimal if you are trying to use something like an Atmel AVR to do decoding.

Oh well, just some thoughts.