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.


Main Parachute Deployment (MPD)


The Pegasus II descent phase begins at 100,000 feet with the Delivery System Release (DSR). This is the point where Mission Control remotely separates the balloon from the craft. The craft will begin its descent phase using only a 2 foot drogue parachute to keep the craft vertical to help maintain communications. The speeds will reach over 300 mph in rarified air, and begin slowing as the craft plummets to lower altitude where the air is becomes denser. Pegasus II will be traveling far too fast to land safely on this 2 foot drogue and requires its main 7 foot parachute to be deployed to slow the craft. Main Parachute Deployment (MPD) is the highest stress moment for the flight, where only 67 seconds remain before the onboard fail safes kick in (hopefully) and try to force an MPD event 54 seconds prior to landing.

Distributed Intelligence

The Pegasus Mission is all about experimentation and we have to put our craft, thousands of man hours, and our money at great risk to run some of these experiments. MPD is the single most nerve wracking, nail biting event on the entire mission. MPD is controlled by a processor running in the cloud that continuously estimates where the craft will be vertically 90 seconds into the future based on the current telemetry from the craft. A form of distributed intelligence. Once the processor determines that 5 consecutive forecasted values are at or below the MPD altitude (which is actually air pressure), then the processor calculates the time in seconds to when the craft hits the MPD altitude. A timer is started and the processor sends the MPD command when the timer elapses. The field gateways should receive the signal from the cloud-based processor and send the MPD command to the craft. MPD should occur at 12,000 – 11,800 feet.


The Big Bet

The big bet is low latency. If the processor does not receive the telemetry at a fast enough rate, then the calculations will be off, i.e., the craft will not be where the processor thinks it is…too low. If the MPD command is not quickly sent and received the craft will be at a lower altitude than targeted, which reduces or eliminates the safety margin. We not just testing a special system for MPD, rather we are testing the entire system. MPD uses exactly the same infrastructure and software that sends the telemetry to thousands of users that view the flight. So, we are experimenting with a huge number of messages flying around in both directions (from and to) at the same time and at scale. Risky? If it wasn’t, then we would not learn anything.