Category Archives: Mach 30 Projects

Achievements Unlocked!

It’s been a very exciting month at Mach 30.  We have made amazing progress on the Shepard Test Stand, gotten accepted to speak at a conference, and exhibited at another.  If life were a video game, Mach 30’s volunteers and partners would have just earned a whole slew of achievements.   Check them out.

Replication – Have your OSHW project built by a third party

This month, the Coca Cola Space Science Center (CCSSC) became the first group outside Mach 30 to build a Shepard Test Stand. I am particularly pleased with this achievement since it is such a concrete demonstration of our open source principles at work.  Here’s CCSSC sharing it with us over a Google+ Hangout.

CCSSC's Own Shepard Test Stand

CCSSC’s Own Shepard Test Stand

I’m not the only one who is happy about this news.  Here’s what Matt Bartow, the educational services support specialist at CCSSC, had to say.

“Congratulations to all of you at Mach 30, because I know you were very excited about seeing the first one externally built.  It was a great success, and thank you for all your help through our build process.  We will start posting our data, and, as we begin using it for student educational programming, we will also be posting about that as well.

If you need anything at all, please let us know.  Thank you so much for letting us be a part of the Shepard Program, and we are very eager to watch as everything develops for the betterment of STEM education.”

Smoke and Fire – Complete first test firing of a rocket test stand

This achievement actually goes to our friends at CCSSC. Not only did they build their own copy of the Shepard Test Stand, but a few days later they successfully fired it. Plus they were able to collect data from their tests and as you can see below, it looks very good (the flat spot in the graph is from a known bug in the Data Acquisition (DAQ) software which should be fixed shortly). Congrats to CCSSC and the Shepard project team!

CCSSC Shepard Test Fire 1 - E12-8 engine

CCSSC Shepard Test Fire 1 – E12-8 engine

Spread the Word – Get accepted as a presenter at a conference

OSHW Logo - credit the Open Source Hardware Association

I am also happy to announce that Mach 30’s Export Control Task Force has had its presentation on Open Source Hardware and Export Controls accepted as a topic at the 2013 Open Hardware Summit in Boston. The format for the presentation is a 6+1 (6 minute presentation followed by 1 minute for questions). The task force is currently working on the presentation materials, which of course will be openly licensed. Stay tuned for more details.

Show and Tell – Attend a major conference as an exhibitor

To top off the month, I was able to attend New Space 2013 where I ran Mach 30’s booth. This is the first time Mach 30 has exhibited at a major space conference, though not our first exhibit experience (we have taken the Shepard Test Stand to both the Open Hardware Summit and a regional Maker Faire).  Thanks to the hard work of our volunteers, Mach 30’s booth included display materials and two hardware projects: Shepard and the first ground station prototype. Sadly, due to fire restrictions I was not able to run a test fire on Shepard at the conference.  But New Space and Mach 30 are already talking about what needs to be done to conduct test fires next year.

Look for a complete report on the conference later this week.

Related Articles

Shepard Test Stand Update 06-17-13

From the beginning of our rocket motor test stand project, code named “Shepard”, our primary objective has been that the data we record with the test stand has to match the manufacturer’s data.  That seems like an obvious goal, but the temptation is always there to run on ahead to bigger and better things before you have a good foundation.  For our rocket motor/engine test stand program, Shepard is that foundation.  Once we know that we have the fundamentals down, we can progressively scale things up through sub-orbital, orbital, and even transorbital capable rocket engines.

Aaron Harper and I have recently been working overtime to get Shepard version 1.1 ready for one of our partners, the Coca-Cola Space Science Center (CCSSC), in Columbus, Georgia.  We’re quickly advancing toward version 2.0 which will be available as an open source hardware kit. Our hope is that the kit will be a tool that the CCSSC and others can use to safely teach hands-on rocket science.  Last week, for the first time Shepard satisfied it’s “vendor verification” requirement during an impromptu test firing.  I had just completed the build of some new hardware that was bound for CCSSC, and like a good little engineer, made sure that I tested it before shipping. The video below shows the actual test firing.

The data looked pretty good onscreen, but it wasn’t until I got back inside and took a closer look that I got excited.

Shepard 1.1 Sample Thrust Curve

The motor I test fired was a D12, and if you compare our curve to the D12’s curve in the official Estes documentation, you can see that they’re very similar.  Our curve has more noise in it, mainly because it’s raw data with no clean-up. The peak thrust, time to peak thrust, and the fall-off of the profile before propellant burnout all match up very well.  Keeping in mind that Shepard 1.1 is a retrofit of version 1.0 to test components for Shepard 2.0, and is not specifically designed for use with this hardware, that’s pretty remarkable.

By the time we tune and tighten things up on Shepard 2.0, we should have a very solid base to stand on when reaching towards our goal of hastening the advancement of humanity into a spacefaring civilization.

If you’re curious about exactly what it took to get to this point, have a look at our development logs on Open Design Engine.  We’d also be happy to answer questions that you have if you contact us through this blog, email, or any of our social media channels.  We look forward to hearing from you.

ad astra per civitatem

Ground Station part 1

DIY Ground Station, Part 1

By Aaron Harper

Communication is a fundamental part of intelligence; it is one of the things that makes us human.  It should come as no surprise that a foundational technology to mankind’s reach into space is his ability to communicate.  To communicate with a spacecraft, a specialized set of equipment is required.  It requires a computer, radio, antenna, and operator.  While this sounds fairly straightforward, space throws us a few curves.

The first issue is literally a curve…  the curvature of the earth and to a lesser degree the local terrain.  This is an issue because a spacecraft is only visible to any given spot on earth for a small part of it’s orbit.  It would really help to know in advance where the spacecraft will be at any given time in order to prepare for the communication.  As you would expect, this is possible with the application of mathematics

The second issue is that to remain in orbit, the spacecraft is moving at a fairly high velocity, and thus the time it is visible (called a window) can be quite short if it is in low earth orbit (LEO).  At a higher orbit, the craft remains visible for longer as it’s apparent motion is slower until you get to the geostationary altitude of 22,236 miles, when the apparent motion matches the earth’s rotation, making it stationary relative to a fixed point on the earth.

A third issue is the orientation of the spacecraft.  While it is generally safe to assume the business end of the antenna will be pointed at the surface of the earth, but what is up, down, left, and right makes a difference in standard antennas.  The craft will cross over different parts of the ground at different angles (skew), so a standard vertical or horizontally polarized antenna will require constant fiddling like the rabbit ears on an old TV.

The fourth issue relates to the apparent (relative) velocity of the spacecraft.  Like anything else in motion producing a waveform, the doppler shift applies.  As a train approaches the sound of the horn is higher than when it departs because the sound waves are compressed by the motion of the train relative to the listener (you).  The satellite, which is moving at a good clip relative to the ground station shifts the radio frequency as well, making tuning rather challenging.

The final issue is that radio signals become weaker as the distance increases (inverse-square law).  A very bright flashlight will be barely visible, if at all, on a distant mountain.  This is because as the light travels outward, less and less photons reach our eyes until it is below our ability to perceive it.  Spacecraft are a fairly long way away when in orbit, not to mention when they are visiting distant worlds, so receiving their signals becomes quite challenging.

Without solving these issues, stable radio communication with space assets is impossible.  Fortunately, these problems have already been solved for us, and it is these solutions working in concert that become a 21st century ground station.  Today a ground station designed to receive voice and data traffic from spacecraft such as ISS may be constructed using common components for under $200.00, not the millions it cost NASA.

A computer running software to predict a satellite pass is the first component of a ground station.  This will easily predict satellite passes, giving us the craft’s precise location in the sky at any given time, though it generally will not take terrain into account.  GPredict is a free, open source program that has an intuitive interface, displaying the data on a table or the view on a map or polar graph.  With some plug-ins, it also solves a few of the other issues as well.

The skew issue is solved by using circular polarization which only cares if the signal is sent with a right hand or left hand polarization (imagine a spiral from the spacecraft to the ground station), not which way the transmit and receive antennas are oriented.  This is a function of antenna design, and a bit of a “black art” compared to the rest of the solutions.  This brings us to a decision…  to point or not to point.

There are plenty of omnidirectional circular polarized antenna designs, but they have a weakness.  An antenna which points in all directions at once can only increase the signal (gain) by a factor of 8 as a theoretical maximum (+9dB), while antennas which focus on one direction (directional antennas) can go much higher, bringing in the weak signals.  The disadvantage is that the higher the antenna gain, the more directional the pattern, and the more precisely the antenna must be aimed.  This increases complexity, mass, and expense.  Always a tradeoff.

The ability to point a directional array, while technically optional for LEO spacecraft, is mandatory for anything in geostationary orbit or beyond.  The mechanism used to point the antenna or array of antennas are largely up to the imagination of the engineer, but they must be made to point accurately enough so that the spacecraft stays within the peak gain area (lobe) of the antenna and it is able to do so in high wind without damage.  Keep in mind that flat panel antennas as well as dishes make excellent sails on blustery days.

Now, wouldn’t it be nice if the prediction software such as GPredict were able to sent the direction of the spacecraft to the pointing assembly (Az-El mount)?  Most can!  In GPredict, a module called hamlib may be added which facilitates the communications between the computer running GPredict and equipment including Az-El mounts.  That said, for the sub-$200.00 ground station, an omnidirectional antenna will be used.
Since the position and velocity of the craft are known, the prediction software may be used to calculate the anticipated doppler shift during the satellite pass.  Using this information in GPredict, some radios may be tuned directly using the hamlib plugin.  This makes running a modern, well integrated ground station a relatively simple process.  As a spacecraft comes into view, simply select it on the software and the hamlib plugin will point the antenna and keep the radio in tune.  This solves all but the last issue in setting up a ground station, that of signal strength.

Major factors which contribute to the ability of a signal to reach from the transmitter to the receiver are the output power of the transmitter, the gain of the transmitter antenna, the distance (inverse square of the distance, as mentioned before), the gain of the receive antenna, and the sensitivity of the receiver.  Unless we designed it, we don’t have much control over the transmitter output power, antenna gain, or the distance (orbital altitude) of the spacecraft.  This leaves the receive antenna gain and receiver sensitivity as areas the builder of a ground station can optimize things.

Fortunately for us, modern radio receivers have really improved.  Back in the day, we were lucky to get a sensitivity figure of -84dB, but today a $20.00 USB dongle is capable of -114dB.  To put this into perspective, every 3dB difference essentially doubles the measurement in this logarithmic scale.  This means that the 30dB difference represents a real improvement of 2 to the 10th power, or 1024.  In English, a modern USB dongle receiver available on Ebay or Amazon is over 1000 times more sensitive than those used in the 60’s that communicated with our astronauts on the moon!

Sensitivity and low cost isn’t the only thing these receivers have going for them. those same receivers which had the 84dB sensitivity were capable of tuning only within a fairly narrow band (406 – 549 Mhz).  The dongle (a Realtek RTL2832u TV receiver) is capable of tuning 24MHZ to roughly 1850MHz by way of comparison.  Simply put, this dongle makes the bridge between a modern computer and an antenna, turning it into the ground station Apollo era engineers could only dream of.  The only wildcard is the antenna.

While there are many antenna designs, to keep the ground station simple and below $200.00, we must select the best omnidirectional solution instead of building (and paying for) an Az-El mount.  A little research has shown a simple design with excellent gain characteristics that can be built by a hobbyist; the “eggbeater” antenna.  As it’s name suggests, this antenna’s design looks like an eggbeater with two wire loops at 90 degrees to one another.  This antenna is circularly polarized, and has a gain of around 8dB.  Construction details are available at here.

This leaves one final component.  The operator is a person with the responsibility and/or interest to operate the ground station.  They have the knowledge of how the systems work, and get usable audio and/or data from the system.  While a license (FCC amateur radio, ham license) is not required for reception in the United States, local, homeowner association, and national regulations vary.  Check if in doubt.  That said, a ham license will be required for the next step: transmitting.

Transmitting voice and data is required for most use of space based assets and real communication.  This will be the subject of the next $200.00 project write up, and as said before, the use will require an FCC license.  A technician class ham radio license is quite easy to get, with no requirement to learn morse code.  The concepts you will learn in getting one will serve you well as an operator of a full fledged ground station.  Transmitting capability is an upgrade to the ground station that will take your equipment to the next level and will let you use space for your communication needs.  Stay tuned!

Transparency Means Sharing Failures and Successes

Maureen and I had lunch with Jerry from Maui Makers and the Hackerspace Space Program a couple of weeks ago.  We talked about a number of things including Open Design Engine, Makerspaces (which led to a brief tour of Dayton Diode), and Open Source Hardware.

It was our conversation around open source hardware which had me thinking back to our meeting days later.  We started off talking about the usual stuff:  licensing, the new Open Source Hardware Association, and of course we talked about open source spaceflight.

But then, sitting there in a Panera Bread over coffee and snacks, the conversation turned toward questions we don’t always address when talking about open source hardware.  Questions like:

  • What should happen to abandoned projects on sites like Open Design Engine?” – Well, we should keep them up for others to learn from or fork into new projects, which is what Source Forge does.
  • But won’t that eventually lead to lots of incomplete projects?” – Probably, which on the surface sounds like a “bad thing”, especially if there are many more abandoned projects than completed or active ones.
  • And what if the reason the project was abandoned was it just didn’t work?  What if it was a failure???” – People really don’t like to share their failures…
  • But, wouldn’t you want to know about the things that didn’t work so you don’t have to discover that for yourself?” – Well, yes. . . Of course. . .

And then it happened:  the light bulb flashed on, and we started talking very excitedly about science, engineering, publishing, and how hardly anyone writes about their failures.  They only share their successes.  In fact, if someone were to publish one of their failures, their peers would stare at them with bewildered expressions and ask “What are you thinking?”

It was Maureen who put it best, pointing out that we need to change the culture so people’s reaction becomes “What do you mean you didn’t share your failure?!?!

In that spirit, allow me to present an update on Mach 30’s first open source hardware project, including the good with the bad, so we can all learn from the progress Mach 30 has made.

Shepard Test Stand Update

One concept for the Shepard Test Stand

Things have been very busy at the Shepard Test Stand.  Since announcing the project in May, we have completed the requirements analysis, the block diagram, and are working steadily through Shepard’s design.  That’s pretty good news.  We also submitted two Shepard related presentation proposals to the Open Hardware Summit.

The first submission was a plenary session presentation looking at the engineering process used to develop Shepard and the instrumental role Open Design Engine played in the process.  The second submission was a demo of the Shepard Test Stand.   We were disappointed when our plenary presentation was not accepted, but were pleased to be included as one of the demo projects.

So Shepard has had its share of successes, but what about the failures?  Where have things not gone as planned?  The most significant challenge for Shepard is our schedule.  We are more than a month behind, and we now have a confirmed deadline of September 27, 2012 to conduct a public demonstration of the test stand.  This gives us just short of two months to complete the design (which is mercifully nearing completion), assemble, test, and document Shepard.  That is a tight time frame, especially given our work to date.

So, how did we get so far behind schedule?

I see two driving factors.  First, we were probably a little aggressive in the scope of Shepard, and in the time we allotted ourselves to complete the project–especially when you consider this was our first open source hardware project.   Second, we split our focus between Shepard and our work on the Far Horizons Project High Altitude Balloon.  Our group of volunteers is still pretty small, and many ended up working on both projects.  With limited time, something had to give.  At the time, the deadlines associated with the High Altitude Balloon (HAB) launch meant that Shepard’s timeline that had to give.

Still, with the current round of development work on the HAB basically wrapped up, we will be turning our full attention to the Shepard Test Stand.  Hopefully, we can find a way to get caught back up and be ready for the Open Hardware Summit.

Only time will tell.

Up, Up, and Away: Live(ish) coverage of High Altitude Ballooning

Today’s the day!

Mach 30 President, J. Simmons and volunteer, Jeremy Wright are in Chicago to begin documenting Open Design Engine‘s first High Altitude Balloon project.

This project is a partnership between Adler Planetarium‘s Far Horizons Project and Albuquerque’s Hackerspace, Quelab.  Adler is providing the design for the balloon, Quelab will build and launch the balloon, and Mach 30 is providing project hosting space on Open Design Engine and project coordination.

As an added bonus, Mach 30 will also be participating in this weekend’s launch.

Watch this space throughout the weekend for new videos, updates and more!

Design Meeting–Live!

You can watch the first design meeting live here–unless the meeting is over, then you should be able to see the video playback.

Photos

A small sample of the photos we took on the trip.

Get Involved!

Tweet your questions and comments about the projects with the hashtag #M30AdlerHAB we’ll answer as quickly as we can.  You can also leave comments below.

For more detailed information about the project as it progresses, watch the project page on ODE, and follow the updates on meeting minutes here.