Gone walkabout - GPS wandering correction

It's been a long time between updates!

Unfortunately, a lack of time, as well as dedication to other projects, has lead this project to fall by the wayside for entirely too long - but work has picked up again and regular updates resumed!

During the course of script testing, one of the biggest annoyances I've come across is the tendency of the GPS fix to 'wander' across a small distance from its actual location when stationary.  This seems to be exacerbated when conditions aren't ideal, such as trees/fences/hills or other obstructions between the device and the sky.  Not only does this hinder the ability to detect if the device is stationary, but it also looks rubbish when output to KML:

The above is an extreme example; 484 waypoints collected over a 9.5 hour period.  In reality, I doubt the payload will remain stationary for such lengths.

Fortunately, the device itself gives some clue as to how accurate we can consider a reading to be through the 'accuracy' level associated with the location - this gives us a radius within which the device is located.  If we compare this with the previous GPS location, we can ensure there's no overlap between the two locations(if accuracy_previous + accuracy_current > distance_moved)and determine if a waypoint should be recorded.

Unfortunately, the above isn't always reliable; I've regularly observed the device recording movements slightly outside of the combined accuracy range of the two locations.  To combat this, I've included a user-defined tolerance value (gps_accuracy_tolerance) which will add the specified percentage tolerance to the GPS accuracy value.  In testing, I've found a value of 10% reduces false-positives by around half (following initial error correction).

The next check performed ensures that the accuracy range is within a user-specified value (gps_accuracy_maximum) beyond which the waypoint is discarded - I've set this to 25 meters.  My device tends to report accuracy in multiples of 5; however this does vary depending on the GPS chipset employed by your device.

The result of the above checks gives us a fairly rudimentary yet effective error filtering algorithm, reducing wandering by over 98% - down to 9 waypoints from 484 in the original example:

This algorithm isn't foolproof, however.  If the payload is travelling at a very low speed and the distance moved between each subsequent location update is less than the combined accuracy (usually between 10 and 25 meters), waypoints will be discarded - even if the device continues to move away from the initial location.  To circumvent this, another user defined variable (kml_waypoint_distance) will force a waypoint to be recorded if the device detects movement greater than the specified distance, provided that gps_accuracy_tolerance is within the specified range.

Of course, if the device is actually moving around within a small radius, legitimate locations will be regarded as errors and discarded.  This isn't the sort of movement we're expecting to see, however I have included both raw and corrected KML output functionality within the script.

Testing at altitude

Recently, a friend invited me to take a trip in a small aeroplane from Moorabbin to Ballarat, around 100km west of the city.  This provided the perfect opportunity to test the tracker at altitude - especially the reliability of the live imagery and telemetry.

I've put a fair bit of work into the script since the last update, which is now largely feature complete.  The results were as good as I could have hoped for - as high as 1200 meters (4000 feet), signal was patchy, but still reliable enough for live telemetry and email imagery to be sent, with strength averaging around -86 dBm (around 3-4 'bars' of reception on your average handset.)  With the use of an external antenna, I'm hoping that I'll be able to achieve reliable signal to at least 3000 meters (10,000 feet), which should see around 11 minutes of live imagery and telemetry.  Best case estimates see signal continuing to around 6000 meters (20,000 feet) - but at that altitude I'd expect only SMS-based telemetry to be transmitted.

This was also the perfect test of the KML output, which previously I'd only been able to test at ground level, which produced fantastic results:

One issue I did encounter, however, is the way in which the phone handles roaming to other networks in 'emergency calls only' mode.  The device will continue to report the signal strength of the network onto which it has roamed, rather than reporting no signal.  This causes the script to continue to attempt to send imagery and telemetry, despite the fact that it will never be received.  I believe I've found a workaround for this by checking the value returned by getNetworkOperatorName() - however this will require further testing.  Sadly, I don't think I'll have the opportunity to test this in a plane in the future!

What could possibly go wrong?

Even though I'm taking a keep-it-simple approach to this project, there still remains many variables that are well beyond my control.  These could lead to anything from a small error causing partial data loss, to a catastrophic failure resulting in an unrecoverable payload.

• GPS CoCom Limits:  This is potentially one of the biggest show-stoppers.  The Wikipedia article describes CoCom limits as"a limit placed to GPS tracking devices that should disable tracking when the device realizes itself to be moving faster than 1,000 knots (1,900 km/h; 1,200 mph) at an altitude higher than 60,000 feet (18,000 m)."
  
  The article then goes on to describe the way in which devices enforce these limits:  "Some manufacturers apply this limit when both speed and altitude limits are reached, while other manufacturers disable tracking when only a single limit is reached. In the latter case, this causes some devices to refuse to operate in very high altitude balloons."
  
  Somewhere, in the radio software for the handset, is either an 'and' or 'or' operator, and until the device is taken above 60,000 feet, I've no way of knowing how it will behave when this condition is met.
• Extreme Cold Temperatures:  Electronics and batteries do not  like cold temperatures.  Living in Australia, the coldest temperatures I'm used to seeing are usually on the warmer side of 0°, usually in the low single-figures.  However, at elevation, the temperature very quickly drops into the negatives, and at 100,000 feet, we can expect to see temperatures as low as -60°C - at which there's no chance of anything remaining operative - even the best-rated Li-on batteries are only rated to -40°C.  There's plenty of ways to keep the payload warm, however I'm only able to test to temperatures as low as my kitchen freezer has to offer.
• No Cell Coverage:  Prior to the return of the payload to earth, there'll only be an approximation of the expected landing site.  The trajectory can vary greatly with as little as an hours difference in launch time -  if it appears that the payload will find itself even close to an area void of cell reception, the launch will need to be postponed.  While there are a handful of balloon trajectory forecast sites, there's no guarantee of accuracy - so consideration needs to be given to the fact that the payload could potentially find itself 100 km+ away from the expected landing site.  With cell reception being the only means of contact upon landing, we need to maximise the chance of it remaining within a cell coverage area.
• Landing in Water:  If the balloon bursts prematurely or is blown off-course unexpectedly, there is the risk of a water landing.  Depending on what sort of body it lands in (lake, river, bay or ocean) there still may be a chance of recovery - so both buoyancy and waterproofing of the payload need to be considered.
• Script Failure:  Whilst extensive testing of the tracking and telemetry script will take place, there still exists a risk that the script, SL4A or device itself could crash, permanently severing communications with the payload.  Subsequently, I will need to consider implementing some form of redundancy should such a condition develop.

As testing progresses, I'll devise, implement and test potential mitigation strategies for each of these, and report back om my findings.

Mapping signal strengths

One very useful feature of SL4A is the readSignalStrengths() function.  This exposes the current cell signal strength as value between 0 - 31, representing an RSSI of between -113 and -51 dBm as defined in GSM standard TS 27.007.  This is useful in that it can be used not only to trigger (or more specifically, not trigger) events based on signal strength, but can also be logged to give an indication of what level of coverage is achieved at certain locations and elevations.

Given that the script was already capturing this data, I had the idea of combing this with the KML output to give a visual map of location-based signal strengths:

There's a couple of issues that I've discovered with this, however:

• The signal scale is logarithmic, however the colour scale is linear.  Most devices will show 16 and above as 'full bars' - which is represented as yellow in the above pictures; so anything yellow and above can be considered a strong signal.
• I've tested this on a handful of different devices, and found that many (though fortunately not the Galaxy Y)  will only report signal strengths that correspond to the number of 'bars' displayed to the user (for example, 1, 4, 8 and 16), which makes for a much less detailed map.

At the moment, I've incorporated this functionality as a basic proof-of-concept, though when the time comes I'm hoping to use it for assessing suitability of both potential launch and landing sites.

Scripting with SL4A (for fun and profit)

From the outset, I'd intended to put my software development skills to use in creating an application capable of providing real-time tracking and telemetry , imagery and data logging, as well as payload recovery.  Aside from the requisite Java, I've got extremely limited experience with Android development, making for a very steep learning curve.

Enter SL4A: Scripting Layer for Android.  From their website: "SL4A brings scripting languages to Android by allowing you to edit and execute scripts and interactive interpreters directly on the Android device."  I originally came across SL4A when looking at similar projects. and found one that had used SL4A for this very purpose over on James Devine's Blog.

After weighing up the options, I've decided that Python and SL4A will be the way to go - the learning curve is significantly gentler and the code far simpler, which will subsequently lead to shorter development and testing times, culminating in a more rapid development cycle.  As an added bonus, SL4A has support built into Tasker, which in its simplest form is a powerful task-scheduler for Android which can be used to launch scripts based on various user-defined triggers.

I'm hoping to keep the script relatively simple, while incorporating the following features:

• Data logging:  Coordinates, altitude, speed and total distance tracked
• Battery data logging:  Charging status, battery level, health and temperature
• Signal strength logging:  Cell signal strength including network type (2G/3G)
• Real-time telemetry:  Location tracking via SMS and email (with altitude-dependent update frequency)
• Real-time imagery:  Transmission of images captured through phone camera via email
• KML output:  3D output of balloon flight path (with error correction and visual signal strength indication)

I've been playing around with SL4A for a few weeks now, and have been thrilled with the results.  Most variables are being successfully logged in CSV format, altitude-dependent SMS tracking is working, and most impressively, KML output is fully functional, as tested on a recent trip in the Dandenongs:

There's still a long way to go - some basic filtering of erroneous values need to be applied to the GPS coordinates when the signal is weak; while this is unlikely to be an issue, there's no way to be certain until the payload has completed its voyage.  I've also done some basic proof-of-concept work with image capture and transmission, but this will require some fine-tuning before being ready for go-live.

I'll need to perform extensive testing once scripting is finished - then I'll post the code for all to see (and use at your own risk!)

The brains of the operation - Samsung Galaxy Y Duos

The phone I'm hoping to use for this endeavor is a Samsung Galaxy Y Duos S6102 which was very kindly gifted to me by a friend who'd been using it as a cheap stand-in after losing her usual phone.  I was at their flat one evening and noticed it gathering dust - having had this project in the back of my mind for several months,  I realised it had a number of features that fit the bill :

The reasonably feature-packed Samsung Galaxy Y Duos S6102

• Android 2.3.6 ("Gingerbread")
• 3G, with dual-SIM functionality
• External antenna connectivity
• Lightweight and small form-factor
• 3MP, fixed-focus camera
• Micro SD port

There's a couple of downsides, however.  The 3G support extends only to the 900 MHz and 2100 MHz bands, meaning I'll be limited to the Optus network if I'm wanting to see 3G connectivity outside of the city (that said, Optus' coverage in Victoria is comparable to Telstra's these days, although the difference in the network performance remains to be seen - more on this later.)  The second is Android's lack of dual-SIM support.  As the Android platform has no such native functionality, any implementation has to be done by the manufacturer - meaning there's no API support, and hence no way to force the use of a specific SIM without user intervention.  By no means a dealbreaker - just something that would've been nice to have.

Since getting my hands on the phone, I've rooted it and installed ClockworkMod Recovery to assist with ROM backup and restoration.  I've opted to stick with the stock Samsung ROM, using Titanium Backup and a lengthy process of trial and error to remove all unnecessary bloat from the phone (everything from the stock music and FM radio apps to a host of unnecessary proprietary Samsung APKs).  This has resulted in a significantly more responsive handset, faster boot times and much improved battery life.

Overall, with a bit of tweaking, for a ~$130 handset, it's a solid little performer that's going to see some pretty interesting use.

The (broken) camera - Canon Digital IXUS 70

I bought this camera on eBay around a year ago - a few months before I left the UK - with the ultimate intention of using it in this project.  I chose this model very deliberately - one, because of its dimensions (it's perfectly rectangular, with no rounded surfaces, making for easy mounting), and two, because it's one of many Canon cameras to support CHDK firmware.  CHDK is an aftermarket, open-source firmware distribution that opens up a whole host of features not available in stock form - including a very powerful scripting language that will be invaluable to a project such as this.  Whilst I'm yet to decide on what I'd like to capture, be it still images or video, the ability to create a script will give me the flexibility to switch between the two at any desired interval.

In the meantime, it was due to serve as a backup travel camera; something I could slip into my pocket for days I didn't want to lug my DSLR about the place.  Sadly, that idea didn't last - somehow I managed to break the screen on only its second outing, rendering it completely unusable and seeing it relegated to a bottom drawer for several months.

I've managed to track down an aftermarket screen on eBay for the bargain price of $15, which should be a straightforward repair.  Once it's back up and running again, I'll set about making a custom battery coupler for it to enable me to provide a power from an external source, allowing runtime well beyond the capacity of the standard battery - but more on this later.

Early days...

I've long been fascinated by the plethora of successful amateur attempts at near-space photography that are well-documented across the web, and have frequently toyed with the idea of attempting such a project myself.  I've been overseas for the past two years, and always promised myself that upon my return, I'd embark on such a venture and try, with the assistance of a few friends, to send a small payload into the stratosphere and (with any luck) back.

I'm no rocket scientist, aerospace engineer, meteorologist or really anything that gives me any insight into such an endeavor, but I do have a few ideas on what I hope to achieve:

• Low Cost:  Most components will be cheap, off-the-shelf components or stuff I already own.  Many others have achieved tracking through the use of a Raspberry Pi - I hope to achieve most of what I want to do with a small point-and-shoot camera and basic Android smartphone.
• Real-Time Tracking:  The one useful skill I do have is software development.  Unfortunately, this doesn't extend to Android as yet, so I'm taking this as an opportunity to brush up on my Android development skills in order to create an app that will be able to provide real-time (within cell coverage limits) tracking and imagery, and hopefully assist in the recovery of the payload upon its return to Earth.
• Altitude and Flight Path:  I'm based in Melbourne, Australia.  At present, I'm hoping to launch the balloon from the Mornington Peninsula, when weather conditions are favorable for a flight east across the state, allowing capture of imagery across Westernport Bay and South Gippsland, to an altitude of between 25,000 and 35,000 meters.

Hopefully, I'll have everything together and ready for launch by sometime in late autumn or winter of 2014.  In the meantime, I hope to document everything from equipment gathering and testing to payload prototyping and application development.