prev next

Of Google+ Pages, Google Drive, and Hangouts

by .
Comment

As most of our readers have already guessed, Mach 30 is a big fan of Google’s services.  We hold our meetings over Google+ Hangouts.  We store our documents in Google Drive.  And of course, we have an official +Mach 30 Page on Google+.  Most of the time everything just works seamlessly.  But, such is not always the case, as was demonstrated last month when we tried to hold a Hangout On Air with guest panelists who had attended the Open Source Hardware Documentation Jam, during which our live stream was completely busted, and after which the video was deleted by YouTube for an unknown reason.

After licking our  wounds, owning our mistakes, and much research, I am happy to report we have a much better integration between the +Mach 30 page, our YouTube Channel, our Google Drive storage, and Google+ Hangouts.  Specifically, we can now run Hangouts from +Mach 30 and use Google Drive (instead of +Ezri Clarke, a fake account we set up to allow us to do this in the past).  As a bonus, the Mach 30 YouTube channel is now integrated into the +Mach 30 page, with its own tab at the top.

And how do I know all of this works?  Why, I tested it, of course (with a little help from our volunteer, Jaye Sudar).  And here’s the proof.

Warning, technical content

For those that want to know how we made all of this work, here are step by step instructions.  Of course, they are provided without warranty and with the usual disclaimer that YMMV.

  1. YouTube Integration with Google+ Pages (based on these instructions from Nonprofit Tech Blog)
    1. Login to YouTube with the account that manages the organization’s channel (we had a shared account for this purpose)
    2. Go to YouTube Settings
    3. Click the Advanced link
    4. Click the “Connect with a Google+ Page” button
    5. Select the Google+ Page you want to link to your YouTube channel
    6. Click the “OK” button to confirm the change
  2. Setup username and password for Google+ Pages (based on these instructions from Google)
    1. Open a browser, we will call Browser 1, and log out of all Google Accounts (this step is optional if you do not use multiple Google accounts, but is highly recommended if you do, it can save a lot of grief later on)
    2. In Browser 1, login to the owner account for the Google+ Page you are working with (note, the owner account cannot be a Google Apps/Custom Domain account, it must be a standard Google Account – if this is not the case, change the owner of the page to a standard account and start over with step 2.1)
    3. Now follow the steps in Google’s instructions for adding a username and password to the Page (click Pages, select the Page you are working with, click on Settings in the Google+ menu, click “Setup username & password”
  3. Integrate Google Drive
    1. In a second browser, we will call Browser 2, logout of all Google accounts
    2. In Browser 2, go to http://plus.google.com and login with the username and password for the Google+ Page you are working with
    3. In Browser 2, go to http://gmail.com, you will be prompted to choose an email address (this will be the login name for the Google+ page in all Google Services, like Google Drive); I recommend something like “plusmypagename@gmail.com” so the username is easy to remember (you will be asked to confirm the new email address using text message or phone call, follow all of these steps until you get to the Gmail Inbox)
    4. In Browser 2, go to http://drive.google.com
    5. If you have existing Google Drive files or folders that you need to use in Hangouts, go back to Browser 1, go to Google Drive and share the files/folders with your new user account for the Google+ Page (chosen in step 3.3)
  4. Test, Test, Test
    At this point, everything should be good to go, so now it is time to test

    1. In Browser 1, visit the Page you are working with, and verify there is a YouTube tab; click it and you should see a list of videos from your YouTube Channel like this one
    2. In Browser 2, start a normal hangout by clicking on the “Hangout” button in the “Share” box on the Page’s home page
    3. Invite one or more attendees to help with the test
    4. Be sure to add Google Drive files to your hangout and verify both you as the Page and the other attendees can edit the files and see each others’ edits
    5. Close the Hangout
    6. In Browser 2, start a Hangout On Air by selecting “Hangouts On Air” from the Google+ menu, then scroll down until you see the “Start Hangout On Air” button on the far right and click it
    7. Name the Hangout, and invite attendees
    8. Again, add Google Drive files to the Hangout
    9. When everyone is ready to start, click the “Start Broadcast” button and wait for the broadcast to go On-Air
    10. Again, verify both you as the Page and the other attendees can edit the files from Google Drive and that you can see each others’ edits
    11. Be sure to say a few words and make sure everything is recording and broadcasting correctly
    12. When you are done, click the “End Broadcast” button
    13. Verify the video shows up in your Page’s stream and on your YouTube channel

If you can get through all of that, you should be good to go.  Happy  Google+’ing!

ad astra per civitatem

Ground Station part 1

by .
5 Comments

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!

Exploratory Learning

by .
Comment

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

by .
5 Comments

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

Growing Open Design Engine

by .
1 Comment

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