What Chronulator case designs would you like to see in the ShareBrained store? Leave a comment, a Tweet, Facebook/Google+, e-mail, it’s all welcome!

Share/Bookmark

Alternative time-telling devices are compelling, but only if they’re easy to read. Building a kit can be satisfying, but only if it leaves room for creativity. The Chronulator clock kit fits the bill on both counts.

Check out the Ultimate Kit Guide online, or buy a paper copy at your nearest magazine vendor.

A quick overview of the board’s design:

• SMA connectors for the baseband quadrature input signal. There are two differential inputs, so four connectors total.
• Two-channel high-speed ADC from Linear Technologies. I designed with the 16-bit, 125MHz LT2185 in mind, but Linear offers many pin-compatible devices that are cheaper, with the attendant trade-offs in sample rate and resolution.
• Sampling oscillator in a standard 7mm x 5mm footprint. I’m planning to use a low phase noise oscillator like the Connor-Winfield CWX813.
• Lattice XP2-5 FPGA for sample rate conversion.
• FTDI FT2232H high-speed USB interface.
• Configuration and FT2232H pin breakout so I can experiment with USB-based FPGA code updating.
• JTAG interface for initial development.
• Power input — approximately 3.7V minimum.

USB 2.0 high-speed performance is a bottleneck for software radio. On a good day, you can get 35 MBytes/second. Assuming 12-bit quadrature signals, that gives you a complex sampling rate of about 12 MSamples/second, and a theoretical bandwidth of 12 MHz. Usable bandwidth will be more like 10 MHz.

Because of this USB-imposed bandwidth limitation, I chose to use a faster ADC to oversample the input and simplify the analog filtering going into the ADC. I’m expecting to oversample the baseband signal by 4x to 8x. With that amount of oversampling, simple four-pole Butterworth or Bessel filters should be plenty. The FPGA will do sample rate conversion, using CIC or FIR filters.

There’s almost no filtering on the ADC input. I’m planning to attach a separate baseband filter or use an RF band-selection filter to severely band-limit my target signals and avoid unsightly aliasing. Here’s one approach for an 80 MHz sampling rate and a 10 or 12 MHz output rate:

The great thing about oversampling is you don’t have to design your analog filter for the final sample rate’s Nyquist frequency. Instead, you can push that stop-frequency up to the sampling rate minus the final bandwidth. In the example above, it’s 80 MHz minus 6 MHz, or 74 MHz. So my filter can gracefully tail off across more than a decade of frequency (74:6 = 12.3x). Of course, with oversampling, I’ve made a lot more work for myself in the digital domain. But FPGA CIC and FIR filter implementations are plentiful and well-understood, so I’m not too worried…

The board should be back from Laen in a couple of weeks. I can’t wait to solder it up and see what happens!

Share/Bookmark

Analog Devices ADF4350 VCO+PLL breakout board

If you want one for yourself, you can find my breakout board in my “in-development” GitHub repo, filed under “radio/circuit-board/adf4350-breakout”. Enjoy!

Share/Bookmark

For completeness, I also uploaded the older TI MSP430 Chronulator 1.3 implementation. If you bought a Chronulator kit before November 2008, this is the code you want.

The NOAA-19 APT signal is a relatively simple signal to understand. When the satellite captures an image, it scans through it line-by-line, at a rate of two lines per second. The brightness of the image during scanning is amplitude modulated on to a 2.4kHz carrier tone, and sounds like this:

You can hear the (slightly painful) 2.4kHz carrier tone. Also notice the tick-tock-tick-tock pulse of the signal. Each tick and tock is a sync signal followed by a line of image data. Why a tick *and* a tock? APT transmits *two* images at a time, so the “tock” is the sync signal between data from the first and second images.

I rigged up a GNU Radio Companion “patch” to demodulate the APT signal. It’s based off a APT decoder by Alexandru Csete. It filters and demodulates the signal and outputs a file of demodulated data.

I tweaked the demodulated file a bit with Python, normalizing the data to the range (0,255) and writing out a byte-per-sample file:

import numpy
raw = numpy.fromfile('words.f32', dtype=numpy.float32)
normalized = raw / max(raw) * 255.0
output_u8 = numpy.array(normalized, dtype=numpy.uint8)
output_u8.tofile('pixels.u8')

Following Alexandru’s lead, I used ImageMagick’s “convert” to translate the byte-samples to a PNG image:

convert -size 2080x1194 -depth 8 gray:pixels.u8 image.png

And behold! A really noisy satellite image!

There are two images visible, side-by-side. The left side seems to be a visible spectrum image, while the right seems to be infrared. You can see parts of California, Oregon, and Washington. The Columbia River, a few miles from my house, is somewhat visible, too:

This was my first attempt at capturing a satellite signal, so I was using a crappy all-purpose dipole antenna. Hence the wretched amount of noise. But still, for my first attempt, I’m pretty pleased! Now, to build a better antenna…

Share/Bookmark

The first thing I did after recording the NOAA-19 APT signal was load it up in Audacity and examine the spectrum of the signal.

That’s a cool looking pattern — and it’s a bit suspicious too. The pinkish-purple curves indicate frequencies in the signal changing over time, over the ten minutes I recorded the signal. Notice how the frequencies change slowly at the beginning (left of the graph) when the satellite was rising over the horizon. The same thing happened at the end (right of the graph) when the satellite was descending back toward the horizon. When the satellite was directly overhead, the signal’s frequency changed very quickly. Hmmm. (think think think…) Hey, that’s the Doppler effect!

Indeed, the satellite is moving very fast — it orbits the Earth every 102 minutes. One Web site claims NOAA-19 is orbiting at 7.55 km/s, which is 27,180 km/h.

Let’s say we don’t already know how often the satellite orbits the Earth, or we don’t know the distance the satellite travels in one orbit. If we measure the Doppler shift of the signal, we can calculate the satellite’s speed ourselves. Here’s my measurement of the frequency shift in the signal — I get 5.6kHz from the the start to end of the satellite’s pass:

When the satellite is coming at me, the signal is “squeezed” and the frequency is increased by 2.8kHz — half of the 5.6kHz total shift I measured. As the satellite is traveling away from me, the signal is stretched and the frequency is decreased by 2.8kHz — the other half of the 5.6kHz shift. The frequency change as a percentage of the signal’s original frequency (137.1MHz) is 0.00204% — pretty small. But consider that this percentage is the speed of the satellite as a percentage of the speed of the signal. The signal is traveling at the speed of light, which is roughly 1,079,000,000 kilometers per hour. If we take that percentage from the speed of light, we get… Drum roll… 1,079,000,000 km/h * 0.0000204 = 22,000 km/h.

That’s close, but no cigar. Why is that number 19% lower than the actual satellite speed over the Earth (27,180 km/h, from above)? That’s pretty easy. The satellite is roughly 850 km above the Earth, and didn’t go directly overhead, but perhaps 450 km to the west. Calculating the hypotenuse: sqrt(850*850+450*450) = 962 km is the closest the satellite came to me. If the satellite went right through me, the Doppler shift I measured would’ve given the right answer. (…and I’d be splattered all over.) But the speed that the satellite was traveling relative to me was less than the satellite’s speed over the Earth.

Credit: Heavens-Above GmbH

Because I’m lazy and I’ve run out of room on my sketch-napkin, I’m offering a free Chronulator kit to the first person who can produce worked math that correctly compensates for the distance of the satellite from me, and gives an answer that’s within a few percent of the actual satellite orbit speed. I’m sure there’s a cosine or arctangent involved… Tweet your solution to @sharebrained or e-mail it to info@sharebrained.com — a camera-phone photo of a hand-written solution is fine (as long as I can read it!).

In part 3, I decode the signal to get at the weather images inside.

Share/Bookmark

Credit: NOAA

Joby was interested in receiving APT (automatic picture transmission) signals from the NOAA POES (polar operational environmental satellite). POES satellites orbit the earth every 102 minutes, and scan the entire Earth twice a day. They beam back radio signals containing images that we see every time we check the weather.

Credit: Fred E. Piering

I checked out the status of the POES satellites. NOAA-19 seemed like my best bet for reception of an APT signal on 137.1MHz. So I consulted Heavens Above (a great planet/star/satellite tracking Web site) to see when NOAA-19 would go over my town.

Credit: Heavens-Above GmbH

A few minutes before NOAA-19 was due to go overhead, I scrambled outside with my laptop, radio board, and cheap telescoping antenna. I hooked everything up and enticed my wife outside to help. As she monitored the waterfall spectrum on the computer, I waved the antenna around, trying to get the strongest possible signal. And here’s what we caught:

Wow! I didn’t expect my radio and antenna to be sensitive enough to receive a 10-Watt signal from 1,000 kilometers away! That signal should be strong enough to decode — which I’ll do in an upcoming post. Until then, stay tuned for tomorrow’s post: “Doppler Shift: How to calculate the speed of a satellite from your back yard”!

On to part 2 (computing satellite speed with “Doppler” shift) or part 3 (decoding the signal).

I designed a breakout board and had it made via Laen’s PCB order. Last night, I soldered it up, and this morning I started working with it through the I2C interface, using my Bus Pirate. By the afternoon, I was receiving pager signals at 929.675MHz, and aviation voice signals in the 118-137MHz band.

Here’s a POCSAG pager data burst. You can see the preamble as a square-ish zig-zag at the left side (start) of the burst:

For the aviation audio signals, all I had to do was amplitude demodulate the quadrature data (which I captured with my computer’s stereo audio input). Treat the quadrature sample pairs as complex numbers (which they are…), compute the magnitude of the complex vector, bandpass-filter the result, and you have the original audio!

Before long (like maybe tomorrow?), I should hook up an input device so I can control parameters live…

Share/Bookmark