 Okay, so welcome here. The next talk here in the main hall of the DapCon 2018 in Taiwan, we're having now here Bide Elgarbi and Keith Packett next to me. We'll talk about rockets, so of course we're here at DapCon, so it's all about freedom and flying rockets with free hardware and free software. I just heard some exciting background information here. You already started the company, 2010, but you have been working already for several years before that together. So looking forward to hear more about the details of flying rockets here with DBR and free hardware and free software. Thank you very much for joining us. Great. Thank you. Can everybody hear us okay? Can you hear me as well? Good levels. Awesome. Perfect. So for those of you who've been to Debian conferences before, this is not the first time Keith or I have given a talk about rocket-related things. We're actually trying to do something a little bit different today. We will be talking about our passion and sort of shared obsession. We're two grown men with a shared chemical obsession with ammonium perchlorate composite propellants. But we will not just talk about sort of the what we do part, but we're going to talk about all the tools that we use for doing the various things that are related to both our rocketry hobby and our rocket electronics business that come from Debian and talk about the places along the way where the work that we've done has motivated us to make additional contributions to Debian. And so don't be fooled. This is very much a Debian all the time for everything we do kind of talk. So what is this whole, what's the whole sort of context about this? I guess before that, out of curiosity, how many of you have never heard us give a rocket talk before? Awesome. Awesome. There are some people that are getting this abuse for the first time. Perfect. So when we talk about rockets, we're not talking about, you know, big commercial rockets. We're talking about rockets that we use in our hobby. This is an interesting collection of small rockets. We have bigger rockets, some of which you'll see photos later. And the objective here is sort of a combination of sort of science and engineering and sort of a technical hobby. And also it's just a heck of a lot of fun to go out in the middle of nowhere very far away from people and put rockets up in the air and just fly them and have a good time. To give you a sense of scale of these rockets, the largest one, which has the red nose and the yellow fin can, that's about a hundred millimeter diameter tube that's a meter and a third or a meter and a half long. I have built rockets that were as much as three meters long. And I'm working on one right now that will be closer to four meters long and about 350 millimeters in diameter. I personally have had rockets go faster than Mach 3 and to altitudes above, well, let's see. I don't do the math very well in my head, so 32,000 feet. About 10 kilometers. A little over 10 kilometers, yep. Just to give you a sense of the scale of the toys that we like to play with. So it doesn't take very long when you start playing around with hobby rockets before you start asking questions or trying to achieve objectives that require some kind of electronics. And so, okay, what did you do to me, Keith? I did something wrong. No, you just changed the way my display is set up. So let's talk just a little bit about avionics. What's the role of, oh, I see what you did. You brought up the note screen, but I don't ever use it. You brought up the note screen. It wasn't me. What did you, you changed the mode of the presenter's console? It's okay, we'll survive. Keith and I have said several times before that part of the reason we have so much fun working together is we have very complimentary skill sets. It's also been said several times by us and other people that if we lived on the same street in the same town, in the same part of the country, we would probably have been forced to kill each other by now. So the best kind of partnership. So the role of avionics is sort of, there's sort of two big things that matter. One is to fly the rocket safely and hopefully be able to get it back so that you can fly it again. And the second part is to collect information about what's happened during the flight. Sometimes that's so that you can design a better rocket for next time. Sometimes you're in a competition and you're trying to compare your results with other people. But one of the aspects that we've pursued quite a bit is that all of our electronic systems that Keith and I ourselves use routinely also have GPS receivers and radio links back to the ground so that we're getting live telemetry during the flight and are able to go find our rockets after we're done flying them. And one of the things that happened very early in my personal involvement in the rocketry hobby is that a rather large project that I built got lost. And it got lost because of a bug in the firmware of a commercial flight computer that I was using to control the deployment of the parachutes in that flight. And that was really, really frustrating. And so it led me to be very, very interested in trying to develop something that worked better and that was open. Because of course that particular product was proprietary and there's no way for me to do anything about it. So today there are a number of boards that Keith and I have designed and built and used in our own rocket projects but which we also make available to others in the rocketry hobby through a company called Altus Metrum. We're actually really proud of ourselves that Altus Metrum has met all of our original business objectives, which were? Let's see, stay friends, have fun, don't lose too much money. Yes, in fact we have succeeded so well in the not losing too much money that we were really tickled that we could afford to become sponsors of DevConf this year for the first time. Really small sponsors. You have to look on the website to find our logo. It's not on the t-shirts and all, but we thought that was really cool. Hopefully by the time we're done talking today you'll see that the contributions that we're making to Debian because of this work are a whole lot more than just money though. In any case, we have a number of different products that we make. They kind of break down into boards that go inside rockets that are mostly flight computers for safely triggering events related to the deployment of parachutes and the recovery of those rockets after they've flown and also for collecting data about the flight and sending position and flight dynamic information back over radio links during flight and making it possible for us to go find them after the flight. That also requires of course that we have ground station hardware so that we can receive the radio telemetry during flight and do something interesting with it. Today the most interesting one of those products we make receives our radio link and turns it into a Bluetooth connection so that you can watch the flight information live using a cell phone or a tablet. The most interesting thing in that space that's happened recently that something we didn't actually do is there's now a third-party company making an application in the Apple App Store for iOS users because of course none of the code that Keith and I write, all of which is of course under the GPL, is welcome in the Apple App Store. So the kinds of things we make. So this is kind of the first thing that we built was a two-channel flight computer called Telemetrum. You can see in the top image it has a GPS patch antenna and a beeper and in the bottom image you can actually see the GPS receiver, the U-Blocks part along with the STM microcontroller, the large chip in the center, memory chip, an accelerometer, a barometric sensor and a radio transceiver. And for a sense of scale that board is about 25 by 75 millimeters. Yep. And then we also have, this is our first ground station. This is a USB connected ground station. It's got an SMA connector, a little radio receiver and the holes on the right side of the board are where you connect a USB wire. Here's our bigger flight computer. It's got more channels of pyro things to initiate stuff during flight. It's also got a three-axis accelerometer, a three-axis driver scope and a three-axis magnetometer, which lets us track the orientation of the rocket in flight. Which is really useful if you want to know, if you want to inhibit various events should the rocket tilt over and point at you. That's been very useful in making rocketry safer. This is one of the things where a little bit of electronics and a little bit of computing know-how goes a long way as in actually making the hobby that we enjoy safer for people to participate in which we both like to do. Particularly for complex projects, either multi-stage rockets where you're lighting additional rocket motor stages in flight or for something we call air starts where it's a single stage rocket but the motors don't all light at the same time. You have one motor that lights and as it's burning you light additional motors and all of those sorts of things that we call complex flights are made substantially safer by the ability to gate pyrotechnic events based on things like how many degrees you are away from vertical and stuff like that. And then we also make some without radios. Some people put these electronics inside of RF opaque containers, carbon fiber or other metalized and conductive systems, aluminum. And so we make our electronics without radios. Michael and I are really careful to never do that because the radio is the most interesting part of it to us. It means you can track the rocket and it also means when the rocket ends up six or seven feet under the ground crushed into a pulp having failed to correctly deploy the parachutes you still get data from the flight. And data from the flight is the most important thing that we get out of rocketry because if you don't get data you have no idea what went wrong. Yeah, on my first successful attempt at exceeding Mach 3 without having the airframe come apart. Partially successful. It was a successful attempt to do Mach 3 without having the airframe come apart. Unfortunately the remains of the airframe ended up about a half a meter below ground. So yeah, a little problem with the Apogee deployment. We'll be attempting a retry on that particular project hopefully right at the end of August that will launch out in southeastern Kansas. I mean it penetrated dirt hard enough that we had to in order to find the back end of the rocket which was closest to the surface of the ground we had to use a pickaxe. So this rocket is the bottom of the rocket the back end of the rocket is more than a half a meter below ground and the ground is too hard for us to dig. It was a pointy stick about 75 millimeters in diameter with a pointed nose cone or the metal tip on it coming down at point 0.78 of Mach or something like that. So yeah it made it interesting when we found it it was a cute little hole with three slots. Where the fins cut the dirt. Yeah. And without telemetry and GPS we wouldn't have even known where to look because after the motor burned out and the smoke trail stopped we had no visible sightings on the airframe as it went up above 10 kilometers and came back down. There's the back of that board. Here's just a GPS receiver. So this is just a tracker. You could put this on your dog or your business partner and I'll allow you to track them around anywhere on the planet. It's a little GPS receiver and a trend. So this is kind of the other half of that the other half of the board. Yeah a lot of folks will take one of these and stuff it up inside of a fiberglass nose cone or something that's RF transparent so that it can get GPS signals and send telemetry out and they'll have one of our flight control boards buried down in the fin can either in the middle of a pile of aluminum parts or sometimes carbon fiber assemblies that are RF opaque. And this was about one inch by one and a half inches or 25 by 40 millimeters or so. Nice and tiny. Okay. So that's the kind of products that we make. What is it that we actually do with these? Well not surprisingly Keith and I got into this because we like to build rockets and in the process of building rockets there's various bits of software that come into play. Probably the most frequently used tool for us for this these days is this thing called open rocket. This started out as a master's thesis by a student I think in Finland who ended up basically writing a huge pile of Java that implements a design, capture and simulation tool for hobby rockets. There were a couple things that were really interesting about it relative to the other things that were available for Windows and so forth at the time. First of all he chose to put it down during an open source license which was awesome. The second thing is that because the team at his university that he was supporting with this work were flying big honking rockets that went really fast up high. He got interested in solving some problems having to do with how drag buries across the transonic boundary that nobody in the sort of software for Windows for people playing with toy rockets had bothered dealing with before. There's still six or maybe a few more active contributors. It's been now quite some time since there was a new upstream stable release but watching the develop list I think there'll be one coming maybe before the end of the calendar year. Because it's one of those classic huge piles of Java with lots of weird dependencies and all sorts of things incorporated in the source tree that I just haven't had the patience to successfully unravel for a while. We don't actually do that as a full package in Debian but there's an installer package that makes it really easy for people who want to use this to download and maintain and sort of stay up to date on the current version of the pre-built jar that's up on their site. If anybody is enthusiastic about wanting to tackle this and is interested in unraveling some of the Java build dependencies in it and working on it with me, I'd be totally happy particularly now that I'm retired and in theory have a little more time. It would be cool to see this turn back into a real Debian package that could live in Maine. And then we use various tools for designing the different mechanical pieces in the rocket. We use open scatter lock because it's really easy for creating things like centering rings. I'll show you an example in a second. And FreeCAD is pretty handy for doing more complex mechanical assemblies and thinking about how pieces are going to fit together. The good news there is other people maintain those for Debian and the packages just work great. So here's sort of a screen shot of what open rocket looks like when you're designing a rocket. As you can see at the top, there's sort of a hierarchical view of the components that go into building the airframe. And for each of those components, you can open that up and there's lots of data in there about what's the material that it's composed of, if it's an exterior component, what's its coefficient of drag or the surface fineness associated with that. And it's really pretty easy to sit there and kind of chunk pieces together and come up with an idea for a new rocket. And then the simulation element of this is really pretty accurate. I've had results that were within a few tens of meters on flights that were to several kilometers above ground, even with motors that I had designed myself and getting all the way from a propellant formula all the way through to a flight simulation and having it come out within a couple hundred feet or some tens of meters was kind of mind-boggling. Open SCAD, if you do any sort of mechanical or 3D printing stuff this tool might be familiar with to you. That's an example of a centering ring my son and I were designing for a complex project that had a large center motor and a ring of smaller motors around it. And so this is designed to hold those motor mount tubes in a fixed position inside the airframe tube. And then, you know, we have a CNC router in the house so we'll go check up a piece of Baltic birch plywood and turn those designs into physical parts. And here's a nose cone that was being machined on our CNC milling machine in the garage out of a rather large chunk of maple. And that's the rocket that my son designed from scratch and built all the parts for. It's a half-scale model of a US Maverick missile. Unfortunately, on its first flight, he had an apogee deployment failure so it ended up, the flight was a whole lot more like a real Maverick flight than he had intended. This is another example where I think the brown band near the aft end of the rocket was just below ground level and only a little bit of the aft fins were sticking up. But, you know, things happen. You know, what can we say? The other thing that I've gotten really interested in in the last two or three years, most people who play with hobby rockets do it using commercially available propellant reload kits. In other words, the motors they're flying were designed and the propellant was crafted into kits of propellant and the related pieces by somebody else. But playing around with the chemistry and physics involved in rocket motors is something that I got kind of interested in. It's almost an entire hobby unto itself. But one of the side effects of that is I got really interested in rocket motor simulation software. This is actually simulating the combustion of the propellant and all of the things that are related to the motor generating thrust. And I'm really pleased to be able to report that there's not one but a couple of different motor simulation programs and do in part at least to needling from Keith and or me of the respective authors. The program which is written in C and this other one which is written in Java are now both available under the GPL. And unfortunately neither one is packaged in Debian yet. This is again one of those examples of my Java who is not good enough to get this to build because it has a dependency on something with the Java community really doesn't use anymore and I haven't figured it out yet. But eventually I will probably make time to put this in Debian. But in the meantime, here's an example of an actual motor designed and flew with it. This was a four grains of propellant in a 54 millimeter diameter motor. As you can see there's sort of simulation run showing what the thrust and chamber pressure and all that are going to be. And then here are the four grains in. The casting stands in my garage after I mixed up the propellant and sort of turned it into the right grains. And then of course before you entrust a rocket to it a friend and I designed and built this test stand which allows us to put a motor in upside down and burn it using the earth as a mass to push against. And built into that stand are sensors for measuring the thrust. There's a load cell in there and for measuring the chamber pressure. And of course that led me to design a circuit board full of electronics so that I have a wireless interface to my test stand so I don't have to sit out in the sun real close to a dangerous motor while we're testing it to collect the data. This little board it's now typically used in a better package but it allows us to successfully start operate the test stand, collect all the data and then download that data over the air and analyze the motor performance before we have to go out in the sun and deal with the remains of the burn. So with that you want to talk a little bit about... Yeah, so the other part, the other thing you've seen us doing a whole lot of the circuit boards obviously we need computer tools in order to design the circuit boards, design the circuits and the circuit boards and have them fabricated. So we use the GEDA suite of applications for all of our circuit board design. This is kind of one of those big schisms it's the VI versus EMACs of the EDA world. You can either use GEDA or you can use... KeyCAD. KeyCAD. And the funny thing is BDA and I both use EMACs pretty extensively with a little bit of buy on the side and they seem a lot more like VIM. I mean it's a bunch of little tools all kind of vaguely glued together whereas KeyCAD is this enormous suite that does everything including reading your e-mail. And so there's a schematic capture tool, GSCAM. There's the PCB editing tool called PCB and then you can actually view the files view the files you generated before you send them off to be manufactured. So this is literally the ability to generate a circuit, generate a circuit board, have files you upload to some website and in a couple of days you get physical boards back that you can load by yourself. It's pretty cool. There's a bunch of companies around the world that do this Gerber to PC board fabrication. I'm sure there's some here in Taiwan I know in my town of Portland there's Osh Park which offers a very expensive service. So this is a way for anybody to build whatever electronics they want not requiring the ability to manufacture PC boards. Right now there's a big transition happening in the GEDA world. A lot of people, a lot of developers have moved from the kind of more abundant PCB project to this more active PCB R&D project. It's got a lot of new capabilities that we're excited to use including better ability to have kind of modern parts and parts with more features and it allows us to generate a 3D model and actually export a 3D model of our boards to customers. We regularly get customers to question this morning how thick is the board with all the components on it. I have no idea. I would have to have models of all little parts and measure them by hand with having a 3D model. I could just go into the 3D model and look at it. So an interesting example here though is that in the key CAD side there recently has been an additional capability added to export designs into free CAD and that's pretty cool but free CAD is another really huge piece of software. What the PCB R&D upstream developer talked about which Keith and I then agreed actually as Altus mentioned to provide some sponsorship for is that he generated an exporter that outputs an open SCAD source file, a SCAD file. So it's a really lightweight representation that's easy to turn into a 3D STL model which is what most of our customers actually want and it's a whole lot lighter weight and it's something we can use as a make target instead of another huge piece of software that we have to deal with. And these are all, BDL actually maintains all of these programs along with the rest of the Debian electronics team so we are making sure that the tooling that we depend upon is current and updated in Debian so that everybody can take advantage of it. It's one of the things we agreed to when we first started and it's part of actually having fun and sort of staying true to what each of us really think about life and what some of our core values are. We just absolutely insist that every tool we use for designing and selling our products is something that we can use Debian to do. It is the universal operating system except it's not flying into my rockets yet. Next project. Yeah, we keep talking about we should do a board for a rocket that's powerful enough to actually run Debian on it but it's such a waste of silicon. Here's what GSCAM looks like. It's a typical schematic capture program. You basically draw your circuit using lines and components and these components actually have attributes that say what they look like on the circuit board and the schematic capture generates files that are then imported into the PCB tool and as you edit the schematic you can re-export that and re-import it into the PCB tool and keep the two in sync. There's a bunch of design rule checking to make sure that when you build your circuit board it actually matches the circuit which is kind of cool and so you actually have some validation that the circuit board you generate is going to accurately implement the circuit that you've designed and that's kind of the whole notion of schematic capture in PCB design. Here's what PCB looks like. It's basically a graphics editor. You draw copper and you paint components out of the board. It's kind of the MS Paint of the system where you're kind of in there drawing individual pixels practically. It looks when you first start it up you're like, how do I use this tool? It's a big blank window and you're like, oh, I import my schematic objects which each have a graphical representation and then you just kind of move them around and draw lines between the two that represent the copper. Yeah, so this is one of those places where art and science come in a little bit and I'm really thrilled that Keith has ended up having fun designing a whole bunch of circuit boards and in fact some of the products that we shipped today, Keith did the hardware designs on but let me tell you we're trying to build boards that are about yay big and have multiple radios that are all single digit millimeters apart from each other. It's a little more than just moving parts around and drawing lines. Making things that actually work is where it gets really fun sometimes. And that's why it's awesome to have BDL around so that when I screw up the radio BDL can tell me what I did wrong. Or just fix it. Or just fix it. You can see this, here we are actually making a product by hand. We don't actually manufacture our products by hand very often because that's really tedious. So this is a prototyping step where we got a PCB manufacturing company to give us half a dozen boards. This is actually when we were using some laser cut captain stencils and so we actually had another company laser cut the little holes where the solder needed to go and then you squeegee this solder paste which is a mixture of flux and tiny little beads of solder. You squeegee that over the board, take it off and then you've got solder all the places the components need to go and then use an inspection microscope to stick the components on. The components are tiny. So a typical resistor is an 0402. That's 40 by 20 thousandths of an inch. So the components are tiny. Which is one millimeter by half millimeter. Something like that. We don't remember anymore. I think 0402 metric is a 1005. So I think it's a 1 millimeter by half millimeter. Anyway, they're fricking small and hard to see. And we are both old men and we need microscopes to be able to assemble our circuit boards. So that's all it takes. It takes a microscope and a little tweezers to do electronics these days. Then when you've got it all assembled you stick it in a frying pan and cook it for a while with a very carefully calibrated cooking profile and the solder all melts and the components are all put together. And that's how you build all that complex. I was actually pleased on the industry tour the other day one of the example objects that we saw in the Science Park Museum was one of the non-contact infrared thermometers and it happens to be the exact model that I used for calibrating my frying pan. So that was really very amusing. Yep. You're doing the software or am I doing the software? You're doing software. I'm doing software. Okay. You wrote most of it. I wrote almost all the software. So in the spirit of the division of labor, BDL does the hardware and I do the software. And then I end up packing most of the boxes to ship things. And then BDL ends up debugging my software as well. And I ended up getting to do some of the hardware and packing very little for shipping. In any case so we're writing stuff for at this point almost entirely are microcontrollers. They're a lot of fun. They're inexpensive, amazingly powerful and very low power. And as a result, we're using an embedded language, my least favorite, most favorite. It's a love-hate relationship with the C language. Of course all of the source code is available on our Git repository. Because we're using our microcontrollers, the tool chain for these microcontrollers actually lets you do source level debugging right on the target. And this is an amazing revelation to those of us who grew up in the 70s where debugging was a painful experience in systems that didn't have a display. So we have full source level debugging with GDB and break points and inspecting of memory and all kinds of cool stuff. I wrote a little operating system because everybody should write an operating system, right? Even I've written one, we just wouldn't use it. Exactly. Which was fun, right? I could have just gone off and used some existing real-time operating system and it would have been okay. Well, you did do that for a while, but the one we were trying to use was just huge and clunky and did lots of things we didn't want and none of the things we actually wanted. And besides, here's an opportunity to meet one of our primary business objectives. Have fun. That's right, right? Writing operating systems, that's a blast. So it's a little cooperative multi-tasker. It could do preemptive multi-tasking, but meh, I don't need it. Why bother? It's harder. And all the tasks in that, some of them do logging, some of them do radio, some of them run the beeper, some of them do the pyrocharges. And so there's a whole bunch of tiny little tasks and it's kind of amazing that when people use our boards and they can't figure out why the beeping and the radio telemetry and everything is kind of out of sync with each other. And it's like, well, it's, you know, whenever the tasks get run, things happen. They're like, well, in other boards, things kind of happen in lockstep in a more traditional embedded design, but processes are fun. All of our devices use USB, which makes it possible to connect them to almost anything. They all have a little command line in them, because that way you can debug stuff without needing any host software. And so if you plug our boards into your computer and ChaosKey is no different here. When you plug ChaosKey in debug mode in reflash mode, it actually has a little command line interpreter that you talk to to reflash it. Here's the compiler suite that we used to use, the SDCC. We had an adventure with SDCC, a new version came out, and the binaries it generated wouldn't fit in our products anymore. They got bigger. It's an embedded device. Life is short and the ROM is full. We looked at what they'd done and it made really good sense, and we totally agreed they'd done the right thing, but unfortunately it made all of our firmware overflow the size of the flash memories and the processors we were using. We looked at each other and thought about it for a long time, and Keith basically said OK, we'll fork the compiler. We love free software. What a fricking disaster. That's why there's a package called CC1111 in the archive. The processor chip we were using at the time was the TI-Chipcon CC1111 and CC being Z-Compiler. I love the DuVlon Tondra, so that's what it's been called. We actually have a plan for doing away with support for all of the ancient to us now 8051 devices after our next release of our software system, which will be coming probably in a week or two, so we are maybe single digit weeks away from obsolete support for that processor and our source tree, and as soon as we do that, that package will be disappearing from the archive. I strongly suggest that anybody who wants to do 8051 development, first of all, check yourself in somewhere and find out why. But if you are, then please use their current SDCC to build a dependency on CC1111 or you may have the pleasure of adopting that package and taking it over when I have it removed from the archive hopefully in a few weeks from now. The other compiler that we use, of course is GCC for our ARM stuff. When we started, there wasn't an embedded ARM compiler for the chips that we're using in the Debian Archive. There was a lot of ideas on how to build that, what you would build and what it would look like. I went ahead and packaged that and got it into the archive and about a week later, some helpful person came along and decided that they wanted to do a better job of packaging it and took it over and I'm like, woo-hoo! So, yes, so we were able to just, you know, kind of see this whole developed embedded ARM development environment in Debian, which was cool. The other tools that we use, of course are the debug connector tools for that source level debugging. The one that we use right now is OpenOCD. Noodle's packages that for us has updated the packages for that and it's been awesome, it works great. And we actually are using an ARM chip now that has support for the DFU device firmware update. I think that's what that stands for. It's a built-in, really small USB flashing tool that you can use to do your first flash of firmware on a brand new device from the factory. And so that tool is actually in the archive. I was shocked. It's like, okay, I've got this chip, it's got this bizarre custom protocol. I'm sure I'm going to have to go write some new tool and I do an app search and there it is and I install and it just works. It's a twisted little tool, but it actually works and we use it exactly once per product to put our bootloader on it and after that we're sort of in control which is what free software is all about. So embedded devices need a C library. You want strings functions, you want to be able to have a math library and you want a little bit of standard IO for debugging. GCC and GCC ABR, those are the kind of the two 8-bit embedded compilers in Debian right now. They have their own C library. It's awesome. You install the compiler and you can just compile stuff and you have a C library. GCC ARM non-ABI, the embedded compiler we use for ARM suggests that you use NewLib Nano, but NewLib Nano isn't actually an embedded C compiler. It's not actually free Nano. Yeah, it's kind of huge and in particular the standard IO that it uses is about 20 or 30 POSIX operating system functions like open, close, read, write. It's like, I ain't got that. I got put C, get C, that's all we have. So we're trying to figure out what to do for embedded C libraries for really tiny systems. I have a hack right now that I'm playing with. It's the NewLib Nano library with the stittidio bits from GCC ABR. It kind of works. We're going to be playing with that. If you are building embedded systems with ARM chips in it and you don't want all of the complexity of the standard IO from NewLib Nano I would love to collaborate. Right now I'm collaborating with Noodle to try to get his extensa chip to use the same library if you have other embedded systems. I would like to get to the point where we have kind of a standard embedded C library for tiny systems that's available in the archive. Yeah, and so the unfortunate reality is that not all of the people in the world and particularly not all of the folks who want to buy and use our hardware actually run Debian yet. So we, Keith in particular spent time having to sort of unravel what it would take to build software for the OS disadvantage. And the really amazing thing for us is that all of the bits and pieces required to build packages for macOS X for Android they all are already around in Debian. And so we actually have a single source tree with a fairly complex set of make file targets that allows me to do a software release with really pretty close to one top level make command if everything goes well and emit this huge pile of different installer objects that we can just dump out on our website and people can grab and download. And once again it's just amazing to us that Debian has all the tools required to do this. So it really is possible to use Debian as your software development platform and deliver working installer packages that install applications people can run on this sort of bizarre range of operating systems. Yeah, so I mentioned a couple times the whole business thing and I tell people that we don't just use free software for designing our products and designing our rockets, but we're actually running the business entirely using free software as well. For the web store front that we use to actually sell things at shop.gag.com we're running Magento which is an amazingly huge, complex really feature filled PHP based web store implementation. It is all completely open source. There are the usual issues with big web suites of, you know, it wants to hand out minified JavaScript and things like that. But it has been while it was challenging to figure out initially it has run really, really well and that's been very successful for us. It's not packaged for Debian and honestly I don't know if a pile of PHP that big ever really makes sense to, you know, package in Debian. One of the things that's happened between Magento V1 and V2 which I'm in the process of moving to is they've completely restructured the source and they have their own sort of dependency management tool for building and maintaining and updating the software. So while it's not packaged for Debian we're running it on Debian and one of the things I'll be publishing as soon as I put our V2 store in production is like explaining all the sort of steps I went through. There are in particular for people like me who don't do web things all the time some interesting little gaps in the knowledge that's out there about I think the last thing was one more patchy module that without it nothing seemed to work the way you expected and with it all of a sudden it's all working. So I'm going to try and publish the notes about that when I can. And then we chose after messing around for a while and sort of doing what you do when you first start things and using things like our US Postal Services website for initiating packages and shipping stuff I kind of gave up. I found a third party software as a service offering called ShipStation and frankly if you run a small business and need to ship a lot of stuff I think they're a global concern but certainly in the US it's well worth the small amount of money that we're paying per month to have access to that because the productivity of it is really amazing it looks into the back end of the web store it learns about new orders and helps me manage sort of where we are in the process of fulfilling those orders and the discounts we get because they have so many customers and are generating so many shipping labels with all the different shipping carriers actually almost entirely offset the cost of paying for that service. And then the other big thing that you have to do when you're running business is you have to do accounting stuff shockingly Ledger-CLI which is now getting sort of long on the tooth and there are other things that people are working on as sort of replacements and alternatives that you can find out about if you want to go read about them it actually is completely sufficient for my needs at the moment though and I really like having an accounting system where the journal is something I can whack on in Emacs with a little bit of an Emacs mode that provides some macro assistance and once again this is something that's already packaged in Devian, it works just great and because all the data is stored and things that look like text files it's easy to keep your accounting history in get and to never be surprised if all of a sudden the numbers don't line up, you can have some way to unravel that in order to get data into Ledger-CLI I use the beanbag tool that Anthony Towns and others created for sort of making it easy to write code in Python that interacts with compressed APIs and with AJ's help I figured out how to do that the first time and now I have an ever growing and complexity script that pulls sales transaction data out of the store and turns it into transaction data in the accounting system there's a tool I found called Reckon which is kind of horrible but it does the job that makes it easy to take CVS formatted data that I'm downloading from our financial institutions yes I'm so sorry this is another one of those I've been around too long to get the whatever CVS comma separated value files that we download from our financial institutions and that gives me sort of a pattern matching thing that makes it much faster to translate those into Ledger format and then accounting is kind of like software you keep your history in get and you run make to generate all the things you need that's a whole lot simpler than it would be otherwise yeah it seems to turn everything into get plus and make file yeah that's certainly the objective so time wise I know we're getting very close to the end of things but a few minutes great because just for fun we have some photos from various things that we've done over the years in rocketry and some of the people who got to do it with one of the things is I remember because we're talking at Debconf that at Debconf 10 in New York City a rocket building buff and went out to a launch site in upstate New York on the trailing weekend and spent two days playing around with the Metro rocket club flying rockets at their launch site I don't know how many of you have ever met Mike Beatty in person he used to be one of the members of our key ring maintenance team and maintained some packages and stuff ever since he had kids I don't think he's been all that terribly active in the Debian community but he did show up in the U.S. and came and flew his level one, level two and level three which is what this was high power certification flights with us at launch sites in Colorado and in Kansas a few years ago AJ also came and flew a level three high power certification project out in Kansas that's the rocket he built to do that it literally is taller than he is and you know this is Keith I guess playing with one of your tiny little rockets out in eastern Oregon I like to build tiny little rockets yeah Keith builds tiny little rockets which gives us test vehicles and excuses to test some of our smaller boards that are designed to fit in small geometry airframes I'll admit I'm sort of holding down the other end of the continuum as I mentioned earlier with some of my crazy big projects match our personal geometries yeah more or less there's a photo of me that's floating around where I have an airframe over my shoulder that's certainly it was almost exactly as tall as I was and about the same diameter and I'm working on one now that will be almost twice as tall as I am and bigger than me so no I'm not planning to ride in it but another thing that we did at one point is my son got really interested when he was younger he's now in the middle of mechanical engineering degree program at Georgia Tech as an undergraduate student but a few years ago he got really interested in the heating that happens in surfaces when rockets get going really really fast and so we actually built a couple of rockets in a series there's some photos of one of them where one of the fins had thermistors embedded in sort of a grid inside the fin and then the nose cone had some thermistors embedded in its skin down the side and the objective was to fly this to Mach 2 or faster and actually measure the temperature rise at high speed in the airframe to do that we ended up sort of customizing one of our existing flight computers and designing a board that was specifically for hooking up a lot of thermistors and I managed to fit those in the tiny little space that was only a few millimeters thick between a rather large motor mount and a rather not much bigger airframe this is what the airframe looked like this is what the third the second version of the temperature measuring project looked like and we flew that airframe to Mach 2.2 which had an interesting effect on the blue paint which had been hastily applied in the parking lot of a hotel the night before using you know spray cans of paint this is what it looked like after it had been to Mach 2.2 I thought that you know that paint job was substantially improved from the original but mostly just because I thought it was really cool to see how much it had gotten peeled off and so finally a couple of things that Keith and I have worked on that aren't really related to rockets that various folks know about I gave a talk at Linux conference Australia a couple of years ago about another altosmetrum thing which is audio boards this is a USB audio interface on one side for channel of class D stereo audio amp on the other side I took a lot of grief at the time from people about oh but class D is not very high-fi let me tell you these work great for all the speakers around our house and I would challenge you to hear artifacts when you're wandering around a house with speakers that are mounted in ceilings and stuff like that Keith and I also have collaborated on taking some of the technology we use in our flight computers for hobby rockets and we turned that into a processor board for amateur radio satellites that is an actual satellite that's about a hundred millimeters on an edge that's one of several that have been launched by the Radio Amateur Satellite Corporation of America in the AMSAT satellite series Oscar satellite series so there are now I think three of these that have one of our processor boards that are in orbit right now and two more that are queued up to launch possibly by the end of this year I'll go to low-earth orbits and it's a real hoot that the first one of those that got launched was a circuit board that I hand assembled using my tweezers and inspection microscope and frying pan in the garage of the apartment we were renting after the house burned down back in 2013 so very much garage shop kind of stuff going to space which I just think is really cool and then and probably about five or six years ago we decided we each had one of the little random number generators for our home machines and couldn't get any more of them because they stopped being manufactured so we decided to build our own came up with a noise source and came up with a little processor and actually I did another talk about this at LCA and the hardest part of this project was finding a box we actually talked about this at Dubconf in Cape Town too so I have some of these for sale if anybody wants one of these of course that was another fun project of course and I'm going to go back to the design with all the software it's a hardware random number generator that you plug into a Linux machine and kernels since 14 or so something like that just notice it and your entropy pool never gets empty which is pretty cool so with that we're pretty much ready to wrap up if you're interested in learning more either about the tools that we're using the things we've actually designed are on our website at ultismetrum.org there's also some rocket related information including some of my airframe designs which have been published are out under gag.com slash rockets all the stuff we do is under free licenses we really like the GPL and so when I was picking a hardware a license for hardware designs we chose the Tapper open hardware license which was intended to be and created to be a GPL like license for hardware it's recently been observed that there's one term in that license that probably triggers the only use it for good purposes kind of issue with it not being 100% free the author and creator of that license has agreed to fix that for us but it hasn't actually happened yet and honestly if I were starting out today there are a couple of more recent open hardware licenses that I might use instead the one that folks at CERN have been using seems like a really good choice I don't personally think that Creative Commons licenses are great choices for hardware designs but that's a really long conversation and lots of our documentation including a number of my rocket designs are out there under CC by SA licenses so feel free to have a look ask questions go out there and play and if you happen to live in a place where a hobby rocketry is legal just do it it's so much fun thanks so much yep we're good I'm sorry we ran all the way to the end of the session this afternoon if you do have questions find us in the hallway we'll be around the rest of the conference