So, a couple of nights ago, I went ahead and assembled the OpenTracker Plus kit that I had ordered from Argent Data Systems. The kit is dead simple to assemble, taking me only about an hour, and I was going fairly slowly, checking each solder joint fairly thoroughly. The kit only uses through hole components, and is very relaxing, even for a big fingered guy like me.

I have got a couple of issues with it though.

One of the more interesting design ‘features’ it has is that it only has a single serial port. This means that you can connect it either to the GPS or to a PC for configuration, but not both simultaneously. This made it somewhat less than completely obvious if it was really functional, at least without wiring up all the cabling you need to attach it to a radio.

The second issue is that it really can only be configured by running a Windows program called otwincfg.exe. I tried running it under wine on my Mac OS X, and while it does startup, it doesn’t seem to handle the serial port properly enough to configure it. I then hooked it to my Linux box, and while the initial connection seemed kind of squiffy, after a few resets, I could get in and conifgure my callsign and the like.

Maybe by the weekend, I’ll get the necessary data cables hooked up for my VX-3R, and it’ll see some service on the air.

Addendum: While digging around, I found my Arduino that I had misplaced, as well as an old Olimex controller board. Each of these boards have pretty much the same hardware capabilities as the Open Tracker, and I think that with some software, a transmit only beacon would be really trivial, and a two way beacon, possible. In digging around, I found some articles from the TAPR/ARRL Digital Communications Conference that would seem to be very useful:

Documentation on the TNC-X website

It’s my usual morning ritual to go back through my WSPR spots and my grabber images, and try to see if anything new shows up. This morning, I had an amazing (and still continuing as of this moment) string of beacon spots into Australia/New Zealand and of course WA2YUN’s station on Wake Island. Heck, I even had a couple of spots into Finland again! Check out the list of spots!

As another sign that propagation was strong, check out these dumps from my grabber of the signal from VK2ZAY. It’s rather common for me to see his FSK CW signal, but rather uncommon for me to be able to make out his SMT identifier. This is far and away the best reception of his beacon that I’ve ever had.

Addendum: Overnight Pierre, ON5SL received this around 06:30, April 10th, and sent it to the Knights mailing list. Pierre is in grid JO10tt, in Belgium. I think this represents the first spot of my visual beacon from Europe.

I’m getting good propagation this evening out to VK land. David, VK6DI runs a grabber, and I started noting that my WSPR beaconw as getting in, so I decided to start sending my “MV” identifier. It’s making it!

David’s grabber will soon be shutting down for his move across Australia, so this may be among the last signals I get from his VK6 grabber. Thanks for all the fun, David.

Check out his nice pictures and description of his beacon and keyer:

iDuino

Addendum: His oscillator/buffer board is a very cheap kit produced by www.vakits.com. It seems like quite a bargain, and could easily be the start of a MEPT project.

Today is a special event day, where those of a WSPR bent move from their 30m haunts to other bands. I’ve shifted operation over to the 40m band, and quickly netted a spot from DH5RAE (my first ever spot from Germany). Who knows that other stations will hear me? Stay tuned.

Update: Wow, had some great overnight spots. Was picked up by German hams DG5VO, DG0OKW, and DH5RAE, my first South American CX2ABP, Japanese station JA5FNX and VK-land hams VK6BN and VK6WS. (VK6WS recorded my band as 80m, but that seems to be a simple mistake). VK6WS would be a new distance record for me, narrowly edging out my previous spot from Antartica, DP1POL.

As part of my tinkering last night, I got the “hamlib” rigctl library compiled and working on my macbook. Now, it’s much easier to change frequencies of operation. In fact, I can do it entirely remotely, and ultimately will be able to shift beacons to alternate between bands and the like.

For the rest of April 8 UTC, I’ll be operating on 17m and see how that works out for me. I’ll then resume normal operations on 30m.

Update²: Here is my updated “spot” map, including last night’s 40m operation.

First of all, starting within the next eight hours or so, my WSPR operations will shift over to 40m for a Wednesday “Special Activity Day” (check out wsprnet.org for details). During that time, my grabber will likely be imaging a part of the 40m spectrum which will likely have little/no activity, so it might not be that interesting. At some point after that, I’ll likely try to shift over to 17m when conditions favor it. The beacon will return to operation on 30m by Thursday, April 9 UTC.

Next, I’d like to note that I’ve had some nice propagation on 30m, including three distinct times where openings to Australia seem possible, and my first spot from Finland, courtesy of OH3QN.

I’ve also added a Cluster Map to find out where people are accessing my grabber from. Here’s the map from today:

Very nice!

Sometimes it’s amazing how people on opposite sides of the world get to working on the same thing. Paolo has been workin on using a simple MP3 player to play back the WSPR tones. He basically is trying to measure and control the time difference in playback so that he gets a cycle time which is exactly two minutes.

Check out his posting:

IK1ZYW Labs: MP3 WSPR.

Addendum: Back in August, 2008, I experimented with using iTunes to send WSPR tones. I was concerned with the long term stabiity of sync, and in the end wrote a program which synchronizes itself with the system clock to send out messages. Had I been clever, I might have thought of taking Paolo’s approach.

I also experimented with using this scheme to send QRSS3. It worked, but uncovered the stability issue that my FT-817 has when it is sending essentially 100% duty cycle.

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?