A Users Guide to Pegasus II

Pegasus II is an experiment in real-time “Internet of Things” technologies from the edge of space.   The experiment uses a High Altitude Balloon (HAB) as a delivery system to carry a payload crammed with sensors, video, and radios into the remote and hostile region of the upper atmosphere known as near space.  The ascent of the flight will terminate at 100,000 feet above the surface of the earth. The experiment allows users to participate in the flight in several ways.

We are scheduled for launch on Wednesday April 13th at 12pm CDT.

(1) View telemetry from the craft in only milliseconds from when the measurement is taken from anywhere in the world.

(2) Watch a live video broadcast of the flight and launch. Note: Flight video is highly experimental.  We will learn much from this flight in terms of live video performance from remote UAVs.

(3) Communicate with the craft during flight by sending messages to the craft. These messages get recorded into the video record of the flight.

(4) Receive SMS text messages on your phone as Pegasus II makes flight milestones.

(5) View a live map that updates the positions of the chase vehicle and Pegasus II as it flies.

There are 2 ways to include yourself in the experiment, Web and phone.

Best Experience

  • Go to the Web site and sign up for flight notifications.  These will allow Pegasus II to text your phone when it launches and you will no miss the flight regardless of whether you are using the Web site or mobile apps.
  • Follow us on Twitter @PegasusMission.  This will keep you informed on any flight delays and alert you of time-to-launch.

Web Site

  • Watch the live launch and flight video.
  • Watch live telemetry and mapping during the flight.

Mobile Apps

  • Download and install the mobile app by searching your app store for “Pegasus Mission”.  If you have already installed the app, we suggest that you uninstall and reinstall the app to help us ensure consistency.
  •  Connect to WiFi if possible.  This will help keep the connections “hot” and reduce dropped connections.  Reconnections can be slow if the signal is not strong.
  • Watch live telemetry and mapping
  • Send us a user message.  We love getting “Hello from <location>” from the users around the world.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Advertisement

The Pegasus Mission and You

The Pegasus Mission is all about bringing you a near space adventure, an experience in High Altitude Flight that you may have never witnessed before.  It is about you.

You can help us out promoting the flight of Pegasus II Oct 5 by using your social networks to promote the flight and get users to sign up for SMS notifications and the craft will send a text message to users to alert them of the launch.

Pegasus II is high altitude mission to near space providing a global real-time experience to users from the upper atmosphere using Microsoft Azure and experimental technology.

Windows and Android apps available in app/play stores for Pegasus II’s mission to near space.  iOS app submitted last night and hopefully will be available by flight time Oct 5 ~10AM MDT from Cheyenne, WY, USA

Search “Pegasus Mission” to find the mobile apps.

Warning:  This mission has no guarantee of success. The mission team is working in a remote and hostile environment with high sensitive equipment nearly 20 miles above the surface of the earth. However, attempting to try what has never been done before is courageous and noble effort itself in an effort to learn and provide a unique experience to others.

High Altitude Science Firsts

  • Real-time video transmission from a HAB
  • Coordinated global broadcast of real-time telemetry and mapping through Web and mobile apps
  • Global user communications direct to HAB inflight
  • Craft notifications via SMS to users
  • Widely available HAS mission that is publicly and globally consumable
  • Real-time communications to/from HAB

Mission Objectives

  • Low latency, high throughput, linearly scalable and bidirectional communications
  • Mobile app with real-time experiences
  • Web site with real-time experiences
  • Security: Distributed authorization
  • Altitude: 100, 000 feet (19 miles, 30.5 kilometers)
  • Live video feed and onboard video from near space
    • Curvature of earth
    • Edge of visible atmosphere
    • Blackness of space
  • Onboard 3D view (5 cameras up, down, 3Xout)
  • Real-time broadcast of telemetry and mapping
  • Real-time communications between users and craft
  • Telemetry capture
  • Remote Intelligence: Automated flight operations from data center 1,000 miles away.
    • Live camera rotation
    • Delivery system release
    • Low altitude high speed main parachute deployment
  • 2K users watching flight (aspirational)

Resources

Web Site: https://www.pegasusmission.io (Live video + telemetry + maps)
Sign up for SMS flight notifications and craft will text you when it launches.
Mobile apps (Live telemetry + maps + sending user messages to craft inflight)
Facebook: http://www.facebook.com/pegasusmission
Twitter: @PegasusMission
Blog: http://pegasusmission.com
LinkedIn: “#PegasusMission”

Dare Mighty Things 😀

Unique Exchange of Equity

When I look back at the nexus of “The Pegasus Mission” Mark and I made a single decision that transformed the challenge into something grander than we initially imagined. Because we were working with real-time, open, and distributed systems coupled to IoT, we needed something compelling that placed an emphasis and reason to the participate in the technology. We did not want to trivialize the technology in any way, and that led to a focus on driving a unique user experience that people had never seen before. By focusing on the entertainment value and taking users to a place they could not travel, we could passively couple both research and technology. It is a unique exchange of equity between the mission team and the users. The users get an incredible experience they could not otherwise obtain, and we get to test the premise of the research and the technology while they do it. While we initially believed our thoughts were original, they were not. The concept was originated a long time ago by a great explorer, Jacques Cousteau.

Perhaps you may remember watching “The Undersea World of Jacques Cousteau” on television when you were much younger. The Cousteau team would travel to remote locations and explore the oceans. This was in a time where underwater filming requiring highly customized equipment and scuba diving was not something many people could do. In fact, Cousteau invented scuba diving with his aqualung. You probably cannot remember the name of single researcher onboard their ship, the Calypso, or any of the research they were doing…but you remember the marvel of undersea world shown to you for the first time. We were absolutely enthralled watching the Cousteau team take risks below the surface in order to gain an understanding of what was down there. The act of watching the television special enabled us to be drawn into a marvelous exchange of equity, because that research, that we cannot remember, would never have been possible without us watching it. Ultimately, we all benefited from our own participation because the Cousteau team help make our lives better through the understanding and research that they did in the oceans around the world. It was an ironic twist that we can in some way thank ourselves for making the oceans a better place.   Our mission to near space is fundamentally no different and depends on users watching flight through our Web Site or phone apps.

With less than 2 weeks away from the launch of Pegasus II, where we take you not down into the oceans, rather into the heavens 20 miles into the upper atmosphere. We will test live video onboard the craft for the first time to bring you a completely unique experience from three times higher than where commercial aircraft can travel. You will see the curvature of the earth, the edge of the atmosphere, and the blackness of space in real-time. Additionally, we will stream telemetry from the craft, and map of the showing the position of the craft and our chase vehicle, all in real-time. Finally, we will let you send a 40 character message to the craft in flight and get your personal message into the flight video record.

While the endeavor is not without risk and success is not a guarantee. Unlike a television special, we will be executing the mission live and I can guarantee will it not be “perfect”.  Innovation is an inherently a risky proposition and it takes a courageous team to live it out and challenge assumptions about what is possible…and attempt to bring you an unforgettable experience. We can only try our best and I believe that the having the fortitude to attempt what has not been done before is noble effort in itself.

You can sign up for SMS flight notifications and we will text your phone when Pegasus II is launched https://www.pegasusmission.io

My thoughts on Innovation from nearly 2 year ago. https://www.youtube.com/watch?v=uMVix6p33Zs

Pegasus-II

We are getting ready for Pegasus-II.  We will target the American West for the flight slightly East of the Continental Divide.  We hope to get some outstanding video of the Rocky Mountains.  Mission parameters will include LIVE video where users will get to see the Pegasus “Eye-In-Sky” using Azure Media Services as well as a target celling of 100,000 feet.  Not to mention an additional 4 or 5 cameras onboard the craft.

We have upped the ante with live video, but also using 38 sensors capable of streaming the telemetry in real-time to Phone Apps (Android, iOS, and Windows Phone) as well as a map to display the position of the Pegasus-II and the chase vehicle in real-time.

Adding to the game plan, we will be allowing Web site and phone app users to place information onboard Pegasus-II while inflight and supply these users with an incredible photo of the craft at its apex as a thank you.

It’s game ON for Pegasus-II and pushing the limits of real-time IOT.

The Power Of Self-Organizing Systems

Pegasus-I was a system with the overall goal to broadcast telemetry and control flight operations in real-time. The system was a combination of organized and self-organized sub-systems that interacted with Pegasus-I during the flight. Let’s examine how we structured this and role of self-organizing systems in the mission as well as how we will leverage them for Pegasus-II and Pegasus-III in the near future.

A system is an organized set of things that form a complex whole designed to achieve a goal. The system designed and used for Pegasus-I included seven (7) interconnected actors, Pegasus-I, Ground Station, Chase Vehicle, Web site, and three (3) Azure Blob Storage containers. The nodes could transmit, receive, or transmit and receive information depending on their function. The overall system was composed on nine (9) different sub-systems that managed telemetry and flight operations. These sub-systems communicated with the actors to execute specific tasks within a sub-system.

Three (3) sub-systems were organized, meaning we had predetermined and configured paths for the information to flow. These sub-systems were associated with storing telemetry received from Pegasus-I by the Ground Station and the Chase Vehicle as well as storing the location of the Chase Vehicle itself. These sub-systems were required to be organized because our storage containers in Azure Blob Storage do not connect to Piraeus. Piraeus requires a durable subscription to be configured to any passive receiver. Below in [Figure 1] shows the system actors and organized sub-system graphs for telemetry and location. You will notice that the only organized sub-systems simply ingest telemetry and location from either the Ground Station or Chase Vehicle to Azure Blob Storage. The Web site does not send or receive any information through these sub-systems.

Figure 1

Figure1

Four (4) of sub-systems were self-organizing, which means they organize themselves on-the-fly to create sub-systems that did not exist before. If these new sub-systems create ephemeral subscriptions to receive information, then those subscriptions will only last for the duration of the connection by the caller. They are disposed upon disconnect. The reason we made this choice for Pegasus-I was that certain sub-systems were only concerned with “now”, not any past history of events to or from the inflight craft. This also reduced the complexity of the system design because we could depend on Piraeus to create the sub-system graphs in Orleans on demand and connect them to the appropriate parties immediately.

When the Web Site connected to the Piraeus gateway, it was entitled to subscribe to the same topics grains in Orleans as the Azure Blob Storage containers. This allowed the Web site to create new sub-systems on-the-fly to receive telemetry and location, shown in [Figure 2]. If the Web site disconnected, both the new subscriptions and their respective observers would be disposed and upon reconnection the sub-systems would be recreated by Piraeus within Orleans.

Figure 2

Figure2

This takes care storing and displaying telemetry without requiring complex configuration or maintenance, but what about those critical flight operations for delivery system release and parachute deployment? We used the same ability for self-organization for those also. We only need to configure topics [Figure 3] for the Web site to send specific commands to the responsible parties, Ground Station and Chase Vehicle.

Figure 3

Figure3

Once the Ground Station and Chase Vehicle connection to the Piraeus gateway, the sub-systems were created [Figure 4] and communications enabled from the Web site to these parties.

Figure 4

Figure4

When you look at the entire system and its sub-systems [Figure 5], it is a complex system. However, using self-organizing systems within Piraeus, we were able to take advantage of creating the sub-systems without the need to configure all of them in advance. We only configured seven (7) topic grains and three (3) subscription grains in Orleans to design the entire system and enable communications and storage so users could view the flight in real-time and allow Mark and I to control flight operations.

Figure 5

Figure5

Instead of describing the various uses of self-organizing systems, which are numerous, I want to communicate how the planning for Pegasus-II and Pegasus-III will use them. We want to be able to bring the excitement of high altitude science to people in a very personal way and allow people actively participate in the experiment in real-time. In our own way, it is like being onboard the Calypso with Jacques Cousteau. Doing this requires that we leverage not only a Web site, but also phone apps to broadcast to users real-time telemetry, maps, and streaming video through Pegasus’s eye-in-the-sky. These phone apps will receive telemetry, location and update rapidly from 100K feet in the upper atmosphere to user’s eye. Additionally, we working on concepts to get some user-defined personalized information onboard the craft during flight such that users can directly communicate with Pegasus and see personal message during flight. However, we cannot control the number of people using the phone apps or when the users choose to turn the apps on or off, or simply a phone dropping a connection due to poor reception. Therefore, we need a self-organizing system for these users, and Piraeus supports just that for this type of experience.

-Matt Long

Orleans Above the Cloud – Piraeus Overview

Disclaimer

The “Internet of Things”, IOT, is a big topic and involves many important concepts about systems, e.g., open vs closed, organized, self-organizing, closed and open-loops. All are worthy topics to understand to put a foundation under IOT. However, I will resist these topics and only discuss Piraeus and the role that Orleans has in the architecture for the sake of brevity.

Piraeus is a multi-channel, multi-protocol, in-memory event broker. It enables edge devices or services to connect and transmit or receive information from other system entities without any coupling and without system entities having direct knowledge of each other. It is a high throughput, low latency, and linearly scalable Operational Technology that simplifies the ability for an open-system to achieve its goal.

Diagram of the physical architecture used in Pegasus-I, i.e., how we got the real-time out Piraeus and Orleans.

PIArchitecture

The Piraeus Architecture (Operational Technology)  that was used for Pegasus-I

PiraeusArchitecture

A system can be modeled as a directed graph and such Piraeus uses this simple construct to enable communications through its gateway to components within a system or sub-system.  Information enters Piraeus through its gateway, then is distributed throughout the graph.  The leaves of the graph are connected to either active or passive system components that receive the information.

The components of Piraeus are relatively simple. A gateway exists that can receive information through a variety of channels and protocols. Once this information is received by the Piraeus gateway it is fed into the appropriate graph for that specific information topic. The node that receives this information is a virtual actor, called a grain inside of the Orleans host process. This type of grain is considered a “topic” within Piraeus and topics are graphed to “subscription” grains, which Orleans can communicate. Once the information enters the topic grain is fanned out to all subscription grains associated with the topic. The subscription grains are observable and feed information directly and immediately to the specific channel and protocol that is associated with the subscription.  There is no polling in the entire Piraeus architecture…ever.

That is a high-level summary, so let’s dig deeper into what is happening under the covers. Topic grains are always provisioned prior to communications being established. They describe the head node or ingress resource of a sub-graph as part of a system or sub-system. The topic grain’s job is to act as a resource for subscription grains to attach and fulfill the sub-graph enabling transmitter and receiver to communicate unidirectional. This gives us consistency with how a generalized system would behave.

The subscription grains can be either durable or ephemeral. Durable subscription grains are configured with metadata and attached to a topic grain. The metadata is part of the subscription grain-state within Orleans and therefore requires no orthogonal look up or database to manage that would impact performance. Durable subscriptions are used by either active or passive receivers. An active receiver is one that creates a connection to the Piraeus gateway. Once that active connection is established, the identity of the actor is used to create and associate “observables” with the specific subscriptions grain(s) for that identity.  When information flows into the subscription grain from the topic grain, the observable for the subscription is already established and associated with the channel and protocol of the receiver. This creates a direct pipeline between transmitter and receiver.  A passive receiver is a service that does not connect directly to the Piraeus gateway. When information is passed to these durable subscriptions, the subscription grain will forward the information immediately to the service. Piraeus supports RESTful Web services, Event Hubs, Azure Blob Storage, and Service Bus for these passive subscriptions.  This means it is possible to create, e.g., to create Web service, and start receiving information from Piraeus without doing anything else.

Ephemeral subscriptions can be used with self-organizing systems.  These are systems that can organically change and system actors can enter and exit arbitrarily.  Ephemeral subscriptions only exists for the duration of the active channel.  Once the channel is dropped, the subscription grain and its observable are removed and resources are disposed.  This enables a self-system to organize without prior knowledge of edge system components.  Of course, access control plays a major component on what is allowed, which is not a topic for this post.

Orleans is a radically different type of technology, which is a key enabler for the Pegasus-I mission to near space. It makes possible some of the key concepts around flowing information at low latency and organizing graphs through its concept of virtual in-memory actors, i.e., grains.   Observables in Orleans also give Piraeus a simple way to mate specific receivers to their respective subscription grains without need to leverage any store and forward technologies and makes for a remarkably elegant end-2-end communications story that is simple to use. We were able to get telemetry from Pegasus-I inflight to the Web site for a user to view in about 20 milliseconds on average, going from a radio transmission from Pegasus to our field gateways and over MiFi on our phones to Piraeus.  Of course, we also proved it also works at 85,000 feet, 2.2% atmosphere, and -60 degrees Fahrenheit.

Notable Technical Details

  • Orleans is a high throughput, low latency, and linearly scalable technology that enables Piraeus to easily manage a system graph or sub-graph to enable communications between system components.
  • Subscription grains are either durable or ephemeral in the context of Piraeus.
  • Subscription grains can be associated with either active or passive receivers.
  • Piraeus enables systems to be either organized or self-organizing.
  • Information flow is in-memory by default, but can be persisted if required.
  • Piraeus uses no databases or storage accounts to perform its operations.
  • Orleans grain-state is persisted in a customized Orleans Storage Provider that leverages Redis.
  • Piraeus has a multi-channel and multi-protocol gateway that does not couple channel and protocol between transmitter and receiver.
  • There is no intrinsic limitation to message size within Piraeus

There is a tremendous amount more about the technical detail, which is far to overwhelming for this overview post.  I will try to post more fined-grained detail at a later date for those interested.

Best Wishes,

-Matt Long

Pegasus-1 Mission Photos and Video

Photo Montage Video | Flight Video | Narrated Video | Mission Prep Video | Flickr | The Miracle of Pegasus-1 | Pegasus Prequel

MarkAndMatt
Mark Nichols and Matt Long – The Pegasus Mission Engineering Team
Mark and Matt the night before flight
Matt Long (foreground) and Mark Nichols check equipment the night before launch.
Mark
Mark Nichols making a preflight adjustment with a cutting tool.
Software check
Matt Long verifying flight operations software.
Mark and Matt tie off the delivery system
Matt Long and Mark Nichols tie of the delivery system, a high altitude balloon ~6.5′ in diameter, with 165 cubic feet of helium.
LaunchCrew1
Gupreet Singh Pegasus-1 Launch and Chase Team
LaunchCrew2
Rohit Puri Pegasus-1 Launch and Chase Team
Electronics
Sensor Payload for Pegasus-1
Payload Housing
Payload Housing
Preflight payload
Preflight payload assembly
Launch site from Pegasus-1
Launch site from Pegasus-1
Exiting the clouds
Pegasus-1 exiting the clouds in lower atmosphere
Sensor package
Sensor package

13-15 miles up
Pegaus-1 13-15 miles up
Mid-Level Flight
Mid-Level Flight of Pegasus-1
Entering the Stratosphere
Pegasus-1 entering the Stratosphere
Directional Ground Station
Directional Ground Station with extended range
Mark Nichols Directional Ground Station
Mark Nichols Directional Ground Station
Location, Location, Location
Ham Radio and GPS for tracking Pegasus-1
Getting Ready
Prep the launch site, Othello, WA 01/28/2015
Dragging the drogue
12″ Drogue parachute dragging behind Pegasus-1
~85,000 feet, 2.2% atm, -60 degrees
Flight APEX on Pegasus-1 ~85,000 feet, 2.2% atm, -60 degrees
Near Flight Apex
The beauty of our planet as seen from Pegasus-1

 

 

Upper1
A planet (we think) seen from Pegasus-1 during the daytime.
V__0039
Pegasus-1 recovered one week after flight.
BalloonRelease
Balloon released and caught on camera. It will burst at 26 foot diameter.

The Miracle of Pegasus-1  | Pegasus Prequel

Pegasus Mission – Prequel

It was 11/07/2014 when I sent an email to Mark Nichols, my partner in this adventure, which contained on the subject line “Must do this” and a link in the body of the message. About 5 minutes later a simple response, “Absolutely”. The Pegasus Mission was born, a real-time IOT experiment in the upper atmosphere with a high altitude balloon (HAB) as a delivery system.

The first days of imagining this experiment we documented a simple set of goals and technical objectives:

  • A photo of the curvature of the Earth, the edge of the atmosphere, and the blackness of space.
  • Real-time telemetry stream of metrological information and location.
  • Demonstrate real-time control over the in-flight craft.
  • Make others participants in the flight through real-time broadcasting of the telemetry.
  • Survive (implicit goal)

Pegasus is truly an intersection of STEM fields, where the “T” is only a part of the equation. There is a considerable amount of engineering involved to make it tangible, to make it fly, to recover the craft, and get communications with the craft in real-time (milliseconds). Mark knows devices and is a craftsman with mechanical things. He can design the electrical systems, the communications packages, and craft the payload and its mechanical devices. I would take care of the aeronautical engineering of the flight and the Operational Technology. We would cross multiple fields from electrical, mechanical, aeronautical, even civil engineering and coupling that with cloud services and an Operational Technology, Piraeus, truly on the frontiers boundaries of what is possible. AFAIK, the first real-time broadcast of IOT technology from the upper atmosphere of our planet.

You could put a payload on a high altitude balloon and with some tools on the Internet likely make it fly. However, you would not know what was going to happen. Its challenge rooted in the hostile environment of the upper atmosphere. We could cover the basics and understand the flight dynamics, but you cannot test something with plus 200mph wind velocities at minus 60 degrees Fahrenheit in your basement. We would have to do our best engineering, our best craftsmanship, and take our shot.

Mark and I were discussing mission parameters on the phone one day, when I laughed up the idea of releasing the delivery system and plummeting toward the surface of the Earth, only to deploy the parachute just above ground level. Mark said, “A HALO drop. Let’s do that”, to paraphrase. . I told Mark, “if you tell me that you can get that parachute out fast enough, then I am okay with it.” Hurling thousands of dollars of equipment toward the surface of the earth faster than a car can travel was spooky proposition, but compelling. We would go for it.

Complexity was high (probably too high) and time was short. We had until that last week of January 2015 to get Pegasus-1 ready. Only a few months from when we conjured up the experiment from our collective imaginations. Mark was spending nights designing the sensor package and craft, I was trying to work through the aeronautics and prep of Piraeus, our Operational Technology. Sensors, servos, radio transmission, control console, MiFi, Piraeus, and Web site all had to work together, it was serial reliability. If everything does not work, we would lose the craft.

We were constantly buying equipment, regulators, sensors, radio equipment, cameras, antennas, meteorological balloons, parachutes. Weight is the deciding the factor, and has weight began to increase, it got more complex and more equipment was shipped to us. Our “bag” of equipment for launch would weigh about 70 lbs to get the 4 lb payload airborne.

Time had run out and we had a week before the conference. We decided to try for a test flight the week before at a remote grass airfield in Kankakee, IL. Weather conditions were suboptimal, but within range of what we thought possible. There was much work to do, not only did Pegasus-1’s electronics have to work, we would need a software interface between the transmitter/receiver and Piraeus, running in Microsoft Azure. While Mark worked on the payload assembly and testing the electronics, I would work in the software interface. We had feverishly worked 19 hour days completing our respective tasks, but still did not have an integrated system. There were also the logistical considerations, getting the helium, FAA flight advisories, permission for a launch site, etc. It’s not a backyard type of experiment, you have to plan it in advance. Completely exhausted, we had missed our launch window for the test flight. The operation would now move from central Illinois to the conference in Seattle where we would perform our session, then try to fly the following day. The weather forecast was optimal for Othello, WA on 01/28/2015. We would attempt to resolve any remaining issues and get airborne in the treeless environment of eastern Washington State.

-Matt Long

Matt.Long@microsoft.com

Photos and Video | The Miracle of Pegasus-1

The Miracle of Pegasus-1

The Pegaus-1 Mission launch schedule 01/28/2015 from Othello, WA at 11AM PST and was delayed several hours. We eventually got airborne mid-afternoon. Several technical problems occurred, e.g. the Ham radio was not operational. This was the backup location system in case we lost the primary GPS, and now we were flying with only a single system to locate the craft. The tracking devices were a directional ground station and an omnidirectional mobile station that we used in the chase vehicle. The ground station had long theoretical range to maintain contact, while the mobile station was much shorter in range. Early in the flight the ground station, experienced some issues and lost contact with Pegasus-1. The shorter range mobile unit was all we had to maintain contact with Pegasus’s location. We had spent many hours trying to make sure we would have contact with Pegasus-1; otherwise we would lose her in a lonely field in a lonely place. Now we were hanging by a thread with only the primary GPS and the mobile unit. As Pegasus ascended and turned due East, the ground station came back online and we had 2 points of contact with the craft. Some relief, but still living only on primary GPS.

The telemetry stream was amazing as we could see the information streaming in every 2 seconds from Pegasus-1. The altitude on the GPS was not updating as fast as we expected, which also led to suspicions on the accuracy of the primary GPS. Was Pegasus-1 where we thought it was? The low hanging cloud layer gave us no visual on the craft, we just had to go with what we had. The ground units pushed the telemetry into Piraeus, our Operational Technology, where a Web site could instantly display not only the telemetry, but also the location of Pegasus-1 on Bing Map. Our chase team used the Bing Map updates to keep positioning and maintaining contact. This was very entertaining.

We were expected a turn to the West in the upper atmosphere, almost reversing the course that we had traveled. This occurred as expected with a slight WNW heading from the lower altitude E heading. We had purposely not expected to take Pegasus-1 to burst altitude, instead we intended to control the descent with a remote release of the delivery system. As we moved further to the West and slightly North the craft was tracking further from the main road, US HWY 26. Given that the altitude had reached mission objectives and that ruggedness of the side roads, we decided to release the balloon and begin the descent stage. Our descent was to be a HALO drop to about 1,000 meters above the surface of the earth where the main parachute would be deployed. Our tiny 12″ drogue chute would keep Pegasus-1 in a vertical position to maintain contact during the rapid descent, expected to take 10-13 minutes from the apex of the flight. We released the delivery system and began the descent stage dropping at 212mph from about 85,000 feet.

Only a few seconds later, at 75,000 feet, we lost primary GPS, but kept streaming the other telemetry data. The chase vehicle was positioned on a gravel road approximately 1.5 miles to the SE of Pegasus-1 when we lost GPS. Our strategy was to move either North of South to intercept, but without GPS and the low hanging cloud layer, we had to get a visual. Time had passed and we continued to look for the craft in the agricultural fields East of Othello, WA. It was going to get dark and we needed to back to launch site and pack up for the drive back to Seattle. We had lost Pegasus-1, but had proved the technology Piraeus, command and control, much of the craft design, and we did have the telemetry…but we didn’t have the video from the onboard GoPro camera or our craft. Now packed up and getting dark, we began the 3+ hour drive back to Seattle, disappointed without the recovery of the Pegasus-1.

Several days later I was reviewing the telemetry and noticed an abnormality. It appeared the primary GPS had come back online with only 30 seconds of flight time left. The chase team was scanning the horizon for signs of the craft when this occurred. We would not have noticed, nor expected it. Could Pegasus-1 have called for help at the last stages of flight? I considered this a remote possibility and began to check path, air pressure, and other telemetry to determine whether this “burp” of location information could possibly be valid. The location “burp” was in a direct line from where the GPS cut out at 75,000 feet and in the expected path. Careful analysis lead us to believe that Pegasus-1 was about 1.5 miles due North of where we had stopped the chase vehicle. The probability cone as only about 600 feet from the last location. Had we found where the craft actually rests?

Our excitement was high and Mark Nichols, my partner in this adventure, had decided to stay an extra day in Seattle and make the 250 mile drive back to the site and try to recover Pegasus-1. He called me and said he was standing on the spot, but no sign of the craft. He wandered through the fields for a time, then decided to drive a short distance to a nearby business to see if anyone had seen a UFO in the field. The business informed him that they knew nothing and he began his disappointing drive back to Seattle. Mark pulled out of the business toward the same point that he had started and noticed some orange out the left side of the automobile. He stopped. He saw some green, it looked like trash in a field. If the drogue parachute was orange and white, what could be green. The shroud lines of the main parachute!!! Mark approached and there it was. Pegasus-1 fully intact and only 800 feet from where we thought it to be. The Operational Technology, Piraeus, not only was critical to real-time flight operations and distributing to others to view, it also saved Pegasus-1’s dying breaths of GPS location.

We now have the telemetry and incredible video of the flight. We are compiling and condensing the video about this amazing story to release soon.

While Mark and I may have been the tip of the spear for the Pegasus Mission, nothing happens with the help and support of others. Our launch and chase team (Rohit Puri, and Gupreet Singh) and the unwavering help and support of Microsoft Research’s Orleans team that guided us for over a year in the construction of Piraeus, the Operational Technology that puts the real-time IOT into the Pegasus Mission. It takes a village, a village of dreamers and innovators.

Pegasus-1 at 85,000 feet, 2.2% atm, -60 degrees
Pegasus-1 at 85,000 feet, 2.2% atm, -60 degrees

-Matt Long

Matt.Long@microsoft.com

Photos and Video | Pegasus Prequel

My thoughts on innovation compiled > 1 year ago, what I believe … here