Recovering Pegasus-I

Recovering Pegasus-I was an extremely interesting part of the mission. This article goes into how it is done, and the fully story is here.

During the flight we immediately lost the Ham Radio, which was our backup GPS, and we were flying only on the onboard primary GPS. The craft had turned NE from East as expected, but with the mission altitude objective reached and difficultly of the terrain 17 miles East of Othello, WA, we decided to begin the descent stage.

Figure 1 is a map of 5 minute intervals of the flight path.


The winds gods were kind to us that day and you can see in Figure 2 that the radial distance of the flight was not very far.

Figure 2

The maximum altitude achieved by Pegasus-I was 84,899 feet, which gave us about 13 minutes during the descent stage before the craft lands. Once we cut down the craft, we begin a rapid descent in rarified air (not much friction) and rate of descent progressively slows as the air becomes denser at lower altitudes. The initial descent rate was over 200 mph and telemetry tells us the yaw, i.e., the rotation parallel to the ground was spinning wildly, while the roll and pitch were bumpy, but relatively stable.

During the descent the latitude and longitude from the primary GPS cut out at an air pressure of 38.8 millibars, due to an antenna becoming loosened. The rapidly spinning yaw likely put significant horizontal force on the antenna. The last recorded air pressure was 37.2 millibars at an altitude of 75,555 feet. Pegasus had dropped 9,344 feet in just 36 seconds at average of 256 ft/sec or 180 mph.

When GPS cut out, we were in dismay. Regardless of the other telemetry still pouring in, we did not have the location of the craft. The chase team exited the vehicle and began scanning the sky by sweeping from West to North, the expected landing zone. While this was actually the correct place to look, the cloud ceiling was only about 1,000 feet, which meant we had less than a minute to visually identify the craft. Figure 3 shows the position of the craft when we lost GPS, the position of the chase team and the last recorded position of the craft, which the chase team was not aware at the time.

Figure 3

After arriving home 3 days later, I was checking the telemetry we captured from Pegasus-I. First, I looked at the moment the GPS cut out, Figure 4.

Figure 4

I scanned further down and noticed this with only 26 seconds left in the flight, Figure 5.

Figure 5

Cross checking the air pressure with the location and topo map, it was apparent that landing point was consistent with the air pressure. Further analysis showed that the points between where the GPS cut out and came back online where in the expected location due to wind velocities and descent rate. The expected location was mapped in Figure 6 and sent to Mark to attempt recovery 7 days after the flight.

Figure 6

Figure 7 shows the last GPS coordinates and where Mark actually found the craft undamaged. The fact that we were streaming and capturing the telemetry enabled us to locate the craft and oddly enough provided and interesting story about the role our real-time IOT technology played in recovery.

Figure 7


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.

Security in Piraeus

Piraeus’s architecture is very intentional to reduce the amount of effort needed to leverage the system. The security of the system is built on a concept that an “authority” that can manage resources within the system, e.g., create topics or subscription grains within Orleans. Those grains are ACL’d by access control policies such that only authorized callers can access to those grains. The callers can be anything that can present an authenticated security token where the attributes of the security token comply with the access control policy of the resource being accessed.

The architecture greatly simplifies how Piraeus functions and also reduces latency within the system. The key is access control and how Piraeus manages this. Piraeus puts the user in control of what resources can be access by what callers. It does this through distributed access control policies. These polices can be cached, expired, and renewed by such that they can change within Piraeus without every stopping or redeploying the system. This clean separation of access control management from Piraeus enables to it be both fast and flexible.


One of the new technologies, other than Orleans, introduced in Piraeus is Claims Authorization Policy Language (CAPL). CAPL is a powerful, but simple logic-based and security token agnostic language for access control that enables rapid authorization decisions. CAPL policies can be created externally to Piraeus and then consumed to provide control over resource access, which reduces the complexity and increases the flexibility within Piraeus.

Topic grains within Piraeus include metadata when they are provisioned. Two important pieces of metadata are URIs that reference access control policies for the topic and subscription grains. Piraeus uses these references to return CAPL access control policies to ACL the resources from a service. We call this authorization service, Authorization as a Service, or ZaaS. ZaaS is where the access control policies are managed and Piraeus simply uses the ZaaS policy store to get and update the access control policies for the resources.

We want the access control system to be low latency and as such Piraeus will retrieve the policies when the Topic is provisioned. The policies will be cached locally as well as in Redis. When the policies expire from cache, they will be retrieved again and updated in the local and Redis cache. The Redis cache allows Piraeus to scale its gateways and make the access control polices available to the entire system. Once the policy is retrieved from Redis, it is cached locally to further speed up the process. When the policies expire locally, they are immediately refreshed to the local and Redis cache from the ZaaS service.

The security architecture greatly increases Piraeus’s flexibility because identity and attribute stores are completed separated from the system. Piraeus can scale and be leveraged in multiple data centers without the burden of porting these stores and/or synchronization because of this segregation, something that would be not possible with CAPL.

The benefits of the security architecture actually increase when you consider this clean separation.  Because we are using security tokens with attributes (not connection strings), this means that no caller is trusted, e.g., device, user, etc.  This is more in line with the scale provided by federated identity that is commonly used in Web sites.  Like I say, “If you don’t trust billions of people, then why would you trust devices when they will exceed the number of people on the Internet in the near future.”  The Piraeus architecture builds on this and opens the flexibility on how devices acquire and manage security tokens.  Piraeus does NOT manage devices and provide tightly coupled mechanisms for security token acquisition…by design.  The reason is that scenarios are so diverse for device registration and management that it needs to be either customized or leverage any existing product.  Since Piraeus is not a principal in the identity transaction, it simple requires that security token presented be by a trusted issuer.  Access to resources by the caller are based on the attributes of the security token as executed by a CAPL access control policy.  Again, cleanly separating the issue of token acquisition and management from the Piraeus Architecture.  Roll your own, use an existing product, just present a security token signed by a trusted issuer to Piraeus and it functions securely using CAPL to maintain access control to resources.