The brain bucket

Finally it has come together, a work in progress for the last year:

Helmet, Camera, Goggles, + Headset.

1. OCF Shell (Plasti-Dip Blaze Orange) + TW REVOLVE impact liner.
2. MOHOC Video Camera.
3. Recon Instruments Snow 2 Heads Up Display (HUD) with custom Paragliding Application.
4. Code Red Bone Conduction Headset/Mic.

Multi-strike blunt impact mitigation liner.

ARC rail goggle attachment.

MOHOC Video Demo: Paragliding Woodside with the Gin Carrera Plus

Paragliding Waivers: No minors permitted beyond this point.

Waivers.

Where would extreme sports (and adventure tourism for that matter) in North America be without them?

Odds are, non-existant.

If there is one thing that stands out in differentiating us in North America from our European cousins it is the degree with which we employ litigation to seek damages (coupled with an implicit assignment of blame) from another party.

For better or worse, it is the reality in which we live.

In addressing this reality, we have devised the waiver - an agreement to hold harmless another party during a given activity. Without this waiver, any activity that holds a chance of injury or death above a statistical zero will likely find itself litigated into non-existence in aftermath of a single incident.

Again, the reality in which we live.

The validity and extent of protection provided by one of these agreements will vary from jurisdiction to jurisdiction. In British Columba, with a thriving adventure tourism sector, a waiver can carry quite a bit of weight. A participant signs one with the understanding stuff happens (potentially from simple negligence) and they accept responsibility for the risks involved. In fact the risks are often part of the draw, causing the activity to be added to ones 'bucket list' as it were.

In the case of paragliding, expect to sign multiple waivers - holding harmless the:

1. National Association (including the instructor, all members, and landowners).
2. Local Club (including all members and, again, land owners).
3. School (including its instructional staff).

Now here in BC there is one catch - the Infant Act.

The Infant Act in its current form states a minor cannot enter into a contract of non necessity. Huh? Basically if the contract doesn't involve putting food on the table or a roof over their head, anyone in BC under the age of majority (19 years of age) cannot be held to the contract terms. 

This includes waivers.

Hold on, can't parents sign a waiver on behalf of the minor - we see them doing it all the time at the go-kart track and paintball field.

Enter 2009 BC Supreme Court Case 1385.

It is a fascinating read, but I will cut to the chase - the last line:

"The Act does not permit a parent or guardian to bind an infant to an agreement waiving the infant's right to bring an action in damages or tort"

Yep. You read it correctly. That waiver mommy or daddy signed is not worth the paper it is printed on. This includes the go-kart track, the paintball field, and ... paragliding.

Litigation lawyer is probably loading up the proverbial 'notice' shotgun with size 7 at this point.

'But' you say...
The parents are friends and they won't sue. Maybe the participant is your own child?
Say hello to the Public Guardian and Trustee of British Columbia, the mission statement of which includes:

Interested in going toe to toe with a Crown Corp?

Minor seriously injured as a result of flying - what are the odds of these folk getting involved?

Now add to the mix a notice from our National Association stating early last year that our insurance provider will not offer coverage where a waiver is invalid.

Mark K. is the NACs legal counsel.

The landowners require that we have coverage to protect their significant assets that we use as launches and LZs. This includes the Crown. Our land tenure agreements include language such as:

"You must:
(a) without limiting your obligations or liabilities under this Agreement, at your expense, purchase and maintain during the Term the following insurance with insurers licensed to do business in Canada:
(i) Commercial General Liability insurance [...] "

(it goes on to specify amounts and rules about presenting to the Crown upon demand proof of possession).

Comments in the quarterly newsletter from the NAC relay a similar concern regarding minors and landowner liability:

Minor in the air -> no valid waiver -> no valid insurance -> violated tenure -> lose site.

Under 19? They can wait until the law judges them mature enough to appreciate the contract/waiver which we (and our insurers, and thus the landowners/Crown) require them to sign. To do otherwise is jeopardizing the very existence of our sport.

For better or worse, it is the reality in which we live.

Now the global caveat: don't take any of this as gospel, consult a lawyer for I am not one. I simply want to make you think about the potential ramifications of having a minor participate in the sport in our current legal environment.

It's all in the application: Recon Instruments Snow 2 vs Paragliding: Part 9

Continued from Part 8

Now that we have a result, it is time to display it to the user.

The Displays are implemented as disjoint Fragments. Each Fragment has no knowledge of any other - nor does the 'master' Activity have any knowledge (at a code level) of the Display Fragments it contains.

Each display has a Broadcast Receiver that listens for Flight Data messages from the Flight Data Service. When a message arrives, an AsyncTask is created to invoke each of the Displays Processors. The result of each Processor is cached and ultimately the Display is updated.

The single deviation from this system involves the Compass. The Compass updates in real time as the user turns their head. Moving the Heading position by way of a Flight Data Message via the Flight Data Service would involve too great a latency at this point (this could be over come with predictive interpolation - but would add complexity with little benefit*). So, the Heading data used by the Compass is fed directly into the Compass Display by way of callback. Processing in the callback is throttled to a period no faster than 30 ms. When an update occurs, each of the children of the Compass (CompassSubDisplays) are walked, their Processors invoked, and the results displayed.

* that said, thought has been given to implementing a complete Flight Data Recorder that would include Head Orientation. The would allow for future playback and enable the creation of PiP video with an overlay of what the pilot would have seen on the HUD.

It's all in the application: Recon Instruments Snow 2 vs Paragliding: Part 8

Continued from Part 7

The refactor continues.

With raw Channel* data being broadcast by the Flight Data Service, we still need to process it before it can be displayed to the user -> either due to the 'noisy' nature of the data (such as a fluctuations in instantaneous vario readings) or the need to aggregate multiple Channels (such as determining Wind Drift or Thermal Location).

The Processors exist to do these tasks of aggregation and low pass filtering. As Channel data arrives at the Display, that data is fed to each of the Processors that the Display has instantiated. If the Processor has all of the data it needs, a result will be returned. If insufficient time has passed since the last invocation of the Processor, the Processor will simply return the cached last result.

Processor

Processors come in two forms:

1. Framed.
2. Custom. 

Framed Processors are built from an aggregate of operations:

1. Converters.
2. Adjusters.

A Converter takes two or more raw Channels and performs an action upon them - such as subtraction or division - to then return a single result.

Adjusters, on the other hand, take a single raw Channel and perform an action upon it. Think low pass filtering as one example.

Converters and Adjusters

Framed Processors typically involve simple operations that do not involve complex computation or access to external data sources beyond the raw Channels.

For more complex computation, one would implement a Custom Processor. Examples would include Wind Drift and Waypoint Navigation.

Custom Processors

All of the Processors are obtained via the Processor Factory. This factory abstracts the need to differentiate between the Framed and Custom implementations. Requesting a Processor from the Factory is done via the Processor ID.

Processor IDs

With the Processors up and running, we can now Display the results.

* A Channel is a single raw stream of data coming directly from the device - such as vario, pressure or gps altitude, latitude, longitude, ground speed.

Onto Part 9: Displays.

It's all in the application: Recon Instruments Snow 2 vs Paragliding: Part 7

Continued from Part 6

A refactoring we will go.

In an attempt to better segregate the data provision from the data consumption, I've moved the process of flight data collection and broadcast into a service running under its own thread.

Providers

The initial source for the raw flight data (referred to as Channels) are the Providers which are invoked by way of either system callback or periodic runnable.

There are three groups of providers:

1. Android Generic - Internal GPS and Battery.
2. Recon Specific - Sensors and Head Orientation.
3. Test.

The Providers all derive from the abstract Provider class and are expected to implement start/stop, the (de)registration of client, and configuration information (identification and channels supported).

Providers

*Note: At the time of this writing, the Head Orientation Listener does not go through the following flow - it is instead part of the composition of the Compass Display (due to the need for minimal latency).

Multiplexer

As Channel data is received by each provider, it is fed to the registered client of the provider. In this case, each Provider shares the same client - the Message Multiplexer. When more than one Provider is a source for a single Channel, the Multiplexer determines from which Provider the Channel will be ultimately sourced.

Providers are ranked based on registration order - earlier Providers getting priority over later registrants.

When a Channel arrives at the Multiplexer, we first check to see if the Channel has already been reserved by a Provider. If so, is the current Channel Provider of higher priority? If yes, now adopt this Provider of the Source and pass on the Chanel Data. If no, do nothing. If the Channel is not reserved, then adopt and pass on the Channel to the Client.

Providers also have the ability to deregister their reservation of a Channel in the event they go offline.  If the Provider has a Channel reserved in the Multiplexer and sends a channel failed message, the reservation is cleared and we treat the channel as unreserved.

Cache

As Channels pass through the Multiplexer, they are stored in the cache until such time as the Flight Data Service can bundle and broadcast them.

Multiplexer and Message Cache

Flight Data Service

Containing this whole system is the Flight Data Service. It is a simple extension of the standard Android Service with the addition of its own thread of execution. The Service periodically (every 0.5 seconds) bundles Channel data stored in the Message Cache into an intent and broadcasts it.

Flight Data Service

The Data Service contains the Providers, which the Service registers with the Multiplexer. The Multiplexer is then in turn registered with the Message Cache. The Providers are then started and Channel data is bundled and broadcast for the Displays to consume.

Refactor Continued ...