Hardware GIF

About a year and a half ago, I started work on a fun little project. I’ve been dabbling with it on-and-off, and now it’s finally finished. So I thought I’d post a retrospective, as the process and challenges along the way were just as enjoyable as the end result.

It all began with a tweet that randomly popped into my head one day:

Sean Martell replied with a classic GIF, and something about the combination of tweets made me start itching to build a real, physical version. The basic plan came together quickly, but I didn’t realize that it would be a long and meandering path through researching GIFs, vintage electronic hardware, nitpicky laser printer output, metalwork, 3D modeling/printing, and more.

I think the finished result is pretty good:

GIVE-A-FUCK-O-METER

Here’s a bit more about the process of building it.

Research and Foundation

The first thing I had to do was some due-diligence: what are the essential qualities of meme-meter? After extensive research on every such GIF I could find, I knew exactly what I wanted. A meter with a retro feel, a realistic face that was scientific and precise, and a needle that jittered around the bottom of the scale to indicate approximately “zero fucks given”. In metric.

All the GIFs

The next day, I jumped on Ebay to scope out some vintage analog meters, and got unbelievably lucky: a pair of Triolab voltmeters from the early 1960s for just $16 (plus shipping). One was rather ugly and worn, but the other was absolutely perfect. Retro, with just enough wear to be authentic, yet in excellent condition. A compact 4-inch cube with a hefty weight makes it perfect for desktop display. And, oh, the details – industrial black crinkle-paint finish, sturdy knobs, brass and stainless steel screws, and a classic aluminum product nameplate.

The insides are equally amazing. Lots of colorful antique components (even a vacuum tube!) on a wire-wrapped board, complete with that distinctive “old electronics smell” that may or may not be known to the state of California as causing cancer. Even the cabling just oozes quality, neatly bundled with lacing that’s rare to see today outside of aerospace applications.

Old-skool components

As an added bonus, there’s an instrument calibration label on the top from “Martin Marietta Corporation, Aerospace Division,” certifying that it’s within 2% of manufacturer’s specs as of November 1963.  Plus an earlier ink stamp from June 1961. They help make it feel like it fell into a time warp straight from a mid-century laboratory. (I’d love to know what this meter was originally used for – Martin Marietta was probably best-known for the Titan family of rockets and ICBMs, so something involving them might be a good guess.)

Calibration sticker and stamp

Unfortunately, the paper sticker was in desperate need of conservation; it was starting to degrade and was very fragile. One corner was missing, and another was barely hanging on. Not too surprising, as it was a simple tag meant to be replaced after 6 months, and not designed for a 50-year lifetime. To fix it I used some adhesive to fasten the loose edges, and a clear “Ultra Matte” polyurethane paint to stabilize the surface. I was pleased with the result, which maintains the appearance of plain (unpainted) paper. [Aside: the tech who originally applied the label was very sloppy with the glue, if you look closely that’s what you see around the edges, not my work!]

Face Time

My first major undertaking was to design a new faceplate for the meter. I used Acorn to draw the scale using vector lines and circles; most of the work was tedious but straightforward. One handy trick was to scan the original faceplace at 600dpi on the office scanner/copier, and use that as a template for accurate physical sizing.

I spent a disturbing amount of time in the vintage typeface rathole. My first thought was to use Futura, which is commonly used in aerospace instrumentation (notably, the flight controls on Apollo and the Space Shuttle). But it didn’t feel quite right – ironically(?) too modern. I also looked through piles of other typefaces, named and unnamed, from hobbyists who recreate flight controls on vintage aircraft. In the end, I just used the modern Avenir Next Condensed font that comes with OS X for the main text. It’s a faithful nod to the original meter faceplace. I also matched typefaces as best I could for the  smaller labels, and redid the “triolab” logo to make it sharper than the original scan.

Once printed, I carefully disassembled the analog meter, flipped over the original aluminum faceplate, and affixed my version with some spray mount.

Before and after. Well, after and before. You know what I mean.

Laser Printer Resolution

Attention to detail was important to me on this project, but one issue I didn’t catch until too late (and never fully resolved) was print quality. Despite my work being in resolution-independent vector format, I consistently got suboptimal output when printing. Here’s an example of a 10pt capital letter “K” printed 3 different ways, photographed through a USB microscope:

Bad K, bad K, ok K.

On the left is output from Acorn, as printed on my 10 year old home HP LaserJet 1012 (600dpi), and in the middle as printed on a new Ricoh C2503 (1200dpi). The rightmost is the same letter “K” printed on my HP, but using TextEdit instead of Acorn. I tried myriad combinations of printing to intermediate formats, source bitmap resolutions, and printer settings, but the results were always the same… Anything coming from Acorn or Photoshop came out with bumpy edges, while output from a text editor was crisp.

My assumption is that something in the pipeline was rasterizing everything, and the printer was just doing it’s best to blithely print a greyscale bitmap with halftones. Eventually I got slightly better, but not great, output by printing to an absurdly high-resolution PDF, filtering to B&W and downsizing with ImageMagick, and then printing the final 1-bit depth image. I’m curious if a dedicated vector program like Adobe Illustrator would have made this Just Work, or if there’s even any good way to do this. Back in the day one could have hand-crafted some PostScript/PCL for this, but I’m not sure exactly how modern printing pipelines work.

Who knew that 1200dpi wasn’t enough for good black-and-white output?! (This guy, apparently.)

Electronics

The electronics on the new meter are slightly overkill, but are what I had sitting around. At the core is a Digispark (basically a tiny Arduino clone), with an IO port expander and a custom protoboard for gluing everything together.

New-skool components

The Digispark controls the meter through a PWM output. Analog meters are driven by rather small currents, and I needed just 206 microamps to drive it full-scale, which is trivial for the microcontroller to provide directly. At 4.65v that needs about 22kΩ (thanks, Ohm’s Law!), so I used a couple resistors summing to 20kΩ and a 4kΩ trimpot for fine-tuning… That lets the software simply use the PWM pin from 0-100% without having to worry about overdriving the meter. Doing so can actually make the needle stick at the over-100% point, and I didn’t want to risk having a software bug cause hardware damage. This meter does not go to 11.

Of course, no Arduino project is complete without some LEDs! I mounted an I2C-controlled RGB BlinkM LED inside the meter, behind a small sheet of milky-white plastic sheeting to diffuse the light. I have it set to generate an warm orange glow reminiscent of a vacuum tube, but it can be changed to other hues with the front-panel knobs (as read by the Digispark). The BlinkM has 24-bit color resolution, which really turns out to be inadequate. The exact color of orange I want (a mix of red + green) is tricky for it to reproduce — the human eye is very sensitive to green, and there is a single 8-bit level that looks about right. One level less and it’s too red, one level more and it’s too green. Next time I’d probably just use a dedicated monochrome orange LED at the right wavelength, or an RGB LED with ADC levels I can control better.

I also tossed in a couple extra white LEDs, just because I could. These have a higher power draw, and are switched by transistors. But they ended up not really working well for illuminating the meter at night, because they’re too far behind the faceplate. Oops.

The components I used were quite small – 0805 surface-mount resistors, 5mm×5mm PLCC LEDs, and 30-awg wire for connections. Some people hate working with stuff smaller than standard 0.1″ PTH parts, but I like the compactness and challenge. However, it’s essential to use a good soldering iron and wire strippers that can handle tiny wires. Also highly recommended: a steady hand, and a magnifying loupe or USB microscope for inspection.

When I was adding the control electronics, I didn’t want to totally gut the existing voltmeter components because they are so beautifully vintage. So they’re simply disconnected and left in-place. Similarly, I wanted to be respectful to the existing layout by carefully routing and weaving my new wiring harness. It’s completely hidden without the case being opened, but it was important to me, knowing what was inside.

Software

There’s not much to say about the software running on the Digispark, since it’s fairly simple. You can view it here. To make the meter’s needle jitter, it outputs a semi-random value near zero, with a rare outlier to make it bounce a bit more on occasion. I can’t make it twitch as hyperactively as the original GIF (there are physical limitations on how quickly the needle will move), but it’s still satisfactory.  I also added some debouncing on the selector switch, using a small state machine and timeout. Probably over-engineered, but it was fun to write.

I did have to do some debugging with an oscilloscope, that was also fun! The code for adjusting the BlinkM LED color would sometimes fail to work — I’d tell it to change color, but nothing would happen. The interface to the BlinkM is an I2C bus, and so I used my oscilloscope to see what was happening. It’s got a built-in I2C decoder, but it was more enjoyable to learn how I2C works and decode the signaling by hand. The problem ended up being that the BlinkM device would sometimes fail to acknowledge a command. I’m not really sure why, but happened rarely enough, and was detectable in software, so I just added a retry for when a failure occurred.

Connections

The most stress-inducing aspect of the project was adding a micro-USB connector to power the whole thing. None of the existing holes in the Triolab case were big enough to accommodate a connector, so I’d have to make a new – and permanent – hole. Further, I wanted a nearly-invisible connector, but none of the commercially available panel-mount connectors I could find were suitable. They were all designed to bolt on top of a large hole in the mounting surface, as a large protruding lump of plastic.

So, I ended up designing a custom assembly for mounting a micro-USB connector and 3D-printing it. A little bit overkill, but it was a fun process to go through.

I’ve previously used Google’s SketchUp, but found it limiting. It seems well-suited to freeform artistic design, but less so for CAD-like design where one needs specific dimensions and layout. After looking at a number of options, I settled on OpenSCAD. It’s both free and Free, has some good tutorials, and allows for precision synthesis . Based on constructive solid geometry, it’s great for someone with a programming background, and reminds me a lot of playing with the POV-Ray raytracer years ago.

OpenSCAD

The connector I designed basically mounts to the back of the mounting panel, and is thus flush with the outside. I had it printed in Frosted Extreme Detail from Shapeways (16 micron resolution!) for just $15. I soldered my connecting wiring to a splashproof micro-USB connector, epoxied it into my 3D-printed connector, and then mounted that onto the meter’s case with silicone. The silicone gave a solid connection, but one that I can easily replace in the future when micro-USB is obsolete. This meter is over 50 years old, and USB format changes won’t be the death of it!

Connector with USB plug inserted

Why a splashproof connector? I wanted to pot (encase) my connector in epoxy for reliability, but from previous experience had learned that epoxy has a tendency to seep though any openings, and foul up the ability to insert the connecting cable. I hoped this connector type would be sealed and avoid that. As it turned out, even a “splashproof” connector still has tiny openings, and I had to spend an hour scraping out partially-cured epoxy from the insides. In the future, I would make my soldered connections, lightly seal up any superficial openings, and only then glue it into its final resting spot.

Another lesson learned is that it’s a pain-in-the-butt (A HUGE PAIN-IN-THE-BUTT!) to solder connecting wires to an extremely tiny micro-USB connector. (I suppose it’s still a good challenge and builds character. Or something.) The connector I used was really designed for surface mounting, but I manged to make it work with patience and plenty of flux. If I did it again, I’d reflow it to a tiny PCB adapter, which would make connecting the wires trivial.

Tiny tiny tiny

It all worked out pretty well, the connector is flush with the case and mounts perfectly into the hole I drilled for it. I thought about painting it black to blend in a bit more, but the fit looks so good that I was concerned that painting could just make it worse. It’s also easy enough to do later, or maybe if I eventually redo it as a USB-C connector…

USB pug in the back

Conclusion

This was a really fun project for me. It was stretched over a long period of time, but the end result was something that I was happy with, something that I learned from, and something that I hope others might find interesting too.

Ironically, I really gave a fuck about this zero-fucks-given meter!

Foxkeh Dance is back!

That’s right! Everyone’s favorite dancing mascot is back, baby!

Back in 2008, Alex Polvi (of Firefox crop circle fame), departed Mozilla to found his own startup. In one of the most epic farewell emails of all time, he created Foxkeh Dance, a Mozilla flavor of the Internet-classic Hampster Dance site.

Alas, domains expire, and for the last 5 years foxkehdance.com has been the home of a domain squatter hoping to interest you in the usual assortment of spam. But a few weeks ago, I randomly  checked the site, and discovered it was available for registration! So I grabbed the domain, and set about restoring it.

The ever-amazing Archive.org has a cached version of the original 7-year-old site from August 24th 2008… Mostly. It has the HTML, but not the images or background music. Luckily a couple of contemporaneous Mozilla community sites included copies of the animated images, and from that I was able to restore what I believe are original versions. (Update: it seems archive.org is now using these newly-restored images to fill in their incomplete cache. Curious.) While the original embedded “hamster.mp3” file is lost, I remember it a being a straight copy of the Hampster Dance site, and that’s easily available. Of course, the original site used plugins to play sound, so I’ve updated it to use a modern HTML5 <audio> replacement.

And now Foxkehdance.com is back!

For those unfamiliar, Foxkeh is Mozilla Japan’s cartoon mascot. Recently it’s been the unofficial mascot of the new Tracking Protection feature in Firefox (butt flames and all). I hope we’ll see more of the ‘lil guy in the future!

You may now resume dancing.

Stellar Paparazzi

Last Thursday (23 Oct 2014), North America was treated to a partial solar eclipse. This occurs when the moon passes between the Earth and Sun, casting its shadow onto part of our planet. For observers in the California Bay Area, the moon blocked about 40% of the sun. Partial eclipses are fairly common (2-5 times a year, somewhere on the Earth), but they can still be quite interesting to observe.

The first two eclipses I recall observing were on 11 July 1991 and 10 May 1994. The exact dates are not memorable; they’re just easy to look up as the last eclipses to pass through places I lived ! But I do remember trying to observe them with some lackluster-but-easily-available methods of the time. Pinhole projection seems to be most commonly suggested, but I never got good results from it. Using a commercial audio CD (which uses a thin aluminum coating) had worked a bit better for me, but this is highly variable and can be unsafe.

I got more serious about observing in 2012. For the annular solar eclipse and transit of Venus which occurred that May/June, I made an effort to switch to higher-quality methods. My previous blog post goes into detail, but I first tried a pinhead mirror projection, which gave this better-but-not-awesome result:

(In fairness, the equipment fits into a pocket, and it was a last-minute plan to drive 6 hours, round trip, for better viewing.)

For the transit of Venus a few days later — a very rare event that occurs only once ever 105 years — I switched to using my telescope for even better quality. You don’t look through it, but instead use it to project a bright image of the sun onto another surface for viewing.

I was excited to catch last week’s eclipse because there was an unusually large sunspot (“AR2192”) that was going to be visible. It’s one of the larger sunspots of the last century, so it seemed like a bit of an historic opportunity to catch it.

This time I took the unusual step of observing from indoors, looking out a window. This basically allows for projecting into a darker area (compared to full sunlight), resulting in better image contrast. Here’s a shot of my basic setup — a Celestron C8 telescope, with a right angle adapter and 30mm eyepiece, projecting the full image of the sun (including eclipse and sunspots) onto the wall of my home:

The image was obviously quite large, and made it easy to examine details of the large sunspot AR2192, as well as a number of smaller sunspots that were present.

I also switched to a 12.5mm eyepiece, allowing for a higher magnification, which made the 2-tone details of the main sunspot even more obvious. The image is a little soft, but not too bad — it’s hard to get sharp contrast at high zoom, and the image was noticeably wavering as a result of thermal convection withing the telescope and atmosphere. (Not to mention that a telescope mounted on carpet in a multistory building isn’t the epitome of stability — I had to stand very still or else the image would shake! Not ideal, but workable.)

As with the transit of Venus, it’s fun to compare my picture with that from NASA’s $850-million Solar Dynamics Observatory.

Observing this sunspot wasn’t nearly as exciting as the Carrington Event of 1859, but it was still a beautiful sight to behold. I’m definitely looking forward to the 21 August 2017 eclipse, which should be a fantastic total eclipse visible from a wide swath of the US!

Sans Flash

I upgraded to a new MacBook about a week ago, and thought I’d use the opportunity to try living without Flash for a while. I had previously done this two years ago (for my last laptop upgrade), and I lasted about a week before breaking down and installing it. In part because I ran into too many sites that needed Flash, but the main reason was that the adoption and experience of HTML5 video wasn’t great. In particular, the HTML5 mode on YouTube was awful — videos often stalled or froze. (I suspect that was an issue on YouTube’s end, but the exact cause didn’t really matter.) So now that the Web has had a few additional years to shift away from Flash, I wanted to see if the experience was any better.

The short answer is that I’m pleased (with a few caveats). The most common Flash usage for me had been the major video sites (YouTube and Vimeo), and they now have HTML5 video support that’s good. YouTube previously had issues where they still required the use of Flash for some popular videos (for ads?), but either they stopped or AdBlock avoids the problem.

I was previously using Flash in click-to-play mode, which I found tedious. On the whole, the experience is better now — instead of clicking a permission prompt, I find myself just happy to not be bothered at all. Most of the random Flash-only videos I encountered (generally news sites) were not worth the time anyway, and on the rare occasion I do want to see one it’s easy to find an equivalent on YouTube. I’m also pleased to have run across very few Flash-only sites this time around. I suspect we can thank the rise of mobile (thanks iPad!) for helping push that shift.

There are a few problem sites, though, which so far I’m just living with.

Ironically, the first site I needed Flash for was our own Air Mozilla. We originally tried HTML5, but streaming at scale is (was?) a hard problem, so we needed a solution that worked. Which meant Flash. It’s unfortunate, but that’s Mozilla pragmatism. In the meantime, I just cheat and use Chrome (!) which comes with a private copy of Flash. Facebook (and specifically the videos people post/share) were the next big thing I noticed, but… I can honestly live without that too. Sorry if I didn’t watch your recent funny video.

I will readily admit that my Web usage is probably atypical. I’ve rarely play online Flash games, which are probably close to video usage. And I’m willing to put up with at least a little bit of pain to avoid Flash, which isn’t something fair to expect of most users.

But so far, so good!

[Coincidental aside: Last month I removed the Plugin Finder Service from Firefox. So now Firefox won’t even offer to install a plugin (like Flash) that you don’t have installed.]

Shredding Fail

A few years ago I blogged about the importance of using a good paper shredder. A crappy shredder is just (bad) security through obscurity, and easily leaks all kinds of info. So I was delighted and horrified to find this package show up in the mail, using shreds as packing protection for the item I had ordered.

 

30 seconds of searching turned up a number of interesting bits (plus a few more with full names which I have kindly omitted):

Let’s count a few of the obvious mistakes here:

  1. Using a cheap, damaged, or simply overloaded shredder that doesn’t even fully cut the paper. I got an inch-wide swath of two pages for free.
  2. Not using a cross-cut shredder. (In part, there is a mix of both types.)
  3. Shredding in the direction of the printed text.
  4. Sending the poorly-shredded output to a random person who bought something from your business.

And of course it would have been better security to use a microcut shredder.

Now, to be fair, even this poor shredding has technically done its job. Other than a few alluring snippets, it’s not worth my time to assemble the rest to see the full details of these banking, business, and health care records. But then I’m a nice guy who isn’t interested in committing fraud or identity theft, which is an unreasonable risk to assume of every customer.

Satellite Radio

In my last blog post, I wrote about how I helped fund the launch of a satellite via KickStarter, and that after launch I would have more to say about receiving radio signals from it. This is that update.

The good news is that SpaceX’s Falcon 9 finally launched last Friday. It’s had two delays since the originally scheduled date of March 30th. No big deal, it happens. Here’s the launch video, showing liftoff, onboard rocketcam, staging, and separation of the Dragon cargo capsule: (YouTube)

This is the CRS-3 flight — the 3rd  Commercial Resupply Service flight hauling cargo to the International Space Station. With the retirement of the Space Shuttle, CRS flights are the only US vehicles going to ISS, although other countries have their own capabilities. This is also the first flight where SpaceX has successfully flown the first stage back to Earth for a landing (albeit in the ocean, for safety, as it’s still experimental). Usually rockets like this are expendable – they just reenter the atmosphere and burn up. But SpaceX plans to fly them back to reuse the hardware and enable lower costs. It’s a pretty stunning concept. There’s no video of CRS-3’s Falcon 9 returning (yet?), just two tweets confirming it was successful. But it just so happens they did a test flight last week that demonstrates the idea: (YouTube)

So back to to satellite I funded: KickSat. The “carrier” was successfully deployed, and the first telemetry packets have been received and decoded. In a couple of weeks (May 4th) it will deploy its 104 “Sprite” nanosatellites, which will each start broadcasting their own unique signals. Things are off to a great start!

The slightly bad news is that I haven’t been completely successful in capturing Kicksat broadcasts with my own ground equipment. Yet.

It’s challenging for a few reasons…

The biggest factor is that the signals are inherently just not very strong, due to power limitations. The KickSat carrier is a 3U cubesat, with limited area for solar-cells. It periodically broadcasts a brief telemetry packet with a 1-watt radio, which is what I’m trying to capture.

And of course the Sprites it carries are even smaller, and will only be transmitting with a mere 10mW of power. The silver area in the Sprite I’m holding below is where the solar cell goes. (It turns out that satellite-grade solar cells are export-restricted under US law, so the sample units shipped without ’em!)

Such faint signals need some modestly specialized (but still off-the-shelf) equipment to enable reception. I’ve got a yagi antenna and low-noise amplifier, as recommended on the KickSat wiki. Successfully making use of it is a little tricky, though. You need to use orbit tracking tools (e.g. gpredict or via Heavens Above) to know when a satellite pass will occur, and where in the local sky its path will be. Yagis are directional, and thus need to be pointed (at least roughly) to the right place. Not every pass is directly overhead, and if it’s too low on the horizon it may be too hard to receive (due to strength or interference).

Additionally, KickSat only broadcasts a short packet once every 30 or 250 seconds (depending on what mode it’s in), and during a pass it’s only above the horizon for a few minutes. That makes for a rather ephemeral indication that it’s even there. Blink and it’s gone! My location has about 4 pass opportunities a day, but not all are useful.

Oh, and did I mention I’m doing this all with a cheap $20 RTL2832U software defined radio?! Heck, the coax cables connecting my dongle to the antenna cost more than the radio itself!

I decided to start off by first trying to catch signals from some other satellites. I went through AMSAT’s status page and DK3WN’s fantastic satellite blog and gathered a list of a couple dozen satellites known to be active on the same 70cm (~435Mhz) band KickSat is using.

My first success was HO-68 (aka Hope Oscar 68 aka XW-1). This is a Chinese satellite launched in 2009, broadcasting a fairly constant 200mW telemetry “beacon” in morse code. Picking out the dotted line in the GQRX waterfall display was pretty easy, even though it’s not exactly on the expected 435.790Mhz frequency due to inaccuracies in my radio and doppler shift(!).

This is what it sounds like: WAV | OGG. Why is the tone shifting? The gradual lowering is doppler shift. The abrupt jumps upward are just from me adjusting the radio tuning to keep it audible. My morse code skills are terrible, but I replayed it enough times to convince myself that it starts out with the expected “BJ1SA XW XW” (the radio sign and initials of its name), per the page describing the signal format. For the lazy, that’s – . . . / . – – – / . – – – – / . . . / . – / – . . – / . – – / – . . – / . – – in morse code.

Next up was FO-29.

Here’s a screengrab of gpredict, showing the predicted path low in the sky, from the southeast to north.

It’s got a stronger 1-watt beacon, which wasn’t too hard to spot. Here I’ve switched from GQRX on OS X to SDRSharp on Windows. It has more features, plugins, and makes it easy to zoom in on a signal. The signal with doppler-shift is readily apparent as a diagonal line.

Audio of FO-29’s beacon: WAV | OGG. Despite the stronger transmitter, the received signal is weaker (probably due to being low on the horizon), and the the morse code is sufficiently fast that I’m not able to decode it by ear. (There’s an app for automatic decoding, but I haven’t tried it yet.)

And lastly… *drumroll*… After a number of unsuccessful attempts to receive KickSat’s signal, I finally caught it today! There was a nearly-overhead pass in the afternoon, so the as-received signal strength was optimal.

I pointed my antenna upwards, tilted it to my clear northeast view, tuned SDRSharp to the 437.505 MHz KickSat frequency, and waited. This is one of the usecases where software radio is really useful… While waiting, I was was recording the entire raw ~2Mhz slice of bandwidth around that frequency. That’s 4.5GB for the 7 minutes I was recording. I actually missed the transmission the first time, as it’s indicated about 23kHz lower than expected (again, due to hardware inaccuracies and doppler shift). But no big deal, I just replayed the recorded data and fine tuned things to the right spot.

Here’s what it sounds like: WAV | OGG. Unlike the steady stream of analog dit-dahs from HO-68 and FO-29, this is just 2 seconds of digital “noise”, like you would hear from a dialup modem. In fact, it’s exactly what you’d hear from an old modem. KickSat is using the 1200bps AFSK-modulated format, which is apparently still widely used in amateur packet radio. There are decoders available to extract the digital data (GQRX has one built in, and SDRSharp output can be piped to the qtmm AFSK1200 decoder).

If you’ve got SDRSharp, here’s the raw IQ data for the packet (ZIP, 60.3MB). I cropped the data to just the relevant portion. Alas, I can’t seem to get the decoder to recognize the packet.😦 I’m not quite sure what the problem is yet… I’ve successfully decoded other AFSK data with this setup, so I suspect my signal was just too weak/noisy. Could be poor antenna pointing, but this was an easy pass. Some folks have had success with improving SNR with shielding, but I haven’t been able to replicate their results. There are a number of knobs and dials in SDRSharp to adjust manual/automatic gain control, so I might need to tweak that. (Unfortunately difficult, as there are only a few brief chances a day to catch KickSat.) It’s also possible that this is just slightly beyond the capabilities of a $20 RTL2832U dongle. Other options exist. I’d love to get a HackRF SDR board, but they’re not available yet. The FUNcube Dongle Pro+ can be had for about $200, but from comparisons I’m not sure exactly how much better it is in this band, or if it’s worth it. I’d love to hear opinions from hams who know this stuff better, or have tried both!

Amusing aside: while poking around in the 70cm band for interesting things, I stumbled across Santa Clara County’s ARES/RACES packet radio BBS. (Apparently, Ted, that is indeed still a thing!) In fact, FO-29 is actually an orbiting BBS! It’s quaintly amusing in the Internet Age, but when it launched in 1990 it must have been amazing. I had just upgraded to a 2400bps modem and discovered FidoNet and UUCP to reach beyond the local area code BBS systems.

That’s it for now. Over the next few weeks I’ll be refining my equipment and skills, and hope to capture some solid transmissions by the time my Sprite deploys. That will be even tougher to catch, but it’s a fun challenge!

Follow

Get every new post delivered to your Inbox.