After figuring out how to find a convex hull for my airplane data, I went back to see how much the range has varied over time. Here's a timeline that shows the daily observations on top, and the area of the daily convex hull on the bottom:
I've had a few changes to my RTL setup over the last few years that have had an impact on range. I've had basically three different configurations in the last two years: (1) an initial version connecting a NooElec RTL-SDR straight to the antenna, (2) an updated version that added a FlightAware filter between the NooElec and the antenna, and (3) a new version that uses a FlightAware Pro USB stick that has the filter built into it. Here's how big the convex hulls were for the data points collected in each day for the three settings:
In general, the filtering does seem to boost my range a good bit. The FlightAware Pro USB stick also seems to do better than a generic tuner that's plugged into an external filter. To be fair though- there were other things that changed in my setup over the years that may be skewing some of these numbers. At some point I inserted a splitter into my setup so I could also route the antenna to a USB DVB tuner. I think that explains the drop you see in the middle of the second setup (ignore the two gap periods- those were because the recorder wasn't running full days).
Now that my setup is a little more setup, I'd like to capture some data and then see how well my range corresponds with things like the weather (sounds like a fun science project for the kids).
One of the things I've been doing lately with the airplane data I'm collection with my RTL SDR is come up with better estimates for how much coverage and range I get in my local area. While you can easily estimate range just by watching dump1090's map output, you really have to look at a whole day's worth of data or more to get a good idea of what you can see. It's also useful to come up with some numerical estimates of the coverage so you can compare one hardware setup to another. After dusting off geometric algorithms, I realized the right thing to do was clean the data a bit and then compute the area of a convex hull for the points. The SciPy spatial library for Python has a ConvexHull that makes this easy to do.
Computing the Convex Hull
My airplane data is just a collection of geospatial points collected each day, so a good way to quantify my range would be to find a bounding shape for the points and compute the area. A bounding rectangle would be quick and easy, but inaccurate. I started thinking about algorithms to rotate a rectangle for a better fit, or recursively remove sections of it until it gave better coverage. Realizing that I was reinventing the wheel, I searched around for known solutions. A s/o answer pointed me to the gift wrapping algorithm, which builds a bounding polygon by comparing all remaining points and selecting the one that would maximize the new interior angle. It looked like it'd be fun to code up, but expensive to compute.
I then stumbled onto a youtube video that explained how QuickHull selected the four (left,right,up,down)-most points to build two triangles, removed all the interior points, and then selected points that would add the largest triangle to the polygon (or remove the most points). I was looking forward to coding this up, but once again, I wondered what was already available. Naturally, you can already do this in python: SciPy's Spatial library has ConvexHull. It's as easy as:
from scipy.spatial import ConvexHull import matplotlib.pyplot as plt # Do something to get some 2D points # Let Convex hull do the work cv = ConvexHull(pts) #cv.vertices has the bounding polygon print("%f\n" % cv.area) # Get some stats
Sigh.. Python's great, but it sure does take the fun out of everything.
There was stil a good bit of other cleanup and map stuff I had to do to start making reasonable pictures. First, I had to throw out some bad data. I still get a lot of bad points, most likely because of transmission errors (or misconfigured transmitters?). I filtered everything out that's outside of a reasonable range (though this was tighter than it needed to be). The number of bad points in any day was 1.2% of the observed points (50% of the days had less than 0.01% bad data). For plotting I had to load in Basemap and do all the normal merc projection stuff. For something so fundamental, this always seems to take a lot longer than it should. In any case, the pictures look good when you finish.
It's science fair time again and I've been looking around for something fun to do with the kids. One of the projects we found online that my younger son liked was an experiment where you see what materials block the signal of a remote controlled (RC) device the most. We dug up an RC tank, forced the controller to the forward position, and then wrapped the controller in different materials. The results were anticlimactic, though. While the fabrics didn't have any effect, the tank didn't seem to be bothered much when the controller was wrapped in foil either. Science had failed us once again.
Software-Defined Radio to the Rescue
The problem with the experiment I realized was that we were making a binary measurement: either the signal was blocked or it wasn't. What we needed was a way to get a better reading on how much the signal was being attenuated. It then occurred to me our RTL-SDR stick and Gqrx could do that for us. The back of the controller had a sticker with "40MHz" on it, which is within the RTL-SDR's tuning range. I launched Gqrx, pressed the up controller, and sure enough there was a strong signal at around 40MHz (with a harmonic at 41MHz). Success. We could see our enemy's signal. But could we block it?
Louis and I used duct tape to anchor the antenna to my workbench and mark off a fixed distance of three feet for the test. We used a rubber band to jam the controller in the forward position and then wrapped the controller in different materials. We recorded the dBFS signal strength off Gqrx (maybe not the right value, but it was consistent enough for comparisons). I did my best to explain what dB's were to both Louis and my wife, but in the end "more negative means less tank signal" was all they needed to know.
We tested 14 different scenarios. Most of the materials (wood, plastic, wax paper, rubber, paper, cardboard, and glass) didn't do anything to stop the tank's signal. Polar fleece and water had a noticeable effect. Metal did the best job of shutting the signal down.
The water test was the most interesting one for us. We wrapped the controller in a ziplock bag and then submerged it in a bucket of water. I had thought that water would completely block it, but we still saw some of the signal. When we reran the original binary experiment with the tank, we noticed that the controller's range was dramatically reduced and the tank would intermittently move.
Side Project: Building an AM Radio
The project was a good opportunity to talk to Louis about Radio stations and how people transmit information wirelessly. I found I had to provide a lot of background about radio stations in general, since the kids get most of their media through the Internet these days. Taking a car ride over the hills (to Fry's) while listening to the radio ("see how the radio gets fuzzy on the other side of the hill?") helped Louis get a handle on it. After the experiment, he had a new appreciation for how NASA ran their own RC car on another planet.
After reading more web pages, I took another step and ordered a 1MHz crystal so we could build a crude AM transmitter. The circuit is clever and easy: you just power the crystal with an audio signal, and hook a long wire to the output to serve as an antenna. I tuned our radio to 1000kHz AM, held the antennas a few inches away from each other, and sure enough, there was Rush's Spirit of Radio jumping the air gap.
The rest of the project was slow writing and arts-and-crafts. Louis wrote up everything for the poster, and (we're told) was very chatty about radio signals when the reviewers came around to talk to him about his project. We now know how to stop the tank's signal. Now all we have to do is submerge the planet in water (already on it!) or start putting countries in big metal boxes.
For the last few years, the majority of my time at work has gone into developing data-management services for high-performance computing (HPC). While we still have a ways to go before an official software release, we're starting to get performance numbers and have initial support for the Cray XC40's DataWarp NVMe array. I was asked to make a poster about our work and present it at an Exascale Computing Project (ECP) meeting that took place in Knoxville, Tennessee.
ECP is a new, multi-laboratory effort in the US that is scaling scientific computing to new levels through advances in hardware, applications, and system software. The goal is to develop an exaflops computing platform in the US that can serve the HPC needs of multiple domains (eg, science, energy, manufacturing, and national security). The data-management software we've been writing for asynchronous, many task (AMT) programming models falls into the system software category, and could be adapted to fit other needs in ECP (eg, workflows, checkpointing, and analysis).
ECP Poster Poster presented at ECP Meeting
Back in October I mentioned in an ADS-B logging post that I had mixed feelings about using the Intel Edison for my embedded projects. This December I decided to make the jump and switch over to the Raspberry Pi. I don't have anything to say about the Pi that hasn't already been said- this post is just to provide me with some closure on the Edison.
The Intel Edison had a lot going for it when it first came out. It featured a 32b x86 CPU, memory, flash, and wireless networking all on a tiny package for about $60. My first devkit had a socket for plugging in Arduino shields, which made it easy to use a lot of existing hardware and software. I bought a second Edison with a minimal breakout board so I could do low-power ADS-B monitoring. It looked like Intel was making smart moves to make a play in the emerging IoT market.
And then... nothing. While the Intel Message boards had a good amount of chatter on them, the only follow-up hardware relating to Edison was some Sparkfun gear and an expensive senor kit/book from Intel. In retrospect, there were a number if missteps on the hardware front. The Edison's micro i/o bus made it difficult for users to get at GPIO on their own. x86 compatibility was a wash because you usually had to recompile code to 32b in order to get it to run on the Edison. USB ports were limited. Worst of all, Intel never followed up with better hardware. Add Edison to the long list of Intel efforts where Intel was going to throw its weight around and take over a market but didn't (Hadoop, High-end GPUs, enterprise storage, smartphones... realsense and omnipath aren't looking so great these days either).
Edison vs Pi 3 Hardware
Back to the positive, though- I got a Raspberry Pi 3 kit for Christmas. The stats for the Pi are well known, but here's a summary of the differences between an Edison on a Breakout Board (BB) and the Pi 3:
Feature Edison(BB) Pi3 -------------- ---------- -------------- ISA 32b x86 64b ARM Cores 2 4 Clock 0.5GHz 1.2GHz Memory 1GB 1GB Internal Flash 4GB 0 Micro SD card no Yes Networking WiFi, BT Eth, WiFi, BT USB 1 4 GPIO 40pin 40pin IO Connector 70pin micro 40pin Video no HDMI Size 61x29mm 85x56mm Idle Power 0.7W 1.7W Cost $60 $40
Performance and Power
I did a few simple benchmarks to do a rough comparison between the boards. First I found and built a Monte Carlo program for computing Pi and let it run for 100M iterations. Using only a single core, the Edison and Pi3 took 52s and 19s respectively, making the Pi 2.7x faster. I started working on some multicore tests via OpenMP, but my Edison installation was missing libgomp and it didn't seem worth fixing. I also downloaded and ran ramspeed on the boards. The pi's caches seem to be 2.2x faster, while memory was 20% to 50% faster.
I hooked up the Pi3 to a few wall-socket power meters and took some preliminary readings. The meters said the Pi3 used about 1.7W when running headless with wireless (no usb, no hdmi). Launching 1-4 instances of the Pi program on the board raised the power to 2.2W, 2.7W, 3.2W, and 3.7W (thus 0.5W per active core). For comparison, the breakout board version of the Edison idles at 0.7W, and runs 1-2 instances of the Pi program at 0.9W and 1.1W (0.2W per active core). While the Pi3 uses 2.45x the power (per core) of the Edison, it's 2.7x faster and has a lot of I/O hardware ready for users. The Edison breakout board only has one mirco-usb port on it, which limits what you can do with it for projects. Upgrading to the Edison Arduino board to get more usb ports and more friendly pins eats more power. My empty Edison Arduino board used 2.4W while idle.
Another feature I really like about the Pi is that it boots off a removable microsd card. This feaure means I can use create multiple microsd os images and boot the hardware differently by plugging in a different disk (similar to the Amigas of my youth). It's also useful to be able to work on the os image on a desktop (installing packages on an embedded box always takes forever). Most importantly though, you don't have to worry about bricking your device if an install goes bad. Upgrading the on-device OS image for the Edison was nerve racking because it was difficult to repair the board if an install went wrong.
I didn't expect to use it, but the Pi's HDMI port has also been a source of fun. I hooked the HDMI up to the TV so I could do the inital network configuration. The display was faster and better looking than I expected, and I soon found myself taking a side trip into emulators via RetroPie. My family took an interest in the Pi when they realized we could plug multiple PS3 controllers into it and play Gauntlet. I wound up buying a Buffalo Classic USB Gamepad controller so we could get a more authentic-feeling SNES controller. At some point I'd like to revisit the emulation side of things and get the Amiga emulator configured right. I may also have to buy one of those X-Arcade Tankstick + Trackball controllers so I can show the kids the wonders of Centipede.
Now that I've started working with the Pi I'm kicking myself for not moving towards it earlier. The boards are cheap enough I can use them for one-off projects around the house, and there's plenty of info out there on how to do things with the hardware. That may mean I'll never do anything original with the Pi, but it's certainly more fun to get a project working than it is to spend a lot of time figuring out a work around for a proprietary board's under-documented hardware.
Update: Intel Quits IoT in June
Sure enough, Intel announced that they were killing off their IoT business and shutting down Edison, Joule, and Galileo June 20th. A sad consequence of this decision was that on July 5th they announced layoffs for 140 people (100 here in Santa Clara, 40 in Ireland). The sad thing is that it wasn't like the hardware wasn't selling- Intel's IoT area generated $721 million in revenue for Q1, which would be astounding for anyone but Intel.