brainwagon

Bill, IO/N2CQR over at Solder Smoke blog commented on one of the problems that I had with my WSPR beacon: that it had become “desynchronized” in time, and therefore the network of people who monitor the WSPR frequencies didn’t report any spots from me. Bill would like to minimize the parts count of his beacon transmitter, and the need to carefully synchronize to a particular time makes that difficult.

From my understanding of how the WSPR software works, it basically records searches for the start of a WSPR message beginning at the start of an even numbered minute. The description that K1JT published says that the WSPR message should begin two seconds after the even minutes, but I seem to recall that the W1JT software scans for the beginning anywhere in the first five seconds or so. Thus, if your clock was that accurate, you’d probably get decoded.

I can think of a couple of different ways that we could do that:

1. Use an accurate clock. The problem is that most clock chips accumulate one second of error every few days. Still, it might be possible to use something like a Maxim RTC chip, and periodically readjust it to keep it going. Depending on your needs, this might work quite well.
2. Synchronize using a radio clock. Here in the states WWV signals are pretty easy to read, and you can easilly use the 1PPS signal to keep on track.
3. Use a GPS as a time base. This sounds hideous, and isn’t keeping in Bill’s minimized philosophy, but GPS modules are actually quite cheap.
4. Use a controller which implements NTP or some other time protocol over a network. Again, not the simplest (although can be suprisingly cheap) and requires network access where you are at.

But there is another possibiity: fix the software on the receive end. The truth is that it isn’t all that difficult to detect the WSPR signal no matter where it starts. WSPR sends 162 distinct symbols, half of which are going to come from the synchronization vector. WSPR works pretty hard to find this by running an autocorrelation, but the truth is that with modern computers, finding it no matter what it’s starting position isn’t hard: it just takes more compute power. But its much easier to get that compute power on the receive side (after all, it’s running Windows or Linux or Mac OS on a fast processor in almost every case). Hence, we could detect messages even if they became desynched from these start positions. It would just take a bit more run time.

Bill’s ideal “one transistor” transmitter is kind of extreme, but I think it does make some sense to simplify the transmitters as much as possible. It’s silly to use a $500 computer (or even a $50 junker) when a $2 microcontroller would be sufficient, especially since the microcontroller probably only draws a couple of microamps. Even the simplest microcontroller can act as a good MEPT beacon (heck, Hans didn’t even need one. If we relax the timing info, there is no pressing need to have one for WSPR either.

This suggests to me that it might be reasonable to create a “son of WSPR” format that uses some of WSPR’s good ideas, but relaxes the need for timing synchronization. I have a couple of other ideas regarding the error correcting codes and the like, and it would be nice to have some flexibility in the message format that would allow sending different bits of information (yes, WSPR has a QSO mode, but I’m thinking of informational messages more in line with the needs of a beacon propagation network). Is it time to work on such a thing? What do you all think?