 So, good morning. Thanks for coming to this session. For those of you who have not heard me talk sometime in the week or who are watching on the streams, I'm BDL Garby. What I want to talk about today is the experience that Keith Packard and I have had working together for the last couple of years, turning one of our hobby obsessions into a small business. And in the process discovering that it wasn't enough to have software that works brilliantly on Debian or even in fact on Linux, but that when we started to sell bits of rocketry electronics to other people, they actually had this strange expectation that the software would also work on platforms like Windows and Macintosh. And because we're very interested in having other people able to use our electronics, we actually completely rewrote the software that we had started with and we now successfully for three or four iterations of major releases have been delivering software that has exactly the same functionality on all three platforms simultaneously with very little pain. And I want to talk to you sort of about some of the decisions we made and how we were able to do that. I must be completely clear about this. The software part of this project is more Keith's work than mine. Within the work that we've been doing together, I have the really pleasant opportunity to be the hardware guy for a change. And I've taken full advantage of that. And Keith has done essentially all of the firmware for the flight board and has led the development of the ground station software. Though as you'll see as we go through the rest of the talk, we've had some interesting collaborators and clip contributors. And actually some of our earliest customers are people whose names you're likely to recognize. So before I even dive in, Altos Metrum is the name of the little project community we started for turning our ideas into realities. It's now also the name under which we sell stuff. That is one of my rockets. It's a historically significant one. It's that rocket that really led to my decision to build my own avionic solutions. That rocket is one that I built to be my first attempt at a level three, which is the highest level high power rocketry certification in the United States. To give you a sense of scale, that airframe is 102 millimeters and outside diameter. And the airframe is about three meters long. It was flying on an M class motor, which is a lot of propellant. And as you can see, during its ascent, the flametail out the back of the rocket was longer than the airframe itself. And it was really quite beautiful on the way up. The sad sad story is that the parts of that rocket I got back are the ones that are red. The golden black pieces never came back. And I don't mean they were damaged. It looked like a beautiful flight. But due to an odd combination of errors, not the least of which was a bug in the firmware of a commercial altimeter board. The parachutes all came out up at the top of the flight instead of down low where we had hoped they would. And the rest of that rocket ended up lost. And the problem is that rocket flew on a weekend that was also the opening weekend of hunting for antelope in that part of the United States. And I'm pretty confident that some guy who was not able to get an antelope went home with a pretty rocket to put on his trophy wall. I don't know this. I'll never know what happened. But I didn't like losing this airframe. I spent several months. The fins were made from carbon fiber in my first personal experience, vacuum forming carbon fiber and so forth. So anyway, that rocket is in many ways sort of directly responsible for all of the work that I've been doing since to create really high quality avionics for rockets. And that's the stuff that we have been doing software for. The software is called Altos. And Altos UE is the user interface for it. But before I dive into talking about all of that, how many of you were at Dubcon from New York last year? Do you remember us crazy guys sitting around in the hack lab building rockets? This is Edgar Bessar and Anthony Towns, both of whom joined in in that whole process. And our friend Saphir, of course, was totally enthusiastically engaged in this whole process. And it was great fun to watch him working on that and even more fun now to have a chance to see a little bit of Bosnia, which he kept enthusiastically telling me last year was a place I absolutely had to come see. And after he put things together, this is on the launch weekend that we attended together at the end of Dubcon for Saphir with one of his rockets that came back in good shape. It was Edgar getting ready to launch the rocket that he built. He actually successfully achieved a level one high power certification that weekend, which was unexpected, but pretty cool. Part of the reason it's cool is you notice that's not a very large rocket. And in order to achieve a high power certification, he had to fly that on sort of a ridiculously large motor for that sized rocket. And he did this on an afternoon where it was starting to get windy. And in fact, when the parachutes came out, the rocket took off. The wind was carrying it downrange very quickly. And many of the people at the launch site were sort of, you know, sadly saying, gee, Edgar, that was a nice looking rocket. But what they didn't know is one of our boards was mounted in the nose cone. And so through the entire flight, we had a live radio link to the ground with GPS information telling us where the rocket was. And so in fact, we were able to find it, recover it in the edge of a pumpkin patch in an adjacent field. We couldn't see it until we were within about 10 meters of it buried down in the vegetation. But we were able to successfully recover it. It had flown beautifully, no damage. And he was successful at achieving his high power level one certification, which was pretty cool. This is one of my rockets. Unfortunately, this photo is maybe a little hard to see on the screen. Be easier if I had blown it up some. But that's one of my rockets, the one that some of you saw me walking around Columbia University with. Big pointy thing about this long descending under the dual parachutes. And this is the crowd that spent the weekend there. And in addition to me, there's Saphir and Edgar and AJ and Keith. And unfortunately, I don't remember this guy's name. But anyway, we had a great weekend, flew lots of rockets. And later in the summer before he left the United States to go back to Australia, Anthony Towns, also known as AJ came by and spent about a week or so at my house, built another rocket, took it to a launch with me in Colorado. And in one day in two flights, successfully achieved his level one and level two high power certifications, which was really cool. And then since then, he and Michael Beatty, who many of you know as Omnic on IRC from New Zealand, helped us to plan and execute a very successful rocketry mini con at Linux Conference Australia in Brisbane this January, where we had 24 people who each put together a rocket. Several of them use our electronics, others of them used some custom hardware that was designed and assembled during the Arduino mini conference at that same event. And again, went out and spent the weekend flying with us. So I won't be labored as you know, you guys pretty much know who Keith and I are. The part that you probably don't entirely know is that we're both deeply experienced system and infrastructure software guys. And producing open hardware and open source products related to our shared hobby rocketry obsession. It sort of feels like a natural thing, but neither one of us really has very much experience writing user interface software. And in fact, I think both of us would say we're not very good at that. And neither one of us really had any significant prior experience working with Java. And you should keep that in mind given what I'll tell you about what we ended up doing. So in some sense, we were people who had a need and a strong basic sort of understanding of this kind of technology. But we're really sort of going down a path in directions that that we didn't know. So what's the basic idea? Well, in case you haven't already figured out, we like to build launch and successfully recover hobby sized models of rockets. And part of the reason this is so much fun is that it brings together lots of different things that we're interested in. There's lots of engineering work that goes into planning the missions that we're going to try to accomplish and designing the actual rockets, the vehicles. There's an element of physical craftsmanship because we're making these things from cardboard tubing and bits of fiberglass. And as we get more advanced from carbon fiber and machining pieces of wood and aluminum to use for spacers and internal structure. For me, it's been an excellent excuse to take my son camping. You know, maybe it's not immediately obvious, but when you fly big rockets, you don't tend to do them very close to population. In the United States, we're fortunate that there are lots of wide open spaces that we can go to to get away from population, to get away from the normal aircraft travel routes, where we can get permission to hold launches. And when we do that, we're often fairly far away from civilization, so to speak. And it's been an excellent excuse to take the camping gear and set up and do all of that great, you know, father and son outdoors kind of stuff and we get to fly rockets. They really is a visceral thrill that's associated with every launch. No matter how much we talk about the science and the engineering and the craftsmanship, there's just something really amazing about getting to the end of the countdown, pushing the button, having the motor ignite and seeing something leave the ground on a huge flametail headed for higher than the eye can see. And then as we go through this whole sort of hobby, as our objectives with our flights become more advanced and as we start to fly bigger rockets, bigger motors and all of these sorts of things, in the hobby you inevitably start dealing with electronics and software. There's really no choice. You know, kids that are building little, you know, Estes or other model rockets and flying them. They're unguided, they have no electronics, the little motor burns a little bit, pops a parachute out, it comes back down. Even that's really cool. But when you start building things that you spend six months or nine months or two years designing and building and you take them out and you fly them on ridiculously expensive motors and they're going to crazy heights and you're trying to collect some particular kind of data and you want to get that data back. Electronics ends up being an important part of the process. And, you know, so what do we use the electronics for? Well, first of all, as I say, to collect flight data. The first question that every little kid asks when they see a rocket go up is, gee, how high did it go? And of course, if you have things like barometric air pressure sensors, you can use those to determine how high something went above the ground. If you've got GPS, this is another possible approach for doing that. Another thing is to control the recovery system. These are not intended to throw away kinds of rockets. These are rockets that we fly and we recover and we fly them again and recover them. It's an absolute certainty in all hobbies that involve flying models, whether they're airplanes or rockets that the question is not whether it's going to break, but how long before it's going to break because eventually something always goes wrong and you always lose things eventually. But if you can stretch out the amount of time between designing something and building it in that final ultimate moment of disaster, that sort of the goal. And so when we talk about a recovery system, we mean things like the parachutes. If you put a rocket up and it goes very high, one of the things that we like to be able to do is to control multiple recovery events. So maybe at the top of the flight, we separate the airframe and put out a tiny little parachute so that it doesn't just come back holistically like a projectile, but instead comes down in a more controlled fashion. But you don't want it to come down too slowly because then the winds at altitude will push it farther down field. Instead, you like it to tumble down fairly quickly. And then when it gets closer to the ground, you have another event that puts out a larger parachute so that the remaining parts of the rocket settle down gently and can be recovered and used again. And then no matter how high it goes, there's always the question of recovering the airframe and finding it. Where did it go? In our case, this is accomplished most often using GPS, sometimes just using radio beacons and radio direction finding. So why did we get started on this Altus Metrum thing? Well, as I mentioned before we came along, most, if not all of the existing altimeter solutions were completely proprietary. There were some other, is that me? Whoa, it is. Somebody in Montenegro. It's the fun of being on a local sim. I have no idea who's calling me. Sorry about that. There were some existing projects to build noncommercial altimeters, but none of them were very satisfying. They were either really simple designs being put together by people who did not have a really strong grasp of the electronics and the software that was required. Or we actually had some friends who were doing really brilliant designs, but they weren't planning to make them available to other people. They were happy to, you know, talk to you about it and maybe share their ideas, but they weren't actually doing anything that you could participate in very easily. And so we decided to collaborate on a completely open hardware and open source, highly optimized solution to address the specific needs that our rockets had. And it turns out in the process we seem to have ended up with something that lots of other people in the rocketry hobby are also interested in being able to use. The hardware on this thing is sort of interesting. No, it doesn't run Linux. The entire design is based on a RF system on chip produced by Texas Instruments. It's actually the part of Texas Instruments that used to be called ChipCon. And it's a micro controller, an 8051, sadly, with some flash memory and RAM and lots of other IO. But the really magic piece is the digital radio transceiver. It has all kinds of really useful features for this kind of work and is capable of generating a transmitted signal at the 10 milliwatt level on a wide range of frequencies below one gigahertz. We happen to operate this in the range of 435 megahertz. To that, we added two megabytes of flash memory for storing the data that we're collecting during the flight and various sensors. We have a barometric pressure sensor, 50G accelerometer, a GPS receiver, and we have support for initiating up to two pyrotechnic charges. What this means is we have a FET switch that we can use to put current through an electric match that starts a little bit of fire that ignites a small black powder charge and generates enough gas to separate different parts of the airframe and put out the parachutes. And one of the things we chose to do early on was to use lithium polymer batteries because their energy density is very high and they don't weigh very much and they're small. And we have complete support built into the hardware for charging those over USB. And so this is what the circuit boards look like to give you a sense of scale. The small dimension is an inch, so that's about 25 and a half millimeters. And the length of it is two and three-quarters inches. That works out to be, what, about 68 or 75 millimeters, or somewhere between 65 and 75 millimeters. So these are, the boards are about that big. And all of this stuff, as you can see, is done in fine-pitched surface mount. And they've worked very well. We're now on about our fourth revision of the hardware. And the current, this is actually version 1.0, we're now on 1.1. And I think in total we've sold a couple hundred board sets of these to other people in the hobby now. So what about the software? Well, the software that runs on the actual circuit board in the rocket is very constrained. It's implemented in, you know, that's really annoying. I wish I could figure out how to turn this phone completely off. There it is. That. Okay. Yes, shut down. Okay, sorry about that. Someone in Montenegro really wants to get my attention. So the software that runs on the actual flight boards is, it's essentially a little real-time operating system that Keith wrote from scratch, specifically to meet the needs of this project. However, it's got some interesting characteristics. And if you're interested in that, you're certainly welcome to go take a look. All the firmware is also in the same repository as the ground software. And it also is completely covered under GPL v2. You're happy to take it and do what you'd like with it. When we started writing on the ground station software, I think the first thing I can say about it is it was a lot harder than we expected. And the part that was harder is that I think because of our history of involvement with various projects in the open source world, we somehow thought, oh, there's all this great software out there with decent user interfaces that runs on Linux and under X. And it can't be all that hard, can it? And it turns out in fact that it actually is fairly difficult to write C software using GTK plus and create really great user interfaces. You know, there's there's really the whole sort of technology stack encourages you to do your user interface development using a GUI tool, but the tools, you know, often don't do exactly what you expect. One of the things that bothered Keith a lot is that in trying to design the user interface, the fact that using the C toolkit with the GLIB based objects system really meant that you're writing code in a language and using a toolkit where the underlying language doesn't really support the data model that's in use by the user interface toolkit. And this means that, you know, there's all these obscure macros that you have to use to access the methods and members. And there's a lot of things that you can get wrong. And frankly, after staring at the stuff for a while and trying to help him understand why what he'd written wasn't working right, I have a new found appreciation for why there are so many weird and obscure bugs in some of the software that we deal with on our distribution on a regular basis. It's also the case that a lot of type errors in the data that you're passing around don't really get exposed because of this until runtime. And so things that, you know, it feels should be possible to detect at software development and compilation time end up being runtime warnings. And, you know, the explicit memory management shared between the application and toolkit happens in sort of non obvious ways. And I guess just as a general problem, you have to have a lot of architecture knowledge about how the toolkits put together, how the whole interface paradigm works before you can write even the simplest program. If you go take a look at what's required to do a hello worldish kind of program in this environment, there's a lot of stuff there. But we navigated that and we ended up with, you know, a stunningly beautiful user interface. And really, you know, for quite a while, this is the kind of stuff we were using. It's a tabular presentation of the raw data that we're receiving in the packets from the boards on the rockets. And the most important thing that was happening is all of that data was also being logged out to files on the notebooks hard drive so that later we could perform various kinds of processing and analysis. And in our first generation of software, the user interface during flight was about this simple. And a lot of the things that we did were done using command line utilities that you would run on the data after the flight. If you wanted to generate plots of the data, if you wanted to do any sort of statistical analysis on it, if you wanted to generate a plot that you could take to Google Earth and rotate in three dimensions and see what the path of the rocket through its flight had looked like. All of those things were done with small command line utilities that would process the data that was saved by this user interface. And, you know, that was OK. There are a couple of neat things that we did, though, that really sort of changed our thinking for the future. One is, I don't know if you can see at the top, but there's actually a tab in that menu that says voice. And we realized early on that there was a library of text-to-speech translation built around the festival toolkit that was surprisingly easy to use. The voice that it synthesizes sounds a little bit like Stephen Hawking and not as much like, you know, not as nice as you might really wish for. But the ability to have this software running on a notebook while you're holding an antenna aimed sort of in the general direction of the rocket, but not having to watch the screen because it's using the voice synthesizer to report the important flight state changes so that you can actually watch the rocket while it's flying was surprisingly cool. And to the best of my knowledge, we were the first people to put this into any sort of open source software in use in the hobby rocketry world. There are other people who had done neat things like putting a speech synthesizer in the rocket associated with their electronics and transmitting it to the ground over a voice radio link. But and while that's while that's pretty cool, and it in fact provides, you know, really interesting experiences for the people observing the flight on the ground just isn't quite the same thing. And I can tell from the chuckles that those of you here understand immediately why that wasn't satisfying to us. So then, you know, a strange thing happened as I said along the way, we all of a sudden in, I guess, the fall of 2009, we got to the point where things were working well enough that every time Keith and I went to a rocket launch somewhere, and we're using our stuff, people would come over and they go, Oh, wow, that's really cool. Where can I get one of those? You know, where do I buy it? Can I have that too? And so when we were together in Wellington in January of 2010 for Linux conference Australia, we spent a lot of time in the evenings that week, sitting up late talking about it. And somewhere in the middle of that week decided, Okay, what we have really maybe is good enough that it's worth making a few to sell to some of our friends in the hobby. And at that point, you know, you think, Well, great, you know, go build a few sell a few life is good, right? Unfortunately, when you make this transition from a hobby to a commercial product, even if it's sort of a informal product that you're making and selling in your basement, we discovered very quickly that even some of our best friends in the in the rocketry world are ardent windows and Macintosh users. And we, you know, you have to decide which problems you want to solve at any given moment. And what we realized was that would be very interesting if we could actually deliver ground station software, which would work across all of those platforms. One of the other things that we realized in that process, though, was that not everyone that we would like to be able to share our development work with in the hardware was likely to be as enthusiastic about dealing with little command line utilities as we were. And so in the end, we made the decision to completely rewrite all of the ground station software in Java. Why do we use Java Well, we had this really strong desire to not have to reimplement things all the time and a really strong desire to reduce sort of the overhead process of dealing with these other platforms. And frankly, we went and talked to all of the smart people we knew who do user interface software. And after listening to us spout on about what our problems were and how much we loathe trying to do things in the GTK plus and C environment, what our frustrations and challenges there had been, even people who knew us well said you really should just do this in Java. And in the end, we decided to give it a try. But it wasn't without challenges. And the biggest challenge honestly was one that completely took us by surprise. It never occurred to us that this was something we would have to deal with and would have to solve because the hardware that we produce has USB interfaces. And, you know, we have our own vendor ID. Actually, we share the sort of FSF quasi assigned, not really officially legal USB vendor ID. And we have a bunch of different USB product ID so that each of our products is individually distinguishable on the USB bus. And on Linux, the obvious right thing to do in the user interface was to go look on the USB bus and find where our devices were and present our devices in our user interface to our users. There's just no way out of the box to do that on a Windows or Macintosh system from an application written in Java. I couldn't believe this. I even as recently as Fosnem this year, I just assumed that we must have not figured out the right magic. And as Tom can attest in the free Java developers room at Fosnem this year, when I talked about this, everyone went, you know, shame, shame, you're right, that's not easy. And so what Keith ended up doing was writing a little bit of custom C code to implement what amounts to a little shim library that would allow Java to interact with a class that understood the underlying USB access mechanisms. And in the process, you know, he had to do quite a bit of work. He had to understand how all of that worked, how the USB stack and so forth worked on the different operating system platforms, had to learn how to do Swig wrappers and had to get all of this working before we could really do anything useful. And, you know, in 2010, I think we really, as I said, we're totally surprised by having to do that. You know, I asked people, what do you normally do if you have a USB device that presents itself as a serial port and you want to get a file handle to talk to that device. And they said, oh, you put up a dialogue box with a list of com one through com whatever numbers under windows and you just have the user pick it. Well, how do they know which one it is? Anyway, I'm pleased. So this is all working. And if anybody else is interested in it, that little shim library is in our code base and is available. We've never tried to, we've never been motivated to try and package that up and make it available separately, but refactoring that little bit out and using it elsewhere could happen if folks are interested. So some of the good things, as Keith says, we get to do all of the work in Emacs. We can code in raw Java and use familiar build tools by which we mean things like make and the autocont tool set and so forth. And he found that it was really easy to get started with the simple UI classes. It took a whole lot less time to implement the same functionality that we'd had in our version one user interface than it originally took to create that. And in this case, as you can see, it wasn't like it was a hugely complicated user interface. It's really just that the things that you're trying to do, simple interfaces are possible to do with only a little bit of knowledge of the system. And as you want to do more things, you can learn a few new classes and each time you learn something new, you get to go a little bit farther and do a little bit more work. There isn't as much that you have to learn before you can do anything as there was in the other environment. There are a couple of other things that were really sort of essential to making this work well for us. One of them is that the festival subset called Flight, which we had been using in C, someone at Sun, I think it might have been an intern or somebody I don't really know, had completely rewritten the Flight Core interpreter in Java and released it under the name FreeTTS, Free Text to Speech, I think is what that stands for. The only problem is FreeTTS was not packaged for Debian. And the reason is that in addition to having the core interpreter, it also had a skeletal implementation of the Java Speech API. And unfortunately, the Java Speech API is one of the APIs that the Sun folks never re-licensed and released as free. And so the upstream packaging of FreeTTS included both the open source free software good implementation of the core text to speech engine, but it was also encumbered with this big pile of source code that was not under a suitable license. I was so frustrated with the fact that this wasn't in Debian that I went and unraveled all of that and discovered that fact. And as a result, did do the work to package FreeTTS for Debian and the package that's in Debian just elides the entire Java Speech API because, in fact, our application doesn't need it. We're completely happy to just directly pass it text strings and have it turn those into speech. And that all works just essentially the same way it did with the C flight library. And I'm really quite pleased with how that turned out. The other thing is that we knew that we needed to have some kind of plotting interface for being able to look at graphs of the data after flights. And the J FreeChart class library was absolutely wonderful in helping to make that easy to implement. Anthony Towns actually dove in and figured out the interface to J FreeChart and wrote the initial Java graphing subsystem that's part of our software that's now been enhanced and worked on by some other people as well. But J FreeChart certainly dramatically reduced the amount of time it took us to get the ability to generate zoomable and panable graphs of the data that we were capturing. And there are lots of libraries to do charting in lots of places. This is actually one of the better ones we've seen. And in the end, I think using Java really has exceeded our expectations. It was easier to write user interface code in Java than we had expected. And once we got over the hurdle of creating that little Cshim library that we need for each operating system, the Java code that we write is completely platform independent. We write that code once and we don't recompile it or tweak it or change it in any way for the other platforms. The free TTS library works just fine. J FreeChart worked just fine on Mac OS. There are recent versions of Mac OS in Windows. The one challenge we've run into is that, of course, the Macintosh operating system folks bind a particular implementation of Java, a particular version of that into a given software release. And so, unfortunately, some of the older Macintosh systems that are out there, particularly some of the older Mac notebooks that people immediately look at and say, wow, that would be a great thing to use at a rocket launch because it's older and I don't care so much if it gets hurt, it's actually hard to get a new enough version of Java installed on the older Mac OS versions to be able to use those. But we don't have the problem in Windows because Windows doesn't include Java, so you have to install it separately and the Sun Now Oracle Java folks have done a good job of keeping up with fresh versions even for older versions of Windows. We have a few lingering frustrations. I won't spend a lot of time on this, but you know, on Debian, the right thing to do is to package the libraries separately. In fact, there's quite a bit of policy around how to do this. There's good helper toolkits for packaging Java class libraries and we use the Debian packaging system in the normal way to manage the dependencies. Unfortunately, that only works on Debian and in the rest of the Java world, it seems to be the case that the expectation is that every application comes with all of the Java code for everything it needs wrapped into its distribution. And so we end up creating something we call a fatjar that contains the class libraries that we're using and that means that the download and installation process for Mac OS and for Windows is a bigger thing to download, but it does mean that it's a single simple install and it all does work at the end of the day. The gridbag layout tool is probably as baroque and strange as anything we've ever seen, but it does work. The, you know, again, I won't belabor all of this, but in order to keep the code reasonably modular, Keith's ended up creating a lot of synthetic objects and this notion of sort of one public class profile is a little annoying when you like to work in a traditional development environment of Emacs and shell-based build tools. So, you know, what have we learned? Well, using Java's been a surprisingly good approach for developing user interface software. I don't think that we anticipated that. It's the reason we didn't start there. And, you know, Debian does include all the packages that are necessary for compiling platform-specific shim libraries for use on Windows and Mac and at the end of the day, you know, we don't try to compile those things all the time. We carry, you know, binaries of those shim libraries around to make it easy to package and release our software. But I think sometime soon, we actually will take the ground station software and as soon as we do a little bit of refactoring to separate out the architecture dependent and architecture independent portions, I believe that sometime in the next few weeks, we will very likely upload this ground station software package into the main Debian archive. As a consequence of that, we will all of a sudden have support for people who wanna run Debian on other architectures on the flight line, which of course is a wonderful way to solve the problem with those old Mac machines. So if you wanna learn more about this, all of the stuff we've done is licensed under the Tapper Open Hardware license for the hardware and all of our software and firmware is licensed GPL V2. All of the details can be found at our website at altismetrum.org. If you have questions about any of that, Keith and I would be happy to answer them. There is a hash altismetrum IRC channel on OFTC where Keith and I and a lot of our customers hang out and talk about rockets and rocket software and how to make all of this stuff better. There's another page on my personal site, gag.com slash rockets, that has more information about the general hobby and some of the projects that my son and I are working on. With that, I'll wrap it up and I believe we still have a few minutes left for questions. Thanks very much for your time and your attention. So if you have questions, we have a mic. Yeah, sounds good. Just a small question. You mentioned you are making model rockets. What are they models of? Well, so the ones that I like to make are not actually models of any specific larger rocket. They are models in the sense of being, I mean, it's always an interesting discussion. They're real rockets, but they're generally out of a smaller scale and sort of a hobby-oriented thing. There are a lot of people within our hobby who like to build scale models of military missiles and commercial rockets and things like this. Last year, for example, or two years ago, I forget now, to celebrate the big Apollo anniversaries, a couple of folks started building big models of the Saturn V and the Saturn I Bs and it's been fun to see some of those fly over the last few months. There are people in Colorado who actually at one time worked in one of the facilities that did assembly of some of the Pershing missiles and things like this and it's fun to see those guys show up with very detailed scale models of some of those things and actually put motors in them and fly them, but for me, I'm not as interested in modeling real missiles. I'm interested in learning how to build custom airframes that will do a good job of addressing the specific objectives that we have for any given mission. Another unrelated question. The GPS as you use, how well do they work at the speeds the rockets are going? Ah, yeah, so the question's about GPS and how well it works in rockets. There are a set of restrictions, at least for things that are built and exported from the US on GPS having to do with the COCOM limits and what it basically says is the GPS is not, consumer GPS devices are not supposed to work if they exceed a certain velocity and a certain altitude and the different GPS manufacturers over the years have had different interpretations of the and versus or of those two conditions. The chip that we're using works fine as long as you don't trip both conditions at the same time and in our part of the rocketry hobby, the highest velocities are achieved close to the ground and by the time you're up very high you're not going very fast anymore because you've bled off most of the energy trading, kinetic energy for the potential energy associated with the altitude and so we don't ever actually trip that. The more interesting issue is that all GPS receivers have a filtering algorithm to try and convert the raw data samples they're taking from the radio signals received from the various GPS satellites and turn those into position and those filters are gent for commercial grade chips like the one we're using. Those filters are usually optimized for certain assumptions like people are probably moving on the surface of the earth. In other words, they're probably moving at velocities that make sense for walking or riding in a car or something like that, maybe in an airplane but not so much and they're certainly not moving very fast in the Z axis and so we tend to violate that assumption and so one of the things that you have to pay very close attention to in the rocketry world is what are the sort of maximum accelerations that the algorithm that's implemented in that particular receiver is capable of coping with without losing lock on the satellites and all the chips that are generally available to us in the rocketry hobby have issues during boost and so the question then becomes how quickly do they recover and figure out where they are again after the boost is over and also how confused do they get while they're unlocked? We tried some chips for a while that were part of the SURF family, the SURF three family and they're utterly worthless because when they get confused they start searching crazily like shooting straight west trying to find a solution when you're going straight up and as a result it takes a very long time for them to reacquire the actual position. The chip we're using now actually coasts really well. It goes unlocked, it says I've lost track of the satellites but when it does that it just doesn't change its X and Y numbers and when it reacquires the satellites it doesn't take it very long to realize oh, we didn't move very far horizontally but we went way the heck up and we almost, I don't think we've ever had a flight that I'm aware of where we didn't have a nice solid position lock before we reached Apogee and then of course we mostly care about the GPS and the recovery phase and it works very, very well for that. Other questions? Yeah. You said you tried GTK, now you are now using Java. Were there other toolkits that you investigated or considered? Our investigation of tools other than GTK plus before switching to Java was done entirely by asking all the smart people we knew what they suggested and the nice thing is because of Keith's long standing role in the X community he has a lot of friends who do a lot of things that have to do with user interfaces and we had the benefit of talking to what we believe are some of the smartest people in the world on these things and as I said, it wasn't 100% consistent but anyone who knew us at all and knew what we were trying to accomplish at all was very consistent about saying you really should just use Java for this and as I said, it's been a really good solution. I think we have time for maybe one more question if anyone has one. Yeah, Tom? One of the things that's happened in the past year is there's been some really interesting work with OpenPilot on AHRS systems around 90 degree of freedom sensors and I'm wondering if you've considered using that. We've actually talked to those guys some and the challenge is that their dynamic environment is quite different and the sensors they're using as a result are often not as directly useful to us as you would think. For example, the good, cheap, three-axis accelerometers have a peak limit of about 18 Gs and my son exceeds that with his rockets. So these are, I don't mean to be a little of sensors but the reality of the rocket dynamic environment is just sort of different. Now, I have flown a nine degree of freedom board as a payload in one of my rockets and we gathered a massive amount of data that frankly we've sort of never gotten around to really truly analyzing. There are other sensors that I would really like to experiment with. One of the companion boards we've developed for our telemetrum system is a board for controlling additional pyrotechnic channels for supporting air starting of additional motors and so forth and one of the sensors stuck on there just because I'd like to experiment with it and learn more about it is a three-axis magnetic sensor. The idea there is you can actually detect your orientation relative to the Earth's magnetic field and if we could use a sensor like that to determine our orientation well enough to not fire the other motors unless we're pointed straight up. If the rocket's had some problem and it's aimed horizontally, you really don't want it to go farther. That would be really cool but there are a bunch of problems with using that naked sensor. One of them is that in the pre-launch configuration we're very close to a metal launch rail and that's gonna disturb the magnetic fields enough that we won't actually be able to do any kind of sort of calibration of the sensor until after launch when we're in the vertical boost and there are some real questions about whether we can do anything useful with that sensor at all but because again, samples of it were cheap, i.e. free. I designed and we're building prototypes of that companion board. It seemed easy to stick one on the board and just go collect some data and see. I think that the folks that Keith works with at the Portland State University Aerospace Society who have a great website by the way at PSAS. I don't know, we can look it up and pass that around if people are curious. They've actually been working on active guidance during the boost phase and demonstrated within recent months a launch where some little canard fins on the airframe were specifically controlled during the boost to do some 90 degree controlled snap rolls. So as the airframe's going up they had a camera looking backwards down the rocket at the ground and as it goes up all of a sudden it does a 90 degree rotate this way and 180 degrees the other way. It's really quite impressive to see that video and obviously they're taking advantage of all sorts of inertial guidance sensors to make that work. When or if we would think it's worth generally building something that has that kind of stuff. I don't know because frankly the board we've built so far actually does everything Keith and I and my kids and his friends and so forth are trying to do right now. So. That's cool. One last question about the license. A lot of people have used the TAP or hardware license and I'm wondering there's recently been this announcement of this new sort of open source hardware license. Can you make a comment about that? I have not actually read the new license. My immediate reaction on Twitter or Identica or something or wherever the heck it was I commented on it. I lose track there's so many of these days. When somebody pointed to that as I said gee were they not aware of the other existing licenses? The more interesting variant is that a lot of the people in Arduino space and so forth have been using one of the Creative Commons licenses for their designs. I'd like to point out that that's like a hugely permissive license and maybe they're happy with that but when we pick the TAP or open hardware license it was specifically because I understood that it had been crafted to be in fact I helped to review the license so I know more about it than some people. The TAP or open hardware license was specifically designed to have some of the same characteristics of the GPL but implemented in a license regime that works with hardware because copyrights on hardware are essentially useless. You have to think about it in other ways and you really have to think about the implication of patented contributions to a shared project so. Anyway I certainly encourage everyone who's interested in this to go take a look. As I said all of our stuff is freely available. You're welcome to take a look. Just this morning I had an email from another customer who apparently is in the process of becoming a co-developer because he sent us patches and you know I get excited when we these are actually patches to the flight firmware not to the ground software. I believe this is the first time a customer has sent us an unsolicited patch for the flight firmware so really excited about that. Thanks again for your time and attention.