Balloon Tracking with a Mobile Phone

Okay, so please read my last post if you haven’t already.

Anyway, now that we had a cheap tracking device, we decided to do what any reasonable people would do: send it into near-space. Or, at least, that was the plan.

So our last balloon cost $800. While $800 is pretty cheap considering what we did, we’re all college students, and we haven’t got that sort of money to spend all of the time. Last launch, we spent over $250 on our tracking system (by the way, an excellent device), some $80+ on our balloon, another $80 on helium, $30 on our radar reflector, and $50 on the parachute.

So we decided to replicate a typical launch, but this time to do it as cheaply as we possibly could. We’ve already got a $50 tracking unit (the i290 cell phone uploading data the sensor.network), so now we just need some way to lift it and make sure it lands safely.

In order to do this, we needed a cheap balloon, a parachute, and a radar reflector.

We built the radar reflector out of aluminium foil and foam, sewed the parachute, and found a cheap, 6′ party balloon. $45 for helium at the local Diddams and we were set.

Just before launch

We launched on December 31st, 2009 from just outside of Los Banos, CA. We inflated the balloon with several pounds of lift, and the balloon rose very quickly. At 641 feet, the phone left cellular coverage and began queuing up GPS readings, ready to send them off when back in cellular range, and all we could do was to wait.

We were periodically checking the internet for tracking information, and about an hour later, we began to get readings back from the balloon. We quickly discovered the the balloon had landed after only going to an altitude of around 6,000 feet (more about this later).

We jumped into our cars and drove to the landing site about 30 miles away.

Alex and Tim standing over the payload after landing.

The payload was in perfect condition, and the i290 phone was still on and reporting data just fine.

Now, about the 6,000 feet: it looks like we cheaped out when buying our balloon. There’s still a bit of contention over this, but it looks like a ‘real’ weather balloon has a higher percentage of latex than that of a party balloon. Our party balloon simply was not designed to expand to the same extent as a weather balloon, and burst at 6000 feet. Really, we should have just gotten a weather balloon — it looks like the small ones are just as cheap as the party balloon we bought ($20).

The good news is that we were able to successfully demonstrate that our tracking system worked. I threw together a little webpage that we used to track the thing on the day of the launch. Forgive me, it’s very rough around the edges.

And, if you’re too lazy to click that link, here’s a picture of our GPS trace.

The GPS trace for our balloon.

.

I also threw together a Google Earth KML file of our GPS data; download it here.

All in all, a wonderful time.

Grand total for this project (not including burritos and gas): $145. Not bad.

Tim has also got written about this on his blog.

Oh, and about the code for the phone. I’m not going to release it (at least right now): it’s far too ugly and hackish for me to release to the public. If you email me, I’ll probably send it to you with a long note explaining why it’s no good and you shouldn’t trust it.

Prepaid Phones, Sensor.Network, and Java

So school is out for the year, and I’ve got some three odd weeks off — plenty of time for side projects.

Anyway, I picked up a really cheap prepaid cell phone a while back for $50, with $5 prepaid credit on it. Neat thing is that it runs JavaME and has a cheap GPS unit built in. Overall, the thing feels pretty flimsy and cheap, but I still can’t believe it was $50.

The phone in question.

Anyway, Tim and I wrote a small bit of code to read the latitude, longitude, and altitude coordinates from the GPS unit on the device and upload it to sensor.network via a $0.35/day internet connection on the phone.

The code to post the sensor data was just a slightly modified bit from yggdrasil (actual source file is here).

HttpConnection conn=(HttpConnection)Connector.open(datastreamURI+"/data");
conn.setRequestMethod("POST");
conn.setRequestProperty("X-SensorNetworkAPIKey", APIKey);
conn.setRequestProperty("Content-Type", "application/xml");
conn.setRequestProperty("Content-Length", sampleDataXML.getBytes().length + "");
OutputStream os = conn.openOutputStream();
os.write(sampleDataXML.getBytes());

If you do take a look at the original source, you’ll notice that I had to change only a very small bit around; Java ME doesn’t have the URL class, so I had to open things up with a Connector; other than that, it was pretty straightforward.

So with a bit more code to sample the GPS, I’ve got a $50 GPS tracker that uploads data to the internet.

With Sensor.Network, I can graph where the phone is.

A trace of the phone's location; you can tell that the GPS isn't very good.

Fun stuff.

Balloon Follow-up

As promised in previous posts, we’ve now got a website dedicated to our balloon; we’ve reserved the domain hibal.org specifically for this sort of thing.

A full write-up, graphs (via sensor.network), and all of the photographs are posted.

Payload Recovered!

If you’ve been following the blog, you’ll know that my friends and I put a balloon into near space. You’ll also know that we didn’t get the payload back immediately.

Well, we’ve got great news; the payload was successfully recovered!

We gathered a team of 3 bicyclists and 5 hikers and went to Henry Coe Park today. The bicyclists made it to the landing site well before us hikers, and they found our payload.

Fortunately, we had some GPS coordinates come in over APRS on Saturday, which made the search much more likely to succeed. The bikers found the payload in a tree.

Considering how far off course the balloon went, it’s remarkable that we were able to recover the thing.

When we got back to the cars, we disassembled the still-intact payload.

Everything was in remarkably good condition, so we took a look at the images; we’ve got 9 gigabytes of photograph; a little under 3000 pictures in total. A SunSPOT in the science payload was also able to record some 600 sensor readings.

We’re totally swamped with sensor readings and photographs, so I can’t post everything here (yet!). I’ve found a few images I consider to be some of our best; I’m still trying to find somewhere to put the rest.

The balloon is still tied to the jeep.

And we're off!

This was very close to the highest altitude we reached.

The entire San Francisco Bay is visible from up here.

I’ve got thousands more, but I’m going to stop uploading for now, until I can find some sort of sane hosting that we all agree on.

I’ll be posting some our sensor data and more pictures later, and hopefully a full breakdown of the project.

Using the Ubiquiti as a Yggdrasil Sensor

My last post focused on using the Ubiquiti Wifi Access Point as a gateway to connect a SunSPOT to the internet (in this case, Twitter).

But we can also use the Ubiquiti as a sensor. The immediate utility that appeared to me was to use the Ubiquiti to scan for wireless networks and to get their signal strength. So let’s get started.

If you’re using a Linux box at home, you can scan for wireless networks using the command

root@localhost:~# iwlist scan

You’ll see an output something like this:

          Cell 01 - Address: 00:1E:4E:AB:CC:DF
                    ESSID:"Sun"
                    Mode:Master
                    Channel:1
                    Frequency:2.412 GHz (Channel 1)
                    Quality=97/100  Signal level:-29 dBm  Noise level=-127 dBm
                    Encryption key:on
                    IE: Unknown: 0007426967526F6F6D
                    IE: Unknown: 010482848B96
                    IE: Unknown: 030101
                    IE: Unknown: 2A0100
                    IE: Unknown: 2F0100
                    IE: IEEE 802.11i/WPA2 Version 1
                        Group Cipher : CCMP
                        Pairwise Ciphers (1) : CCMP
                        Authentication Suites (1) : PSK
                    IE: Unknown: 32080C1218243048606C
                    IE: Unknown: DD0700039301660000
                    IE: Unknown: DD06001018020100
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
                              9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
                              48 Mb/s; 54 Mb/s
                    Extra:tsf=00000017288f01d0
                    Extra: Last beacon: 3492ms ago

Now there are three lines in this that we’re interested in. The first one states the MAC address of our access point. Next, we want the line describing the ESSID (the “name” of the network), and, finally, the line showing us how strong our signal is, in dBm.

Now whenever I have a bit of text parsing to do, I always go to Perl. Unfortunately, I haven’t got enough space on the Ubiquiti’s measly 4 MB of flash to install Perl. Instead, I’m writing all of this in Bash. So I wrote a small shell script in Bash that parses the output from our iwlist command and prints only the useful information: ap_scan_and_format.sh.

#!/bin/bash

aplist=$(iwlist ath0 scan|grep 'Address\|Signal\|ESSID')

IFS=$'\n'
for line in $aplist; do
	if [[ "$line" =~ Address ]]
		then
			echo $line | sed 's/://g' | sed 's/.*s //g'
	fi
	if [[ "$line" =~ ESSID ]]
		then
			echo $line | sed 's/.*:"//g' | sed 's/"//g'
	fi
	if [[ "$line" =~ Signal ]]
		then
			echo $line | sed 's/.*Signal level=//g' | sed 's/ dBm.*//g'
			echo
	fi

done
echo "done"

Alright, let’s walk through that really fast. First thing I do is grab the output of our iwlist command and extract the useful lines (the ones containing Address, Signal, or ESSID), and put all of that into variable $aplist. I then step through the lines one by one and extract only the most useful information.

So the output now would look something like this:

001E4EABCCDF
Sun
-29

Neat. Now I’ve got to come up with a clever way to send it back to our SunSPOT.

head -n 1 /dev/ttyS0 > /dev/null
./ap_scan_and_format.sh > /dev/ttyS0

So now I just wait for the serial to hear a new line character ‘\n’ and then I can pipe the nicely formatted list back to my SunSPOT. Perfect.

Now I need a bit of logic over on my SunSPOT side of things.

        out.write("\n".getBytes());
        do {
            byte[] buffer = new byte[in.available()];
            in.read(buffer);
            read += new String(buffer);
        } while (read.indexOf("done") == -1);

That’s all we need to send the newline character and read in our list of APs.

Now to get that data back to sensor.network. I’m running a project called Yggdrasil on my Spot so that I can report my sensor readings back to sensor.network.com.

A bit of code later and I can get a nice look at how my wifi signal strength varies over time.

How about for all of the access points in the building?

The cool thing about using sensor.network is that I can now, say, try to correlate these readings against humidity, or other sensor readings in the area.

Twitter, Ubiquiti, and Spots

Okay, so if you haven’t yet, please read my last blog post.

Twitter has this great API that makes it super easy to “tweet” (I can’t believe I just used the word tweet). The coolest thing is, you hardly need any extra software, which is a huge plus, especially on the Ubiquiti Nanostation which only has 16 MB of RAM and 4 MB of flash. I read this great guide that uses cURL. Unfortunately, when I tried to install cURL on my Ubiquiti, opkg tried to install a couple MB to my flash; way too much. Curl was not feasible given my limited hardware.

Fortunately, there’s a smaller program that can accomplish the same thing: wget. OpenWRT already has wget installed, but it’s a smaller version of wget that doesn’t have everything we need (it’s actually part of BusyBox).

Now, one of the reasons that cURL is so large is because it wants SSL. We don’t need that, so we can install the package wget-nossl.

root@OpenWrt:~# opkg install wget-nossl -force-overwrite

The -force-overwrite is required or it’ll complain that wget is already installed:

* Package wget-nossl wants to install file /usr/bin/wget
But that file is already provided by package * busybox

Anyway, once we’ve got wget installed, we can post a message to Twitter like this:

wget --http-user=wifispaught --http-password=password --post-data=status="test!" http://twitter.com/statuses/update.xml

Now let’s see if we can’t add a Spot to the mix.

StreamConnection serialStream = (StreamConnection) Connector.open("edemoserial://usart?baudrate=9600&databits=8&stopbits=1&parity=none");
OutputStream out = serialStream.openOutputStream();
out.write(("wget --http-user=wifispaught --http-password=mypassword --post-data=status=\"Hello, world!\" http://twitter.com/statuses/update.xml\n").getBytes());

Okay, we need some code to run on the Ubiquiti side of things:

root@OpenWrt:~# head -n 1 /dev/ttyS0 | ash

This will read a line off of the serial connection (ttyS0), and then pipe the output into ash (a simple shell included with BusyBox). Since the SunSPOT is sending the wget command, there’s no need to do any parsing or logic.

Now I’ve got a SunSPOT posting to Twitter via wifi.

If you’re interested, here’s the twitter feed of the spot.

Ubiquiti and Spots

A significant part of sensor networks, is, well, the network. The radio on the SunSPOT is designed for low power consumption, and works well in relatively short ranges, something like 50-100 meters at the very most. When a stronger radio is required, you’ve got to do something else.

The black PCB in the picture is an Ubiquiti NanoStation2, with a range of several miles over Wifi. Below, of course, is a SunSpot. They’re talking to each other over serial, which is provided on the Ubiquiti (actually, as it would turn out, most routers seem to have serial on the board). To make it a bit easier to use, I put OpenWRT on it so that I could take advantage of their package management (I can run Perl!), and other niceties.

Anyhow, the whole thing was remarkably easy to do once I disabled the existing output on the serial. Apparently OpenWRT, by default, has a console running on the included serial.

I had to edit /etc/inittab and remove the line:

ttyS0::askfirst:/bin/ash –login

Once the serial was free, I just set the parameters using stty, and can now write to the serial using the command

cat > /dev/ttyS0

And read from it with

cat /dev/ttyS0

Writing to serial is easy with a Spot:

StreamConnection serialStream = (StreamConnection) Connector.open("edemoserial://usart?baudrate=9600&databits=8&stopbits=1&parity=none");
InputStream in = serialStream.openInputStream();
OutputStream out = serialStream.openOutputStream();

Pins D0 and D1 are Rx and Tx, respectively.

I think I’ll tie it up with some Perl to report values back to sensor.network.

Hello, World! (USGS, SunSpots, sensor.network and more fun)

Hello, all!

I’m not entirely sure how to start out, so I figure I’ll describe the work I’m doing.

I’m currently (until the end of Summer 2009), an intern at Sun Labs. I decided to host the blog here instead of on Sun’s website because I’ll hopefully continue using the blog after I’m gone. I’m working on the SunSPOT project; more specifically, sensor.network.com. All of this has been described in great detail by another member of the spot team, Vipul Gupta.

Anyway, here’s where I come in.

In the lower left corner of that map is Sun’s Menlo Park office, where I’m located. Look a bit toward the center right of the image and you’ll see a white spot, just below the Bayshore Expressway; we’ll call that area SF2.

SF2 is an old salt evaporation pond, and before that it was a marsh. The USGS is trying to restore this area back to the wetlands they once were. More on that here.

As part of the restoration, the USGS is trying to monitor the area. That’s where we come in. They’ve got a few sensors that they’re going to be putting in the area, which will hopefully be reporting data back to sensor.network with the help of a SunSPOT, so that a researcher doesn’t need to physically access the sensor. Additionally, the USGS is interested in knowing what birds and how many are in the area; a process usually done by going to the site and counting birds for an afternoon a few times a year.

We’ve been playing with cameras, CHDK, eye-fi cards, and Ubiquiti wifi access points in the lab for a while now, and we think there’s a better way to monitor the area.

Our plan at this point is to place several Canon cameras running the CHDK custom firmware in boxes on the Dumbarton Bridge, pointed towards SF2. Each camera will have an eye-fi module that uploads the pictures it takes via wifi to an Ubiquiti access point located at the Sun campus a kilometer or so away. The cameras will take several hundred pictures a day, and the researchers will be able to get a more accurate ‘picture’ of the bird situation at SF2, without needing to spend a day on-site.

Stay tuned: I’ll be posting more information along with pictures and maybe some code soon.