ShareBrained Technology makes electronic kits and devices for music, radio, and timekeeping. The Chronulator is our first product -- an analog, retro-ish clock with modern, programmable guts. Like all our (future) products, the Chronulator hardware and software are open-source. So you can customize it to look and work however you choose. Read more about the Chronulator or take a look at our gallery.
Taking a cue from Adam’s Chronulator case design, I experimented yesterday with a friend’s laser cutter, to make a Chronulator case that’s simple and easy for customers to assemble. Here’s the result:
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!
Willamette Week has a nice little write-up of the ADX Portland GIFTED Maker’s Market holiday gift sale. The Bombulator (bzztbomb’s Chronulator) is prominently featured!
Come out to ADX this Saturday (December 17, 2011), from 11am to 5pm, and load up on great gifts. ShareBrained will be there, along with friends Curious Terrain and Platemark X.
Make: Magazine’s Ultimate Kit Guide is out, and the Chronulator kit received a great review:
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.
ShareBrained will be showing and selling Chronulators at ADX Portland’s GIFTED “Maker’s Marketplace” on December 17th, from 11am to 5pm. If you live in Portland and want to pick up a Chronulator, this is a fine way to do it. there will be some 40-ish other vendors there, so come by and do some last-minute gift shopping!
I’m plugging away at building an inexpensive, high-bandwidth software-defined radio receiver. I built a bunch of PLL+VCO boards, filter boards, and quadrature mixer boards. But I still don’t have a good ADC to sample the signals I’m receiving. No longer! I just submitted a four-layer design to Laen’s Dorkbot PDX PCB Order, which should give me 10 MHz of bandwidth:
A quick overview of the board’s design:
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!
I’m a software radio freak. When I first heard about the Analog Devices ADF4350, a PLL+VCO that can tune between 137.5 and 4400 MHz, I was obsessed with getting one and building it into my projects. Naturally, the first step was to build it into a breakout board and get to know the chip. So I loaded up EAGLE, cranked out a design, and sent it through Laen’s four-layer PCB order. I’ve since soldered up two of these boards, and they’ve both worked wonderfully.
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!
I want to make a motorized pointer to follow the International Space Station (ISS) as it orbits over my house. To do that, I need to compute the altitude and heading of the ISS, based on the ISS orbit data, the current time, and my latitude, longitude, and altitude. I found a lot of stuff via Google that looked like what I wanted, but the math was too ugly and foreign and I got impatient trying to make it work.
About a month ago, I ran into Nathan Bergey, a space junkie and originator of ISS-Notify. I knew he’d have a good opinion on how to compute this stuff. Sure enough, he recommended PyEphem, which is a delight to use. Tracking the ISS as it goes over is pretty simple. Here’s the Python code I use:
import math
import time
from datetime import datetime
import ephem
degrees_per_radian = 180.0 / math.pi
home = ephem.Observer()
home.lon = '-122.63' # +E
home.lat = '45.56' # +N
home.elevation = 80 # meters
# Always get the latest ISS TLE data from:
# http://spaceflight.nasa.gov/realdata/sightings/SSapplications/Post/JavaSSOP/orbit/ISS/SVPOST.html
iss = ephem.readtle('ISS',
'1 25544U 98067A 11290.51528320 .00016717 00000-0 10270-3 0 9006',
'2 25544 51.6378 264.9380 0016170 337.7557 22.2896 15.60833726 20019'
)
while True:
home.date = datetime.utcnow()
iss.compute(home)
print('iss: altitude %4.1f deg, azimuth %5.1f deg' % (iss.alt * degrees_per_radian, iss.az * degrees_per_radian))
time.sleep(1.0)
When run, this program prints the current altitude (in degrees above the horizon) and azimuth (heading in degrees “clockwise” from North).
iss: altitude 78.1 deg, azimuth 249.8 deg
iss: altitude 79.1 deg, azimuth 250.7 deg
iss: altitude 80.2 deg, azimuth 251.7 deg
iss: altitude 81.2 deg, azimuth 253.0 deg
iss: altitude 82.2 deg, azimuth 254.7 deg
iss: altitude 83.3 deg, azimuth 256.9 deg
iss: altitude 84.3 deg, azimuth 259.9 deg
Sweet! Now all I have to do is pump these numbers out a serial port to an Arduino controlling a couple of servos, and I should be good to go!
I’ve started using GitHub as my source code and design repository. And naturally, the first thing I put on GitHub is the Chronulator 2.0 code and circuit design. Look for many Chronulator firmware enhancements, now that my code management has grown beyond .zip files…
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.
In the last two parts, I used my homebrew software-defined radio to receive weather image signals from the NOAA-19 satellite and spent some time trying to calculate the satellite’s speed using frequency shift measurements. This time around, I’m going to demodulate the raw signal and turn it back into the image the satellite captured.
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…
Quick recap: In part 1, I captured weather satellite signals with my software-defined radio prototype, using the audio input on my laptop. So, what can be done with these captured signals?
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.
Facebook
GitHub
Google+
Twitter
YouTube