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
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
No comments:
Post a Comment