Category Archives: Open Source

Gravitas at Mach 30

Gravitas (n.) – An ancient Roman virtue that denotes seriousness and dignity. It encompasses the depth of knowledge and/or personality that comes with experience. A very old word, but a modern circumstance.

So, how do you decide who’s got it all together in a field of endeavour as broad as ‘Space’? In any situation, you look for the survivors. Those who’ve been in the ‘game’ the longest with the most success. In something as new as the Open Source Space Movement, it can be a little more difficult. This is because a good web presence or a flashy marketing video can imply credence, sometimes more than actual content can. You have to dig past the ‘vaporware’ to find the real foundations. Another telltale sign is the language. Not the difference between German or Swedish or English, but the language of the non-tech, the space enthusiast, and the astronautical engineer.

Open Source is a confusing maze for newcomers. It is a difficult paradigm to wrap the brain around when all of your existence has been cocooned in a proprietary existence. Add “Space” to that and life gets interesting. Out of the 754,000,000 hits on a search engine, where do you start? What values, what gravitas do you look for? How does this relate to Mach 30?

cropped-mach30webheaderwordpress1.jpg

Here are some of the things that we have done to promote gravitas.

Organizational maturity:

  • Mach 30 is a 501(c)(3) public charity. We’ve built a solid foundational base on which we established the organization, with the IRS paperwork to prove it
  • Strong business processes including openly shared documentation, meeting minutes, strategic plans, etc.  These provide transparency.
  • We seek out like minded organization and work with other non-profits, makers spaces, government entities, and the broader aerospace industry.

Technological stepping stone approach

  • Being biased towards mature technology means we can build and test now.
  • Having learned from the misatkes of others, we avoid the “death spiral” of giant development projects that will cost large fortunes.
  • Pursuing a technology “Road Map” development plan instead of jumping-in to shiny and fun projects
  • Tackling the true barrier to safe, sustainable, routine, and reliable spaceflight:  Namely affordable and reusable spacelift.

Open hardware development and Open Design Engine

  • True open source hardware projects (space-related or otherwise) need to share their WHOLE project, from inception to disposal.  Mach 30 does this on ODE.
  • In fact, Mach 30 is responsible for the development and operations of the opendesignengine.net because we identified this as an unfulfilled need, then filled it.  
  • Mach 30 conducts its work using open systems engineering processes.  Open source hardware development with distributed collaboration is different, as we’ve learned from past projects.

Identified need to deal with Export Controls, ITAR and more

  • Working to understand Export Controls
  • Having an Export Control Task Force
  • Meeting regularly to expand our knowledge and compliance of Export Controls

Each of these works combine to build gravitas. We’ve been at this for four years. We ask ourselves these questions frequently, “Are we doing this right?” “Are we true to our vision?” “Is this right/correct/needed?”. We strive to complete our goals. We work to make our little corner of the Open Source Space Movement a little better each day. We don’t have all the answers, but we are willing to share what we know.

Mach 30 is gaining gravitas, little by little. Each conference we attend, every event we hold, and every failure we review and improve upon adds to that weight. We are by no means perfect, but well will continue to work towards bringing humanity into a spacefairing civilization.

~ ad astra per civitatem ~
to the stars through community

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

Change

Change. It’s never easy, even when it is for the best of reasons. In a group or corporation, it can be chaotic or revolutionary. Yet, as most philosophers will tell you, it is inevitable. Here at Mach 30, we have seen a lot of change from those early days when it was simply a dream in the mind of Mach 30’s founder and president, J. Simmons.

In the last year, there has been a steady increase in volunteers and a change in board members. Maureen Carruthers, treasurer and long time member of Mach 30, stepped down as a board member in March of 2013.  Her  new position as the Program Manager for the National Robotics League is demanding much of her time.  Her contributions to board leadership and Mach 30’s communications team will be missed.  Fortunately, five new volunteers have stepped up to help on a variety of tasks such as Open Design Engine (ODE), the Export Control Taskforce and our Yuri’s Night Celebrations.

2013 is looking to be a busy year for Mach 30 events.  To start off, we celebrated our 4th year as an organization in January. New technology baffled the techies amongst us so the celebration was not as well attended as possible. However, we did overcome some of those issues in time for our Yuri’s Night Celebration. We are looking forward to a repeat of that success in January and April 2014.

Tech Gremlins bit Mach 30 again as we attempted to hold a Hangout concerning the Open Source Hardware Documentation Jam on the same day that Google+ made a sweeping upgrade to their service. We had a great hangout, but lost the video.  It is hoped that we can hold another hangout soon on this topic.

2013 has seen an explosion of projects on and off of ODE due to the diligent work of Jeremy Wright, Aaron Harper, and other volunteers.  These include improvements to ODE itself, enhancements to the Shepard Test Stand, and work on a satellite ground station. A grant proposal to SpaceGAMBIT was made in April in order to update and expand ODE as a development tool and a community.  However, the competition was stiff and ODE didn’t receive any funding. Other avenues are now being looked into to accomplish those goals.

Shepard Demo Sneak Peak

Shepard Test Stand Close-up

Mach 30 is working with Columbus State University’s Coca-Cola Space Science Center (CCSSC) to kitify the Shepard Test Stand for use in STEM programs for schools. In addition, Mach 30 volunteers are working on upgrades to the Shepard Test Stand to make it easier to build and operate.

The open source Ground Station which was featured during the Yuri’s Night Celebration has developed into a low cost satellite receiver station.  This project has been well received, and discussions about kitifying it are in process.

Two of our volunteers are working with the board to update the website and improve our social media outreach. A new theme as well as a reorganization of its content are in the works.  Take a look below for a sneak peak at the new webpage.  It is hoped by mid-summer the website makeover will be complete.

m30_new_web_ss-1

Screenshot of new web page

Last year saw the launch of the Catalyst Club, Mach 30’s annual fundraising campaign.  Support from donors, especially Catalyst Club members, is essential to the continued growth of Mach 30 and the development of open source space flight projects.

The first six months of 2013 have been exciting. The changes that have begun and will continue may feel chaotic at this point. Yet they are necessary in the long run if Mach 30 is to grow. We hope you join us in our adventures to bring Open Source Space Flight to the world.

 

Related Articles:

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!

Growing Open Design Engine

April is turning out to be quite a busy month for Open Design Engine.  So far we have found a new software development contractor to help us with the heavy lifting required for some of our new features, submitted a grant application to cover the next version of Open Design Engine, and prepared materials for the upcoming Open Source Hardware Documentation Jam.  By next week, we should have all sorts of feedback on what the Open Source Hardware community is looking for in project hosting.

Mach 30’s Ground Station Antenna

For those who don’t know, Open Design Engine is Mach 30’s free project hosting site for open source hardware projects.  We use it to host all of our publicly available projects (aka those not covered by export controls) such as the Shepard Test Stand and GS-001 (our new ground station project).  It is also home to a number of very cool projects from other users, including Andrew Starr’s Scanning Tunnelling Microscope.

Over the last couple of months, volunteers at Mach 30 have been planning the next major release of Open Design Engine as part of the work to apply for the SpaceGAMBIT Call for Projects.  As this plan came together, the volunteer team leading this effort realized Mach 30 would continue to need external software development support.  Unfortunately for us (but very fortunately for them), Littlelines, our developer for the current version of Open Design Engine, has plenty of work lined up at the moment and is unavailable for our next round of work.  All is not lost, however.  After reaching out through the volunteer team’s professional network, Mach 30 has been introduced to Mutually Human Software.  I am very happy to report Mutually Human will be a great addition to the Open Design Engine team.  Not only are they a skilled Ruby on Rails shop (Rails is the toolchain which Open Design Engine is built on), but they also “get” open source hardware and the maker community.  So much so that they are sponsoring a local startup makerspace, GR Makers.

April also saw the completion of Mach 30’s application for funding from SpaceGAMBIT’s Call for Projects to support Open Design Engine development.  Our application includes work to completely overhall the user interface, improve the infrastructure to support git repositories (among other things), implement one or more revenue generation streams so Open Design Engine can become self-sufficient, and marketing Open Design Engine to grow its user base.  I encourage you to take a look at the application.  The team did a great job in planning this new version, and in preparing the document.

Finally, I have been getting ready for the Open Source Hardware Documentation Jam.  This three day long conference/hack-a-thon is all about what the Open Source Hardware community needs to easily publish, share, and reuse documentation for open source hardware projects.  I am very excited to be included in this event for Mach 30’s work on Open Design Engine, and I am looking forward to sharing what we have learned and where we are headed, as well as finding out what the community needs from sites like Open Design Engine.  Stay tuned for updates from the Documentation Jam, and for a follow up On-Air Hangout covering the lessons learned and the community’s path forward after the event.

ad astra per civitatem