An Arduino-based solution for PROJECT BALLOON | Miscellaneous | Forum

I'm posting this here because there currently isn't a dedicated part of the forums for PROJECT BALLOON.  Once the names are chosen we'll need to do this (assuming we want to stick with the forum system), at which time this can be moved.

I've been doing a little bit of learning about the Arduino boards and their extensions ("shields") as well as how to program these things.  I've taken a real shine to Arduino, and in this post I'm going to outline what I think might be an effective and fairly straightforward way to handle the electronics for PROJECT BALLOON.

I'll start with a very quick overview of the Arduino boards and Arduino  shields.

Each Arduino board comes with a fixed number of digital and analogue input/output pins.  Here's the current basic Arduino board, the Uno.  You can see fairly plainly the 14 digital pins along the top and 6 analogue pins along the bottom.

You can connect whatever you like to these pins in order to do stuff.  It's very common in the Arduino world to buy things called "shields" which are extra boards which sit ontop of your Arduino, with pins slotting into the digital and/or analogue pins of the Arduino below it – just like sticking a PCI or AGP card into a motherboard, for instance.  Here's a picture of an LCD/keypad shield sitting atop an Arduino board.  You can see fairly clearly the connection between the shield and the board's analogue inputs:

Now, typically you attach a single shield to an Arduino to do something, but there's (sometimes) nothing to stop you stacking shields on top of shields, so that you can get monstrosities such as this:

This kind of super stacking will "just work" if the different shields all use different I/O pins on the Arduino board.  If multiple shields use the same pins, you need to put some extra layers between them to redirect the pins (and change your software to reflect this).  It's inconvenient, but not  conceptually difficult or hard to get right.

Now, for PROJECT BALLOON: I've found the following shields at SparkFun:

• A GPS shield, which you solder a standard GPS module into so that you can read positions
• A microSD shield, which you can put an SD card in and read/write to it
• A cellular network shield, which you can use to make calls, send SMSes, etc.

Based on SparkFun's descriptions of which kind of and how many I/O pins these shields use, I believe it is possible in principle to stack all 3 of these shields onto a single Arduino Uno board.  With the right software, this would let us create a fairly small box of electronics which functions like this: you turn it on and it starts reading GPS coordinates; every 10 seconds (or whatever interval we like) it writes a timestamped set of coordinates to a .csv file on the SD card; every 10 minutes (or whatever interval we like) it sends an SMS of the current coordinates to one or more predefined phone numbers.  It just sits in this loop until you turn it off or the batteries die.  This is, I think, all of the basic navigation and communication features we would need for the very first stage of PROJECT BALLOON.  We could attach this box plus whatever payload we like to a balloon and let it go and (unless we are somewhere remote without cellular signal) find it again later.

The total cost for all the components needed to build this (an Arduino Uno board, the 3 shields and a basic GPS module) is about US$225 – not too bad.  I also think this approach is pretty compatible with our social contract and design philosophy – the Arduino boards are open source hardware, and we're doing very little actual building ourself by using off-the-shelf shields.  The only electronic design which might be involved is re-routing the connections from the shields to the Arduino board to avoid pin conflicts – very simple.  We're not designing our own circuits or anything.

With regards to future extension, this stack of shields would, I believe, use only 9 of the Arduino's 14 digital I/O pins, meaning we have 5 left which we could use for temperature/pressure sensors (for instance) or, at later stages of the project, to connect to a non-cellular communication system (something ham radio-ish) and/or to accept arbitrary data from a secondary payload.  Note that if we run out of pins we can buy an Arduino Mega for an extra $20 – it has a total of 54 digital pins and 16 analogue pins, which is more than we could ever need.

In addition to the hardware side of things seeming very straightforward – kind of like lego, really – I've had a brief look at the software side, and that seems relatively easy too.  I'd volunteer – with confidence – to start building this device myself, learning as I go, and expect to have the basics working in a few months, if I didn't know full well that it would take over my life until it was perfect, which I can't afford right now.

Does anybody have any compelling arguments to not approach PROJECT BALLOON in this way?  I know that in the past we have discussed using Smartphones to do this.  This could well be cheaper, but for one thing it is less open and for another thing it's probably less extensible, when we come to consider things like input from sensors or the use of non-cellular communications.

If people think this looks like a promising way to go about the project, then, once the project has a name and some clearer requirements/stages, it might be a good idea to make a post on /r/arduino at Reddit (867 subscribers, seems moderately active) asking (i) for people to confirm that this would all really work the way I think it would, and (ii) if anybody is interested in helping design, build and test such a device if we provide some or all of the funding.

Thanks a lot for finding that ham shield!  I agree that ham is more capable and open than cellular.  The only reason I didn't address it much in my post is that I didn't imagine there would be ham shields like the one you found.

I have always thought that the later stages of PROJECT BALLOON should feature both cellular and ham because, as you say, they complement each other well.  Ham is much more capable (e.g. if we want to relay arbitrary data from secondary payloads, ham seems to me a much smarter idea than cellular), but cellular is super simple – everybody on the recovery team for a launch is likely to already own a cell phone, and nothing else, like directional antennae, are needed.  The learning curve is zero.  Using cellular only for the first stage and then adding ham to a later stage makes sense to me, but of course this is up for discussion.

That stuff you are watching on eBay sounds to me like it would be helpful, but I'm not that knowledgable about ham radio yet and I'd hate to encourage you to buy something that you later find to be not useful just because it sounded exciting to me.

With regard to simple instrumentation, I think SparkFun should have us covered there, too.  E.g., here's a digital thermometer and digital pressure sensor.  They're both fairly cheap and small.  They also have small and cheap CMOS cameras which could be handy, too.

It's absolutely fantastic that you're willing to volunteer to lead this project, that will hopefully do a world of good for making sure things keep rolling.  Everything Arduino related is free as in freedom and Linux-compatible, too, so you should be able to avoid any moral conflicts.  You'll also hopefully have some project Meteor folk to get advice from as well.

Re: Camera resolution – The CMOS camera I linked to earlier can do 1280 x 1024 resolution at a maximum, I don't know if we'd be satisfied with that or not.  Regardless, reading the comments for it on SparkFun it seems like the supposedly excellent manufacturer's documentation is actually inconsistent with how the device actually works, and is also in Engrish, so perhaps we should give it a miss.

Re: GPS maximum altitude – Very good point.  The GPS shield linked to above is designed to "just work" with this GPS module, on which someone has commented:

***PUBLIC SERVICE ANNOUNCEMENT: THIS UNIT WILL NOT WORK AT AN ALTITUDE OVER 18000 METERS (60000 FEET)***

This unit uses a Sirf-III GPS chipset has a limitation that buyers
should know about. THIS UNIT WILL NOT WORK AT AN ALTITUDE OVER 18000
METERS (60000 FEET). This doesn't matter to most people, but is
important to hobbyists that take part in high altitude weather
ballooning, amateur rocketry, etc. Someone I know mistakenly purchased a
Sirf-based unit for ballooning and I'm hoping to save people from
making the same mistake.

I'm going to post this in the comments section of all the Sirf-based
Sparkfun products in the hope of saving someone from from making the
same mistake. I apologize if the Sparkfun guys consider this spamming,
that isn't my intent. It, also, isn't my intent to drive business away
from Sparkfun. They have an awesome collection of GPS products and many
of the other modules don't have this limitation.

So that GPS module is a no-go.  However, the shield says it is compatible with others, which may not have that limitation.  SparkFun's GPS buying guide makes it sound like all the modules work more or less the same way, so it should not be too hard to get a high-altitude GPS module working with the shield.  There's a comment on this module which suggests it may be suitable for ballooning.

Re: SMS and Twitter on Arduino – J., that library looks really nice, I was expecting that one of us was going to have to learn the AT command language to get SMS working, but if that can be abstracted away from, all the better.  The Twitter messaging idea is a great one, too, that never would have occurred to me.  It would be good for publicity, in that even people not on the tracking and recovery team could follow the flight's progress.

Re: Using Redmine – I had  been having similar thoughts for CSTART, actually.  With our 4 new projects looking likely to have names, logos and project leaders in the near future, now would be an opportune time to "reboot" our web infrastructure too.  I don't think forums are super well suited to engineering, and I also worry about WordPress' forum software's scalability to a large set of projects – we will start having forum namespace clashes eventually, I think.  Using Redmine as a stand-in for ODE might be a good idea.  It would also encourage development of ODE from Redmine.  Now that there seem to be a lot more interested people on /r/tothemoon, we may be able to find some Ruby hackers willing to help.

Okay, starting to understand things better.

The GPS shield is not designed for that altitude-limited GPS module per se.  It is designed for a specific kind of connector cable, the EM 406, which the altitude limited GPS module uses.  If you look at the GPS shield, you can see, in the bottom right, a 406 connector.  Next to it is a space where you can solder on a 408 connector if you have a GPS module which uses one of those.  The idea is, I think, that you just stick the pins of the GPS module into the large pinned area in the middle, and then plug the cable from the module into your 406 or 408 connector.  The large pinned area, as you can see, isn't actually connected to everything else.

Now, the Venus module doesn't come with a 406 or 408 connector cable.  It comes as just a naked chip that you have to hook up yourself.  However, SparkFun do sell this, which is just the Venus module soldered to a tiny board with connections from all the module legs to nice easy to use connectors (this kind of board is called a breakout board).  In addition to breaking out the Venus module pins, the board also has an SMC connector for attaching an antenna – the Venus module does not have an onboard antenna like the altitude-limited one linked to above.  This is unfortunate in that we have to add the cost of an antenna, but they seem fairly cheap.

Now, back to the GPS shield – note that all the tracks running away from the 406/408 connectors run through some connector points labelled TX and RX (transmit and receive) and 5V and 3.3V (power sources).  There are correspondingly marked connectors on the Venus breakout board.  I believe if we just ran wires between corresponding connectors, everything should work.

That said, in this configuration the GPS shield is a largely unecessary middle man.  Looking at the tracks on the GPS shield, it appears that all that shield does is connect the Arduino board's 5V and 3.3V power pins to the corresponding power pins of the GPS module, passing them through a button and a switch for on/off and reset capabilities, and connects the GPS module's TX and RX pins to the Arduino's hardware serial pins D0 and D1 or, if you flip a switch, to any two other pins (the two little solder blobs marked 2 and 3 next to the hardware/software serial switch are clearly just intended for you to run wires from them to two other digital I/O pins of your choosing).  It's really that simple.

Considering that we don't (I think) actually need on/off and reset capabilities for the GPS module independently of our entire avionics box, and that we're not going to want to switch back and forth between hardware and software serial, using the GPS shield is a waste.  We can just buy the Venus breakout board and run wires ourselves from the Venus module's 5V, 3.3V, TX and RX pins directly to the corresponding pins on the Arduino board – this is a really simple job, it would just require 4 soldering points on the Venus breakout board, on the Arduino side we wouldn't even need to use solder if we could find some wires which ended in pins that could be inserted into the Arduino's headers.

All of this raises the question of just what all the other pins on GPS modules do if the power pins and serial TX/RX are all you need for basic functionality (I can see one marked "BAT" which is obviously for a backup battery), but I suppose it doesn't matter much.

Note that the cost of a GPS shield and the 406-connected altitude-limited GPS module is US$77.  The Venus breakout board costs US$49.95 so unless a few bits of wire and a GPS antenna with an SMC connector cost US$27, this new option is going to be cheaper – and it gets us a better GPS module and probably saves a bit on weight and space, since the Venus breakout board is cheaper than the GPS shield.