Category Archives: Events

Mach 30 at the 2013 Open Hardware Summit

One of the things I look forward to the most every September is the Open Hardware Summit. From the first year, the Open Hardware Summit has been a critical event for Mach 30 team members to attend, and 2013 is no exception. This year involved a number of firsts for Mach 30 including our first opportunity to speak at the Summit, another speaker mentioning Mach 30 and its work, and meeting makers who are using Open Design Engine to host their project.

Perhaps the most exciting part of the Open Hardware Summit (at least personally) was being included as a presenter. As part of our work to develop export control policies to deal with ITAR and similar regulations, the Export Control Task Force decided to submit a proposal to give a presentation on export controls and open source hardware. The topic was accepted by the Summit organizers for its timeliness (Defense Distributed’s 3D printed gun has thrust the topic into the limelight) and the quality of the task force’s export controls research. I must say the task force did a great job preparing the materials, and I can’t thank them enough for all of their support. And I am happy to report our message of preemptively addressing export controls was well received. For those who missed the presentation, we expect the Summit organizers to post videos of the presentations and we will be sure to share the video as soon as we see it is posted.

Open source rockets makes for ITAR fun. #ohsummit

A post shared by Jeremy Blum (@sciguy14) on

w0z talks OSHW project management and ODE

w0z talks OSHW project management and ODE

No less exciting for Mach 30 was seeing Open Design Engine (ODE) mentioned in someone else’s presentation. Mach 30 friend Amanda “w0z” Wozniak gave another impressive engineering process presentation . In previous years she has discussed the design process, and this year she discussed project management. As part of her presentation, she discussed the importance of project management tools, highlighting ODE for its lightweight setup and ease of use. She went on to create a project (a laboratory EKG pre-amp) in ODE as a living example of the value of sharing open source hardware projects on sites with builtin project management tools. She even found an answer to an unsolved design problem she had been working on as a side effect of publishing her documentation. Thanks w0z for using ODE and sharing your experience!

??? and Greg show off the Photosynq

Robert and Greg show off the Photosynq

Last but not least I got to meet Greg Austic and Robert Zegarac in the Open Hardware Summit Demo Hall. Greg and Robert are working on a hand-held, low cost, open source photosynthesis measurement platform called Photosynq. Photosynq is hosted on ODE, and this was the first time I have been able to see (and touch) hardware developed outside the scope of Mach 30 which is hosted on ODE. It was a real thrill to see hardware come to life which was birthed on our project hosting portal. Congrats to Greg and the whole Photosynq team. Keep up the great work.

So, there you go. It was certainly an exciting year for Mach 30 at the Open Hardware Summit. The only thing which could have made it better is if we had fired off the Shepard Test Stand. Hmmm. Maybe next year…

Related Articles

New Space 2013 Wrap Up

J. Simmons at New Space 2013

J. Simmons at New Space 2013

As I mentioned in my last post, Mach 30 had a booth at the New Space 2013 Exhibit Hall.  This was our first time as an exhibitor at a major space conference, and it was time and money well spent.  We got to share our open source mission, demo two of our hardware projects, and meet some really great people.

The display materials in the booth, prepared by our graphic design ninja and board member Rebekah McGrady, covered our mission, open source hardware, Open Design Engine, the Export Control Task Force, and our current open source spaceflight projects.  One of the big surprises for me was just how well people responded to our mission.  Just a few years ago we would routinely be greeted with blank stares when we explained our mission is to develop open source spaceflight hardware.  This week I saw only one blank stare.  And everyone else was so excited by open source spaceflight that I got more than one high five.

I think part of the change in attitude was due to the fact that we had hardware to show.  Our booth included demos of two of our projects:  the Shepard Test Stand and our first ground station prototype.  More than a few people stopped mid stride when they saw the hardware on the table.  Those were always the best conversations.  The feedback we heard from the attendees about our hardware projects was extremely valuable.  For Shepard the big lessons were we should stick with the Arduino for our data acquisition system (teachers in STEM environments are already learning about Arduinos) and there is much more interest in Shepard at the collegiate level than I realized was out there.   For the ground station the big lesson is just how much demand there is from individuals and educators for this version of the ground station.  It is so high, I already have a number of emails already from people asking for a link to the project website.

As is always the case when we attend conferences, I met a number of great people at New Space. First is Liz from the Space Frontier Foundation’s Teachers in Space program. They are running teacher workshops about spaceflight and raising money to send teachers on sub-orbital flights. It’s a great program and we are talking about how the Shepard Test Stand and other Mach 30 open source projects could be used in their workshops. Next is Reuben who I met over drinks Friday night thanks to an introduction by Ethan, a Mach 30 volunteer. Reuben has experience in fundraising and has been sharing links with me for the Revenue Generation Committee.

Ground Station Demo

Ground Station Demo

Finally, last but far from least, is Tim from Southern Stars.  Southern Stars KickStarted a cubesat last year, the SkyCube, and he brought the engineering model to the conference.  It did not take the two of us long to realize he had a satellite and I had a ground station, and that clearly we should see if they could talk to each other. Within an hour we were sending messages from the SkyCube engineering model on one end of the exhibit hall to the Mach 30 ground station at the other end. And then, as if that was not cool enough, we decided to use the two projects to run an impromptu demo during a panel Tim was on later in the afternoon. Check out the very excited celebration of the demo over on Google+.

Related Articles

Exploratory Learning

Everyone involved with Mach 30 is always learning and growing, whether it be from conversations on social media outlets like Facebook or Google+, activities like the book club , or our weekly Hangouts. Another way we learn is by simply doing. When we started our Shepard Test Stand hardware project, we weren’t exactly sure how things were going to work. There was no tried and true method for developing spaceflight hardware using a tool like Open Design Engine (ODE), and we knew there would be growing pains. That’s one of the many reasons we started with a small scale project like Shepard instead of tackling something bigger.

Our engineering process was largely created and refined during the course of that first test stand project, and is now being applied (and further refined) in the creation of our newest project – a satellite tracking Ground Station . One of the things that’s been most interesting to me to watch has been how certain pieces of a project are best developed. The first thing I noticed is that there is a lot of power in spinning up a forum post on a step in the design process and then letting the discussion take its own course. Using the ODE forums for the initial discussion has two main advantages that I see:

  1. It gives everyone a chance to participate. If we hold a Google+ Hangout at 5PM EST in the U.S. to do the design of a widget from scratch, people in other U.S. timezones (or parts of the world) may very well not get a chance to participate. Posting a step of the design process on the forums and then leaving it for a day or two, or until the discussion runs its course, allows more people to give their input.
  2. It gives everyone a chance to think. Sometimes you just need to sit on a thought for a day or two before your ideas really become clear. You might have even posted an idea to the forums earlier in a day, and then a better way of doing that thing, or a major flaw in your idea sends you right back to the forums to post a retraction or revision. Using this form of communication gives you that time to think.

In some cases, the forums are all you need to complete a step in our engineering process. For example, on the Ground Station project we were able to complete steps 1 through 3 of our engineering process without ever having a face-to-face meeting. In step 1 we answered the high level whys and hows of the project. Questions like “Why are we building this?” and “How is this going to be used?” are what we tackle here. Step 3 involves creating a diagram so that it’s easy to see all the parts of what we want to build and how they all fit together. Then step 2 of the engineering process, which involves creating requirements that use words like “must” and “shall”, naturally come out of step 1. Requirements create a measuring stick that helps us make sure a project is doing what it’s supposed to.

Now, all of that is not meant to give the idea that forums are the be-all and end-all of project communication. One you’ve had the initial discussions in the forums, we’ve found that it’s often best to do those “in person” meetings using tools like Google+ Hangouts to help solidify and finalize decisions. This seems to be especially important with things like mechanical, electrical, and software design which often are easier to finalize when discussed face to face. On our preliminary design for instance, which is where we come up with a rough idea of what parts we need for a project, we may start out in the forum to give everyone a chance to contribute, but then we hold a Hangout to finalize the preliminary design. We discuss in real-time what everyone has put forth in the forum and distill it all down to a plausible design.

We realize that our processes will continue to evolve and be refined as we continue our work to enable the human race’s journey to the stars. Each project we do brings with it new lessons and opportunities for growth both on a personal level, and an organizational one. We encourage you to join us as we grow towards completing our mission.

Test Early, Test Often, Test Everytime

Credit Rob Sayer

Not everyone knows this, but my first degree is in theatre, specifically theatre lighting design.  Before I ever learned about differential equations, stress analysis, or lift-to-drag ratios, I studied color theory, script analysis, and worked lights for dozens of shows ranging from “A Christmas Carol” to “Evita“.

One of the secrets to making sure a play comes off without a hitch every single night for weeks, months, or even years on end is something called a dimmer check.  Before each performance (even if there was one earlier in the day), the lighting crew chases everyone out of the theatre, and one by one turns on the 50-500 lights over the stage to make sure everything is still working.  The crew checks to make sure the lights come on, that the color filter in front of the light has not faded or burned through, that the light is still pointed at the correct location on the stage.  And, believe it or not, for medium to large shows, there is almost always something that needs to be fixed before each and every performance.  Yes, even when the last performance was just a couple of hours ago.

This attention to detail, and insistence that every time the equipment is turned back on it should be tested, is an essential element to getting live performances right every single time.  It’s even more important when you have just changed something, whether it is to make a repair or an improvement.

I pride myself on how my experience in theatre influences the way I approach live events at Mach 30 and elsewhere.  I always insist on rehearsals, especially when technology is involved (we had two separate technical rehearsals for this year’s Yuri’s Night Party), and I do my own version of the dimmer check for any gear I plan to use during an event.

hangout logo-g+_dk

Mach 30 Hangouts happen each Thursday

But this week, I got cocky, and I made a change (to improve our Google+ page) without running through any tests afterwards, and this change broke our ability to host On-Air Hangouts (on a week when we had an important one scheduled).  #Oops.  Apparently, linking one’s YouTube channel to a Google+ Page causes some squirrelly behavior with On-Air Hangouts.  Behavior we did not notice until during and after this week’s OSHW Documentation Jam Round Table Hangout, which not only led us to starting twenty minutes late, it also appears to have prevented the video from becoming sync’ed over to our YouTube Channel (which is too bad, I think our panelists and guests had some really great things to say, and I am sorry we won’t be able to share them with the Open Source Hardware Community).

So, that’s the bad news.  Of course, the good news is no one died or was injured from my failure to properly test things.  But, Mach 30’s work is building to a day when people’s lives will be on the line, so it is important to recognize small failures so we can learn from them.  In this case, the lessons are

  1. Remember to test everything associated with a system after making changes to the system (there is likely a balance of risk vs reward to be struck, but clearly the key features of a system should be checked when significant changes are made)
  2. Mach 30 needs to identify the core features we are using Google+ for (such as On-Air Hangouts) and create a test plan (or dimmer check) to be run when changes are made to our Google+ infrastructure, either because Google upgrades a feature or because we turn on an existing one we had not been using.

And, in the mean time, I will look into trying to recover our lost hangout video, and schedule the already discussed second round table hangout (after I have fixed our YouTube settings).

ad astra per civitatem

Mach 30 Reporting In: October 2012

We dedicate our first weekly hangout each month to catching you up on what is happening at Mach 30.  We do project updates, share where we are stuck, and answer any questions that come up about Mach 30 or our work.

We also broadcast and record that hangout, so even if you can’t join us live, you can still stay in the loop.

If you’d rather not watch the whole meeting, or if you’d like to have easy access to the resources we discuss, you can access the meeting minutes here.

Bonus Video!

In addition to our usual reports hangout, we did a bonus on air hangout in September from the Open Hardware Summit.  If you missed it, you can catch up here.

And here are the videos and pictures previewed in the Open Hardware Summit hangout.

It’s not too late for feedback!

If you have questions or ideas we want to hear them.  Leave a comment below and a Mach 30 board member will answer as soon as we can.