It's all in the application: Recon Instruments Snow 2 vs Paragliding (Part 5)

With the Christmas break spent optimizing my BLE implementation (to get some degree of reliability in messaging from the Bluetooth enabled vario), I figured I was set to begin field testing with my upcoming trip to Brazil.

Then an email from the trip organizer -> we will be using turn points to keep everyone close to roads, making for easy retrieve. 

Looks like navigation support just got bumped in priority.

The turn points were distributed via the standard .wpt file format. I just needed a way for one to select the points, assign radii, display bearing and distance to the next point, and pop them from the queue as they are reached.

A split implementation seems best -> build the list on the phone and push to the HUD.

The HUD side: 

The red inverted triangle shows the bearing to waypoint that is 4.4 km away. 

The MFD has been updated to include the height above launch to its cycle of information when within 5 km of launch.

A short while later while on bar and gliding away from the turn point (looking back at it), a wind guesstimate shows up. Heuristics need tuning.

Flight time is in the lower left corner.

The phone side:

Turn points from .wpt loaded and parsed.

Launch point selected, now able to add to waypoint list at bottom

'Add' selected, enter the radius in meters.

Launch and landing added - aggregate non-optimized distance displayed. 'Save' is now available. Selecting a waypoint in the bottom list will replace the 'Add' button with a 'Remove'.

The Save has been re-purposed to 'View' for now. Launch visible with the turn point radius in green.

...and the LZ. The black line is the path to be taken. Again non optimized.

Once saved, the waypoints (along with associated turn points and radii) are pushed to the HUD via Wifi P2P. The HUD has a thread watching for the turn point file to be updated and will pick it up when the upload is complete. The HUD will then populate the navigation queue and display the next waypoint on the compass (as above).

Next steps include the ability to slide the vertices of the flight path around within the turn point cylinder radii (hand optimization). Following that would be automated optimization using some form of the Travelling Salesman genetic algorithm.

Continued in Part 6

It's all in the application: Recon Instruments Snow 2 vs Paragliding (Part 4)

BLE - Bluetooth Low Energy.

Its all the rage in 'wiring' up sensors to a flight data aggregator (such as the GliderHUD on the Recon Instruments Snow2).

Now that the GliderHUD app can display flight data generated by the internal GPS, its time to look at external data sources like the XCTracer vario/GPS.

Using the sample application provided by Recon (which is based on the Android BLE tutorial published by Google) - I was able to get the Snow2 and XCTracer chatting with one oddity. It appears that the BLE stack on the Snow2 struggles with multipart messages. This is not particularly surprising as the only BLE device the Snow2 could talk to originally was the remote. I imagine that the up/down state of 6 buttons could easily be packed in the 20 byte limit of a BLE message - precluding the need to address a rapid chain of messages hitting the onboard transceiver and protocol stack. Just a hunch though. It could also be the quality of the Bluetooth chip itself. Who knows.

Well, the message format I wanted to support out of the box was the native XCTracer frame with a plethora of data.

But it is not to be.

After the third (sometimes fourth) XCTracer subpart, a new message begins - meaning the remainder of the original is dropped. Trying to accommodate a rapid turn around within the characteristic notification callback, I tried posting the byte data to a Handler immediately. Still no dice. Maybe a bug on my part.

What I do know works (mostly...mostly) is the LXWP0 format - it comes across in two parts as opposed to the five or six portions with the XCTracer sentence.

So LXWP0 it is.

Sadly this costs me the groundspeed - it would be nice to be able to skip using the onboard GPS on the Snow2 altogether except as a backup.

The changes are up on GitHub - https://github.com/Levemus/GliderHUD

The vario data coming from the XCTracer via BLE (the XCTracer is reporting the altitude as a negative, which the altitude display floors at 0 m):

Continued in Part 5

It's all in the application: Recon Instruments Snow 2 vs Paragliding (Part 3)

A quick recap from Part 1 and Part 2:

A killer deal on a Recon Instruments Snow2 +
A device that runs on the Android OS +
A paragliding dev with a modest amount of experience in game engine implementation on Android.
=
A Paragliding HUD work in progress.

Using the sample Compass app from Recon and some ideas on wind drift approximation from Alistair Dickie (along with a circular regression implementation from Dr. Micheal Doube) - I managed in the last pair of posts to put together a simple PG HUD that showed heading, bearing, altitude, groundspeed, and wind drift direction (along with a poor mans climb rate/vario and glide ratio).

In the 'rush' to slam together this prototype implementation, things became a bit of a hot mess (as they always do) - with the inevitable intermixing of UI and data provision (emmveecee rather than MVC, as it were).

Reorganizing

So a refactoring we will go (caveat: it is a work in progress, this is simply a snap shot at the current moment).

The result: The display elements are listeners that subscribe to broadcasters.

Broadcasters and Listeners

When the app is started, broadcasters and display elements are instantiated. The broadcasters are passed to each display (listener).

The listener attempts to register itself with the broadcaster, specifying which Flight Data elements it cares about and the minimum interval between notifications.

The broadcaster looks at the requested elements, compares them against what it can provide and replies with those it can service.

The listener stores the outstanding services it still needs until the next broadcaster is sent its way to register with.

Flight Data

Once registration is complete, the listeners wait for invocation of their onData callback. The passed param is a Flight Data object. The listener can query the Flight Data object for values it needs to update itself with. If the Flight Data object cannot provide the value (as could be the case when subscribing to multiple broadcasters providing different data) - an exception is tossed (the alternative could a TryGet like function seen in C# dictionaries, perhaps).

With data in hand, the listener (display) can update and refresh itself.

ListenerBroadcasters

Some broadcasters are aggregators of data - subscribing to get information, processing it, then providing a result to a downstream listener. The WindDrift is one such case - it subscribes to the GPS for bearing and ground speed information, processes it, and provides wind speed and direction.

Moving forward

Right now the implementation does not handle competing data broadcasters - we could get altitude information from the onboard Android GPS and we could (once implemented) get that same altitude from a BLE device such as the XCTracer. Experimentation leads me to believe that the XCTracer will provide better altitude data, but being a BLE device - it is not as reliable a source as the onboard GPS. This needs to be accounted for - some form of override and failsoft -> use the Android GPS for altitude until a better source appears, use that source until it drops off, then back to the Android GPS. Maybe an intermediary manager.

Source

Disclaimer:
Source is up on github, purely for educational purposes. Paragliding is a dangerous activity and use of this software in any way, shape, or form, can result in serious injury or death. Levemus Software Inc. assumes no responsbility and provides no guarentee related its use. Any use of the source must include the below github url from which the source originated. Any commercial use must have prior written permission from Levemus Software Inc.

https://github.com/Levemus/GliderHUD

Continued in Part 4

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

Over the summer an online dealer in Utah for the Recon Instruments family of devices had the Snow2 + Scott googles on sale for over 50% off. Even with the exchange rate, it was a phenomenal deal compared to the price local dealers were charging. The Snow2 is a pseudo HUD in that it does not directly overlay ones view, but instead sits on a small display in the lower right field of view.

An image of what the HUD looks like within the goggles, from Necessary Coolness.

Here is a link to Recons info page.

The HUD software is geared almost exclusively towards snow sports (thus the name Snow2 and likely why I got it so cheap mid summer). But it runs on Android, and strangely enough yours truly has a decent amount of experience with Android fairly close to the metal.

Trivial to repurpose this device towards a more paragliding centric application. Grab the Recon SDK, the sample app, and a hacking we will go.

The result:

Fairly simplistic. It autostarts on boot, precluding the need for the all-too-easy-to-lose remote. The compass rotates in line with heading, the green arrow indicates bearing. If the user has a sufficient change in bearing or a climb rate above 0 m/s, the centre display will show climb rate, otherwise it shows glide ratio. Climb and glide are averaged.

Next up will be determination of wind direction and speed (a blue arrow on the compass?). After that, maybe speed to fly, maybe BLE connectivity (if Recon has finally updated the OS for the device with proper SDK support) to a PGing GPS such as the XC Tracer.

In any case, it and the laptop will follow me to Brazil for further testing/dev.

Continued in Part 2.

...Or skip ahead to the current refactor.