Monthly Archives: January 2008

Grump! AO-51 down, command team on it.

Sigh. I was gonna work AO-51 this morning, but couldn’t hear the downlink. I shifted to the digital downlink frequency, and could hear it was active. It appears the satellite is temporarily off line. From the amsat-bb mailing list:

AO-51 stopped transmitting and went into Boot Loader mode. The command team has reset the satellite and have the digital downlink up and running.

We will reload the satellite as quickly as possible.

73,
Gould, WA4SXM
AO-51 Command Team

Best of luck getting it back online, lads!

Bay Area Modern Geek Ham Radio Meetup

Alex Perez, KD7OFR, sent a message to the AMSAT mailing list, basically asking “where are all the hams, and why aren’t we doing more to attract new, particularly younger hams into amateur radio?”

Great questions. I wish I had a great answer. The grumpier hams would claim that kids today are just too lazy, with their cell phones and their video games and their rap music! But that’s too easy. I think something somewhat more subtle is going on.

If you were a ham licensed in the 1930s, you were literally on the cutting edge of technology, using something which really was viewed as completely magical just a few years before. If you were licensed in the 1940’s, you were probably doing your part in the war effort, and developing a skill which could be used in service of your country. In the 1950’s, there was a civil defense angle. In the 1960’s, the Cold War. But by the time the 1970’s rolled around, the need for a citizenry trained in radio operation simply began to evaporate. By the 1980’s, the microcomputer revolution was underway, and many of the talented young people (myself among them) spent their time learning about computers. By the late 90s, cell phones were ubuiquitous, the Internet provided 24/7 broadband data access and the need to use ham radio to communicate largely evaporated.

By my way of thinking, if we are to promote ham radio, it ultimately can’t just be about communicating with people. After all, most young people have access to technology (cheap technology at that) which allows them to do that, with much greater reliability and ease than we can ever hope to provide on the amateur frequencies. What then, can we offer?

I think a lot. First of all, a ham radio license is a license for radio experimentation and exploration. Some would say that it is quite an achievement to get an Extra class radio license (and it is), but what we learn after getting our licenses is vastly more important than what we learn before. As hams, we are allowed to design, build and use our own radios, on frequencies dedicated for our own use. By doing so, we can not only communicate with other hams but experiment to learn about radio, our earth, the atmosphere, and even outer space. And there’s a lot to learn.

Since last October, I’ve built an HF receiver, and used it to pick up RTTY from the Galapagos. I’ve learned how to track satellites by hand, and communicated with hams from Hawaii to North Carolina, from Manitoba to the Island of Socoro, using only 5 watts of power and AO-51. I’ve programmed my own weather satellite decoder. I’m having a blast, not just for what I’ve done (which frankly, tons of others have done before) but what I have learned along the way.

Anyway, enough of that.

Alex has set up a group on meetup.com for the Bay Area. this Friday is there first meeting. I’m gonna try to make it, if only for an hour (I have a conflict), and I urge any other hams who might be reading my blog and are in the Oakland area to stop in.

73s.

Non-hams making poor use of AO-51

Well, it was a scheduled 88 degree high pass for me today on AO-51, so I was out there with my Arrow again. For the second time in a week, I’ve ended up calling CQ on the satellite because nobody was talking. That finally scared of regular WA8SME (thanks Mark) and I got Gerry, KB7F again, although I appeared to lose him before I got confirmation. Oh well. Toward the tail of the pass, my contact with WA6JE was kind of spoiled by all sorts of odd noise in Spanish. My guess is that they are some business, illegally operating on the 2m band on the uplink frequency.

Spanish Speakers on the Satellite, probably inadvertently…Check it out.

Addendum: I designed my first QSL card using the Apple Pages word processor. Here’s the one I sent Gerry via email:

First QSL card going out to Gerry

I haven’t figured out how I’m going to get real cards printed yet (probably economically to have them professionally printed), so for now, I’ll be sending them out via email.

Addendum2: Wow, that looked incredibly ugly. I redid the conversion to make it look a little better.

Better version…

FeldHell encoder…

I’ve been pondering the amateur mode known as FeldHell or Hellschrieber. It’s a very old mode, dating back to a patent in 1929. I’ll let Randy, K7AGE explain it with a demo on youtube:

For fun, I sat down and wrote and encoder for it. It tries to be really good about bandwidth, I haven’t checked it out yet for that, but it sounds relatively unclicky at the moment. Here’s an example mp3 file of a FeldHell transmission. Perhaps later I’ll get the time to write up why I think FeldHell is interesting.

Addendum: It seems to mostly work, although I might have a timing issue, and I’m uncertain as to how good the filtering is. I played it back into gMFSK which has a feld decoder, and the images come out significantly slanted. There are variants of FeldHell which run a bit slower, maybe that’s the issue. I’ll have to ponder it more. I adjusted the timing in the recording, added some gaussian noise, and got the following image:

My Feldhell Modulation decoding inside gMFSK

Addendum2: I discovered an error in the code that I put in to add Gaussian noise (embarrassing). It tended to add in considerable low frequency power. Not sure what overall effect it will have on the signal, but it sure made the spectrum look funny. I think the pulse shaping is reasonably correct.

Addendum3: As some evidence that my program works… here’s the power spectrum of the message above, with the improvement in the gaussian noise generator.

Audio Spectrum of my Feld Hell Encoder in the Presence of AWGN

Extreme Homebrew Electronics

Every once in a while, I encounter one of those odd hams who likes to homebrew his own electronics, but who views using integrated circuits as “cheating”. He’ll assure you that you can’t possibly understand how radios work if you use integrated circuits: that real homebrew radios are constructed from simple transistors. Or maybe even more perversely, he’ll assure you that all “real” radios are constructed from parts that glow, and that they will be the only technology that survives the EMP burst of the the nuclear bombs that that Soviets Russians North Koreans Iraqis the Axis of Evil are set to send against the United States.

I think this is hilarious. I mean, with the exception of one person I know (and she’s insane 🙂 ) nobody is capable of making a transistor anymore than they are capable of making an integrated circuit. Objecting to their use on a basis of some kind of “electronic purity code” is just silly.

But anyway, enough of that. Here’s a website about a French guy who makes his own tubes. From wire, glass tubing and pieces of metal. And apparently builds radios out of them. The number of steps he needs to go through to assemble a tube is just amazing. He’s got all these crazy jigs and torches and tools and vacuum pumps. Just freaking amazing. Check out the 17 minute video (very expertly done, and with no voice, just some soothing music). It’s just crazy.

French guy makes his own tubes, by hand.

Sines and Cosines of the Times….

I can never remember these formulas, so I wrote this program. I’m putting it here so I won’t lose it, and so others may benefit.

#include <stdio.h>
#include <stdlib.h>
#include <math.h>

/* $Id$
 *
 * Written by Mark VandeWettering.
 *
 * Any copyright would be pretty stupid.  Use this code as you see
 * fit, for any purpose, commercial or non-commercial, with or
 * without attribution.
 *
 * I wrote this little test program mostly as documentation for some
 * interesting recurrence relationships which I keep forgetting and
 * have to dig up from time to time.
 *
 * To generate a continuous tone, you basically are repeatedly
 * evaluating sin(n * ang), for n = 0... however many you need (or,
 * alternatively, cos).  Writing the loop in this naive way is pretty
 * horrible though, it takes many cycles to evaluate a sine or cosine.
 * Another way to do so is to compute the complex number m = cos(i *
 * ang) (where i is the sqrt(-1)) and then maintain an accumulator which
 * is repeatedly multiplied by m.  Unfortunately, eventually numerical
 * roundoff makes the resulting vector diverge.
 *
 * Luckily, there is a third option: to use a recurrence relationship
 * for cos(n * ang) and sin(n * ang).
 *
 * From section 5.4 of Numerical Recipes: The Art of Scientific Computing:
 *
 * cos(n*ang) = 2 cos(ang) cos((n-1) * ang) - cos((n-2)*ang)
 * sin(n*ang) = 2 cos(ang) sin((n-1) * ang) - sin((n-2)*ang)
 *
 * Somewhat amazingly, these recurrence relationships are _incredibly_
 * stable.  The program below implements both of them (generating a
 * sin and a cosine in each iteration) using only two multiplies and
 * two adds per iteration.  On the 3.4Ghz Intel machine I have, this
 * entire program runs in about 11 seconds, and the vectors traced
 * out by the program are still unit vectors to the precision of
 * a normal printf.  You can try replacing the "doubles", with "floats",
 * and you will see the precision isn't as good, but might be adequate
 * for your needs.  It should be noted, however, that the program runs
 * in exactly the same time in either case (doubles and floats are both
 * single cycle operations) with my machine/compiler.
 */

/* This test program runs for a billion cycles, which at the sample rate
 * specified is just about a full day.  The idea here is to see if the
 * generated sines and * cosines continue to trace out unit vectors. */

#define NCYCLES         1000000000
#define SAMPLE_RATE     11025
#define FREQ            (800.0)

main()
{
    double ang = 2.0 * M_PI * FREQ / SAMPLE_RATE ;
    double c0, c1, c2 ;
    double s0, s1, s2 ;
    double cm =  2.0 * cos(ang) ;
    int i ;

    c0 = cos(-2.0 * ang) ;
    c1 = cos(-1.0 * ang) ;

    s0 = sin(-2.0 * ang) ;
    s1 = sin(-1.0 * ang) ;

    for (i=0; i<NCYCLES; i++) {
            c2 = cm * c1 - c0 ; /* c2 is cos(i * ang) ; */
            s2 = cm * s1 - s0 ; /* s2 is sin(i * ang) ; */
            c0 = c1 ;
            c1 = c2 ;
            s0 = s1 ;
            s1 = s2 ;
    }

    for (i=0; i<100; i++) {
            c2 = cm * c1 - c0 ; /* c2 is cos(i * ang) ; */
            s2 = cm * s1 - s0 ; /* s2 is sin(i * ang) ; */
            printf("%f %f %f\n", s2, c2, s2*s2+c2*c2) ;
            c0 = c1 ;
            c1 = c2 ;
            s0 = s1 ;
            s1 = s2 ;
    }
}

/* $Log$ */


Addendum: Jim Blinn has a chapter on circle drawing in his book, JIm Blinn’s Corner which is probably relevent. It’s been some time since I read it (and I can’t find it on my shelf at the moment), but I believe it also points you to Minksy’s circle drawing algorithm that appeared in HAKMEM. It’s clever, but doesn’t really draw circles, and is no faster than the method above. What’s really odd is that it uses less storage for temporaries, which makes it look as if it were buggy.

Addendum2: Well, I coded that program up, just for fun. It turns out that you can use it as well. Gosper explains how to compute the desired value of epsilon in the Minsky’s algorithm, and unlike the code above, it is stable when evaluated using floating point arithmetic. Unfortunately, it generates a fairly notable ellipse, which doesn’t change over repeated evaluation, but isn’t very round either. As the speed the points go around the curve decrease, the curve becomes more circular.

Still, pretty interesting.

#include <stdio.h>
#include <stdlib.h>
#include <math.h>

/*
 * According to Gosper, Item 151 in HAKMEM,
 * 1-epsilon^2/2 = cos(theta), where theta
 * is the desired angular increment.
 * This means that...
 * 1 - cos(theta) = epsilon^2 / 2
 * epsilon = sqrt(2.0 * (1-cos(theta))) ;
 */

#define SAMPLE_RATE 11025
#define FREQ        800.0

main()
{
    float x = 1.0, y = 0.0 ;
    float ang = 2.0 * M_PI * FREQ / SAMPLE_RATE ;
    int i ;
    float epsilon = sqrt(2.0 * (1-cos(ang))) ;

    for (i=0; i<1000000000; i++) {
        x -= epsilon * y ;
        y += epsilon * x ;
    }
    for (i=0; i<1000; i++) {
        x -= epsilon * y ;
        y += epsilon * x ;
        printf("%f %f %f\n", x, y, sqrt(x*x+y*y)) ;
    }
}

Addendum3: I’m not sure what I really said about the “complex multiply” method really is true. Using the builtin gcc complex support, it runs in about the same time (even though I think it should have twice as many multiplies, perhaps it pipelines better?) and works just as well with respect to roundoff.

For completeness:

#include <stdio.h>
#include <stdlib.h>
#include <complex.h>
#include <math.h>

#define SAMPLE_RATE 11025
#define FREQ        800.0

main()
{
        int i ;
        complex m = cexp(2.0i * M_PI * FREQ / SAMPLE_RATE) ;
        complex acc = 1 ;

        for (i=0; i<1000000000; i++)
                acc *= m ;
        for (i=0; i<1000; i++) {
                printf("%f %f %f\n", creal(acc), cimag(acc), cabs(acc)) ;
                acc *= m ;
        }
}

Argh… battery died during AO-51 pass…

Early today, I had problem with feedback on my little Sony ICD-P520 voice recorder during an AO-51 pass, which was unusual: I’d never heard it before. I suspected that it might be because I didn’t have a connector tightended or an audio jack stuck in all the way, and wanted to work the evening pass so I could test it. Unfortunately, minutes before the first pass of the evening, I realized that I had left the radio on, and the thing was dead. I tried quickly to shift to my little Yaesu VX-3R, but it doesn’t have the uplink frequencies plugged in, and I botched the recording anyway.

So, I put the Kenwood on the charger, and waited the 98 minutes for the next pass. Unfortunately, the Kenwood charges VERY SLOWLY, like 10 to 12 hours, so when AO-51 came up, I didn’t have much of a charge in it. I was suprised to find that nobody was working it as it came up in the southwest. I was the first person to call out. I got WC7V, Kerry, and then KD7F KB7F (upon further playbacks) called back, but while trying to confirm the contact, my battery cut out again. An annoying feature of the TH-D7A is that it gives no hint: it just reboots.

But, at least the feedback was gone on the recording.

Here’s it is, for the enjoyment of all.

Sorry ’bout that James Gerald. I’ll catch you again some other time.

Motion…

As a break from my amateur radio posts, here’s a photography one!

Most of my photographs are cool largely by accident. This is no exception. Well, that’s not quite true, I was sort of trying for this effect, but it turned out much better than I could have expected. It’s shot with the Night Portrait mode of my Panasonic point-n-click camera, which means that it holds the shutter open and hits the flash. Thus, you get some nice motion, and a fairly sharp image at the end. I think it’s kind of neat.

Motion…

Why a receive preamp is better than a transmit amplifier for working amateur satellites…

I’ve been pondering potential upgrades to my satellite capabilities. Right now, I’m using a very popular combination: an arrow antenna and a Kenwood TH-D7A. Often, at the beginning of passes, where satellites are still relatively distant, I get very weak signals, and can’t often hear the satellite well until they are maybe 15 or 20 degrees over the horizon. In talking (both on the bird, and via email) with Mark Spencer, WA8SME, I’m beginning to see why his recommendation of adding a preamplifier to the receive side of my setup might result in better overall performance.

Mark wrote a very nice article for the Amsat Journal entitled Why can’t I hear AO-51? which is simply great and clearly explains how you can figure out the path loss between the satellite and you. It turns out that the path loss from you to the AO-51 is probably somewhere around -126db on 440mhz, but the uplink loss from you to AO-51 is only about -112db, or nearly 14 db stronger.

What’s the difference? Well, first of all AO-51 is running only 1w of total power and my Kenwood cranks out above 5. That’s almost 7db stronger right there. What’s the rest of the difference? Mostly the difference in free space loss between 2m and 70cm. The approximation for path loss that is most often used for freespace
path loss is:

path loss = 32.44 + 20 log(d) + 20 log(f)

given in db for a distance of d kilometers and frequency f in megahertz.

Assuming the distance is constant, for a given frequency, the difference is the is about 9.5 db stronger on 2m than on 70cm. (20 * log(145.92)-20*log(435.3) is just about 9.5). It turns out that AO-51 is a little deafer than your HT, but has about 4db more gain in its antenna compared to your rubber duck, so overall, you have a much easier time getting signals to it than it does getting to you.

What this suggests to me is that a receive preamp may very well be a good idea. I’m looking into getting one soon.

AO-27 Pass…

First time I worked AO-27 in the new year, caught regulars WA8SME, VA7MG, WA6KYR (who I didn’t recognize, but I worked him on December 19th), KI6IUJ, and WX7P.

MP3 Recording of QSOs for Jan 5, 2008 on AO-27, around 22:45 UTC

The audio starts pretty raspy, you can barely hear me coming back through the downlink, but later, it gets MUCH stronger. This seems typical. WA8SME has assured me that I’m getting through fine at these lower elevations, but I can’t hear myself very well. Perhaps a preamp is in my future.

Colorized Sat Pictures

Colorized Sat Picture (sort of)I was trying to figure out how people really colorize satellite pictures, but wasn’t making any headway, so I just went ahead and did some relatively straightforward gimp work. I’ll write this up too, eventually. Basically it is just a set of thresholds to establish some masks (one for the ocean, one for brown land, one for green, and one for the clouds. Less green would probably be better than more, because it begins to leak into the clouds. Oh well.

AO-51 from inside…

Well, the weather today sucks. We have 40mph gusts, and are expecting a full 2 inches of rain. That being said, I decided to try to work AO-51 as it came overhead by standing in my living room with my handheld yagi. It wasn’t stellar, but I did manage to get W8SME (you can hear him tease me that it isn’t “shorts weather” since I usually have been operating in shorts and a T-shirt from my front yard). The interference from the roof made it pretty difficult to receive and even harder to receive, but you can hear a bit of the traffic.

Pass recorded from my living room, pretty marginal.

Talking to smart people makes me feel stupid…

See the curving sync lines?Okay, so here’s the deal: I’ve been working on my weather satellite decoder off and on for a few weeks, and been cleaning up the code, trying to make it simpler and better explained in preparation for eventual publication. I’m now at the point where I’m trying to do the whole “sync detection” part, so that each scanline is placed directly below the previous one. But if you look at the image on the right, you’ll see that the problem isn’t just finding the one, correct line length, the lines actually vary in length, becoming longer as the picture moves down, causing the image to drift right.

I immediately thought, “this has something to do with Doppler shift”, which is correct, but which I didn’t have any kind of real justification or mathematical basis to my understanding. It was, of course a guess. I was walking back from lunch, explaining this to Tom, and I said “the odd thing is that I don’t understand how the lines could be getting longer.” After all, the satellite emits 2 scanlines per second from its point of view, that doesn’t change when its received, right?

Tom looked at me like I was stupid.

Which was of course enough to spawn me to rethink, and realize that yes, I was being stupid. Let’s say that the satellite emits a 100hz tone for one second. The received signal will be Doppler shifted up or down based upon the relative velocities of the satellite and the ground station. If the satellite is moving towards the ground station, the Doppler shift will move the frequency up. The received signal will complete the same number of cycles, but at a higher frequency. That means it has to take less time. Similarly, for a satellite moving away, the frequency will be lower and each scanline will be greater than the nominal frequency.

In my case, at AOS, the satellite is approaching, and the line rate will be greater than the nominal 2hz. At max elevation, the satellite is moving perpendicular to the observation vector, and the line rate will be precisely (well, not precisely, as pointed out by Steve below, but close enough for my purposes…) 2hz. At LOS, the line rate will be less than 2hz. In each case, successive lines are longer than previous lines, which causes the nominal trend to the right we see in the images as decoded by my simple decoder.

Duh Einstein. I find again that when you think about things the right way, the answer seems obvious.

Addendum: if we could trust the sampling rate of the sound card, we could determine the exact point where the satellite passed max elevation, by finding the place where the line rate was precisely 2hz. I’m not sure how accurate your average sound card is. I’ll think about it some more.