One of the Knights mentioned that Bill was now visible on WSPR. Presumably, this means his DSB beacon is actually alive. Here’s a link to his spots as reported on the WSPR net. Not bad!
I’ve been poking half-heartedly at Milhouse, my checkers program this morning. I found that a particular puzzle (puzzle 34) that I got from a puzzle book seems to behave so oddly that I must believe that there is some underlying bug in my program.
But rather than dwell on that, I found a link to a collection of papers by Bob Hyatt, including one on parallel search, a topic which is much less completely covered in available literature. Bookmarking this for later.
Addendum: I finally added a nice screen dumping capability to my program, so I can leave some nice graphics for positions, rather than the text-only versions I had before. Here’s the troublesome position, with red to move. Chinook sees it as a win. I think 5-1 is the right move. I need to think on this some more.
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:
A year ago, I blogged that I had dusted off my old checkers program, named Milhouse, and had uncovered a bug in my transposition tables. Today, a year later, I still haven’t debugged it entirely. I tried adding routines to access the Chinook endgame database files to it, but it’s not quite there yet: it seems to go seriously astray in certain positions. I’ve got a few goals in this project which are as yet unrealized:
- Make the endgame stuff work.
- Tune the evaluation function.
- Develop a program to generate a good opening book.
- Make a nice interface for it, and release it to the universe.
Doubt I’ll get to any of this today.
Addendum: It can solve some pretty tricky checkers problems. This position seems unobvious to checkers novices like myself. White is to move and win:
LOADED puzzle 101: Rob Pike, Puzzle #28. Color is set to white. White +--------+ | W - - R| |- - r r | | - - - w| |r r - - | | - - R -| |- - r r | | W - - W| |- - r - | +--------+ Red
On the other hand, puzzles like this one remain elusive. The chinook database reports that this position is a win for red, but it’s pretty difficult. It takes milhouse a 22 ply search to identify the path which leads to a strong advantage. Ironically, I find this position fairly easy to guess the right answer. Red has both white men pinned, and it seems releasing those pins would probably not be a good idea. This leaves the red man at 15 as a possible mover. You could move to 19, and force the white king to give way, and then march down the side to get kinged, but what’s less obvious is that you can then drive the white king to the single corner where it too can be pinned. Of course, I’m a checkers idiot, so what do I know. The winning line appears to be to force an exchange of the checker originally at 15 for the white king, and then capture the white checker originally at 12 which gets pinned in the corner. Then you have a classic 2:1 king endgame.
LOADED puzzle 85: 2nd position, easy, from The Checker Maven. Color is set to red. White +--------+ | - - - -| |W - - - | | - - - -| |- - - - | | - r - w| |w R - - | | - - R -| |- - - - | +--------+ Red
And I thought I was nerdy for having the Dr. Who theme be my ringtone…
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.
This is just an interesting little aside. Over the past couple of days, construction of the new building here at Pixar Animation Studios has begun in earnest, which means that we have pile drivers operating a couple hundred feet from my office. Strangely, my office appears to be very close to a resonant node for the building, and my monitors were shaking back and forth. Bleh.
One of my fellow Pixarians decided to put here iPhone to a good use, by recording the ground shaking. Check it out.
April 9th is Tom Lehrer’s birthday.
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.
Update2: 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.
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:
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:
- 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.
- 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.
- 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.
- 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?