New Launch Window and Win10 App

We will know in the next 48 hours whether the Oct 5 – 6 launch date will hold good news for weather conditions.  We will advise of a go or no-go on Monday or Tuesday (Sept 28 or 29).

Our Win10 and windows phones are now searchable in the Windows app stores.  You can search for “Pegasus Mission” and install the free app to watch the flight of Pegasus II.  You can also send a message to the craft inflight and we will show you message on a tiny LCD display outside the craft and record it into the video record during flight.

We will advise shortly on the phone apps for Android and iOS, stay tuned.

Remember to go to the Web site and sign up for SMS flight notifications and the craft will text your phone when it launches so you will not miss the flight.

We hope the UAV gods can an excellent weather forecast for next week in the next 48 hours 😀

Best Wishes,


Testing and Photos of Pegasus II Internals

We are in the throws of end-2-end testing in preparation for flight.  Below are photos of Mark Nichols handwork for the craft and sensors, video, and radio.  Recovery system and housing not shown.  Pegasus II is a highly complex craft.  I find humor in that he brings it in an Atari box.

Lower deck internal craft sensor array, gps, and telemetry radio


Upper deck internal craft gyroscope and video radio


Outer top of craft disassembled


Out top of craft assembled


Mobile station radio, gps, and sensors


The carrying container


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

My thoughts on Innovation from nearly 2 year ago.

Pegasus II – Launch Window Sept 28, 2015

Pegasus II mission team is pushing out launch window to week of Sept. 28th, 2015 at our location in Cheyenne, WY.

Remember to go to and sign up for flight notifications.

I have shown, image below, the full expected flight profile from launch to touchdown as well as the critical communications that impact the flight.

The ascent phase will take about 95 minutes from our launch altitude climbing to 100,000 feet.  Once we get to the target altitude between we begin the Separation, Descent, and Landing sequence, or SDL.  SDL happens through communications from cloud intelligence running in a Microsoft Azure Data Center over a thousand miles away.  The entire SDL sequence depends of our ability have the cloud act as the “brain” for Pegasus II and communicate with extreme low latency to the remote craft in this hostile environment.  This intelligence determines when to separate the craft from the delivery system, or Delivery System Release (DSR) at the target altitude.  The next phase is the high speed descent (HSD) as the craft rapidly descends on its tiny drogue parachute.  The cloud intelligence will be computing the forward vertical position on the craft in time and issue a command for Main Parachute Deployment (MPD), when the craft is at an altitude of 12,000 feet.  This command will unfurl a 7 foot parachute and slow the craft down for a safe landing and touchdown. If everything doesn’t work just right…well, we will own some expense debris.

Dare Mighty Things 😀


Piraeus Overview for Pegasus II

Piraeus is our experimental and research IoT technology that we have used on the Pegasus Mission.  It is the critical communications technology that puts the real-time into the Pegasus experience and allows users to view telemetry and location as well as interact with Pegasus as it flies.  The following is simplified overview of the technology and its purpose.

Piraeus Overview

Experimental IoT Technology — Research

Piraeus was design by building on several well-known engineering and technical practices and theories used over the last 70 years, including systems engineering, systems theory, control theory, information theory, and open systems theory, to enable a distributed and flexible open systems to be created, managed, and leverage real-time communications. Effectively, Piraeus allows a proxy of a system graph to be represented and simplifies the communications needs of physical or digital actors within the system, while addressing security holistically.


Piraeus is a symmetrical architecture that enables a distributed event-based open system to be organically constructed and communicate with low latency, high throughput, and linear scale. A system graph is constructed within Piraeus, which represent a proxy of the physical and/or digital subsystems outside of Piraeus that constitute the open system. The system graph can be modified at any time to enable “edge actors” (EA), i.e., physical and/or digital subsystem components to communicate. These EAs can emerge and enter the system or remove themselves from the system at any time. This enables the system to organically change and supports graph management, occasionally connected clients, complex systems, and self-organizing systems.

Piraeus is a generalized architecture and creates no constraints and makes no distinction between EAs. These EAs can be devices, services, or processing units, which may be active or passive in nature. Active systems require a channel to be opened by the sender or receiver to Piraeus for communications, while passive systems require Piraeus to make an outbound connection.  These simplifications enable a system to be constructed however fluid to address the communication needs of information senders, actuators, intelligence processes, and analytics through same the symmetrical architecture.

Piraeus supports a range of channel and protocols, where EAs choose their respective channel and protocol to communicate. These is no coupling between the channel and protocol to enable communications between EAs. Piraeus makes these transitions between senders and receivers of information, which reduces the constraints for communications.   Piraeus supports HTTP, TCP, UDP, and Web Socket channels as well as HTTP-REST, CoAP, MQTT, and WS-N protocols.

No store and forward technology exists intrinsically within the architecture. Communications processing is perform in-memory and separates the nodes in the system graph into independent units of execution. If the need exists for persistent or cached storage of information, then this storage is considered an EA to the system, i.e., another node in the system graph. The elimination or store and forward technologies reduces latency, increases throughput, and enables linear scale to meet system demands.

Security is simplified by authenticating connections the system using a single security token. Piraeus intentionally separates the management and process of security token acquisition by the EAs. This keeps the security within the system simple, while enabling the management of EAs security to be completely outside of the system and/or customized to address specific scenarios. Access control to system resources is executed via distributed access control. Access control policies are constructed outside of Piraeus for system resources, where Piraeus can consume them at runtime. These access control policies are mutable and Piraeus can refresh them to enable external entities to manage access control to the system graphs without side-effect or redeployment.

The system graph is constructed by first assigning a node to the graph called a “Topic”. The Topic is an input into a system proxy within Piraeus. The outputs of the system proxy are called “Subscriptions” and can be either durable or ephemeral. Both Topics and durable Subscriptions are provisioning and manage with the Piraeus API. Ephemeral subscriptions are never provisioned and are self-managed by Piraeus.


A receiver of events, i.e., a subscriber, is associated with a resource in the system graph called a subscription. These subscriptions can be either durable or ephemeral. A durable subscription is a resource that persists itself in the system graph whether the EA is connected or not to the system. These durable subscription can be configured to store events to a specific duration while the EA is not connected, then spool them out once the EA reconnects. An ephemeral subscription does not exist in the system graph until the EA connects to the system. When the EA disconnects, the ephemeral subscription is removed from the system graph and its resources are disposed.

Piraeus enables several transparent benefits.

  • Low latency, high throughput, and linear scale.
  • Any open system can be constructed that leverage one of the channels and protocols supported by Piraeus.
  • System can be composed of any combination or organization of physical or digital edge actors.
  • Systems can be simple, complex, complex adaptive, complex adaptive with emergent intelligence, and self-organizing.
  • External subsystems can be created and added to the overall system graph.
  • Edge Actors are treated as first class citizens and homogenously.  There is no need to customized internal system components with address functional roles of Edge Actors.
  • No routing technology is required because the system graph defines the route and access control defines access to resources within the graph.
  • System resources are self-optimizing.
  • Security is simplified and management of edge actors is orthogonal and localized to a party that understand how to implement the scenario however customized.

Pegasus II at Microsoft OneWeek

The Pegasus Mission participated in Microsoft OneWeek 7/29-7/30, sponsored by MS Research with a showcase of flight equipment, devices, and software.

Below is our sign at the MS Research area, and Mark Nichols (co-founder) behind our 100 lbs of Pegasus II goodness.  The event went very well and we were invited and delivered a 20 min Shop Talk (TED Talk) of the mission.

Many thanks to our partners at MS Research for the opportunity.

WP_20150729_001 WP_20150729_002

Pegasus II Flight Profile

Pegasus II Flight Profile
The flight begins after we connect the craft with our 2000 gram meteorological balloon. The balloon needs to be filled with an exact amount of Helium to provide us with the lift we need to hit our vertical speed target and have enough margin of error to meet of 100,000 foot target altitude. The video and telemetry on the 100 minute trip to target altitude should be spectacular as the craft rises at 5 m/s, i.e., ~17 fps. Once we hit the apex, that’s when everything begins to happen very fast.

Delivery System Release (DSR)
We must separate the balloon from the craft to begin the descent stage. We only have about 6 minutes from the target altitude before the balloon with expand to its 34.5 foot maximum diameter and burst. We send the DSR command from a Web site run by our Mission Control that feeds into our field gateways and up to the craft. The craft releases the balloon and we begin the first phase of descent. The reason we need to separate the craft from the balloon is that the first part of the descent stage is incredibly violent and we don’t want the bridle that tethers the craft and balloon to interfere with the recovery systems.

Descent – Phase I
The first part of the descent occurs with the craft rapidly accelerating using only a 2 foot drogue parachute. The drogue as multiple purposes in the recovery system, but during the first phase of descent its main job is to keep the craft vertical, i.e., antennas point down. The drogue does not produce enough drag to keep the craft from reaching terminal velocity, which initially is about 305 mph in rarified air. Once the craft reaches 305 mph, it begins to decelerate as it encounters denser air during the descent. The craft will descend on the drogue alone for 88,000 feet, which will take only about 13 minutes.

Descent – Phase II
While the craft is descending it is transmitting telemetry that we use to determine when the main parachute deployment (MPD) will occur. We have 2 running and redundant processes running in Microsoft Azure that collect the last 30 points of time and air pressure during descent. The algorithm uses these points to plot a least squares line and project where the craft will be in 90 seconds. Once the algorithm projects that the craft will be below 12,000 feet in 90 seconds or less, it computes the time until the craft hits 12,000 feet from its current position and starts a timer. When the timer expires, the process in the cloud sends our field gateways the MPD command, which is sent to the craft. The speed at which this all must happen is extremely important, because at 12K feet, Pegasus II will crash in about 2 minutes unless the MPD occurs.

The MPD sequence starts with drogue’s bridle being released from the craft. When this occurs the drogue is putting tension directly on the deployment bag (D-Bag), which houses the main 7 foot parachute. The drogue pulls the D-Bag up, which is tethered to the main parachute. As the D-Bag is pulled up, it pulls the main parachute up and away from the craft and we should get a clean deployment. The main parachute should inflate and slow the craft from about 23 m/s to 5 m/s, i.e., safe enough to land. The craft should descend on the main parachute for about 6-7 minutes.

It’s 100 minutes up and 20 minutes down with a the nerve ratcheting deploy of the main parachute sent by the cloud to save the craft with only a few minutes (literally) to spare.

Descent Speed Chart

The Pegasus II descent phase is that point in the mission where you have to put your faith in your team’s work and just let it happen.  There is nothing you can do. Just watch and wait for the life saving Main Parachute Deployment (MPD).  It is hard to get a feel for this because it all happens in the remote and hostile environment of the upper atmosphere.  Below is the graph of the descent speed in fps and mph, which show you how fast the craft is falling on it 2 foot drogue parachute.  It takes about 11 minutes to get from 100,000 to 12,000 feet on the drogue.  Once MPD occurs at 12,000 feet,  it takes about 7 more minutes to land safely at our 5,000 foot surface level altitude in Cheyenne, WY.