Paragliding / PPG specific requirements

Maybe we can talk here about what we want to see in a paragliding/ PPG specific device?
I have an idea of a small and simple device, (inspired by XCTracer II, I love the elegant simplicity of it) that I think can work well for the paragliding use cases and maybe also PPG?

  • Small size (~ 40mm x 40mm x 10 mm), flat solar panel glued on top of the device.
  • Small current consumption such that in typical flying conditions the solar charging will provide for an indefinite battery life. Then the device can stay attached on my harness between flights - one thing less to worry about.
  • On-device UI is limited to a single button (and maybe some covered SOS button?) and a couple of LEDs. No screen - screens tend to have poor visibility in sun light (maybe e-ink changes that drastically?) and they also take the space where we can put solar panel. Maybe also a buzzer for On/off/BT connected/Lora connected notificatons - LEDs are not very useful in bright light during pre-flight.
  • USB port for charging. Optionally maybe also implement USB drive interface - users can then simply drop the files on the drive for firmware update (In my experience OTA DFU is flaky… But maybe this is just a poor implementation). Also I love the simplicity of a text config file that can be dropped into the device USB storage to configure it.
  • The Phone App provides messaging capabilities and will also push other pilot location into a Flight Computer app running on the same phone. There is a whole zoo of such apps, but many of them (XCTracker, XCSoar) support incoming FLARM data as NMEA stream, so we can use that. The app will also push GPS location and vertical speed back into the device, so no on device GPS/vario is needed.
  • Ideally the device can interoperate with other radio protocols for flying: FANET, FLARM, etc. This is less relevant in US, but maybe different elsewhere.

Anyway, enough for me rumbling, maybe somebody wants to pitch in?

2 Likes

Misc comments:

  • Since each device sends positions to the other devices (and since any node in the air will have amazing line-of-sight), most messages will be delivered in one hop. But if someone lands out or needs retrieve, their messages will be getting routed by nodes in the air. This nicely lets the map view in the app help with the all to common problem of someone landing out and then no one knowing exactly where they are.

I also think: some slight refactoring of the existing mesh position info would be useful: Currently we send position and battery level. Really, that data should be structured better in the device code. We should instead allow a list of tiny protobufs in the “node ping”. The these different types of data could be sent on different intervals:

  • Position (already sent at the user selected position interval)
  • Battery level (only send every 15 minutes)
  • NodeInfo (user/nodename) (only send once an hour - or when changed)
  • Vario data (if the paragliding Plugin is installed and a BMP280 or similar is found)

When a new node signs on to the mesh, it requests the current info from all other nodes (this is a rare/expensive event - needed to build the initial/current node-db)

5 Likes

+1 for this idea. Would completely satisfy Organize and supplement power details in protobuf · Issue #636 · meshtastic/Meshtastic-device · GitHub

1 Like

+1 for the odd Open Glider Network message out every once in a while.

2 Likes

Hiya,

First off, I’m new to the platform so I may have missed something, so sorry if I ask some questions that have been answered elsewhere. I’m definitely interested in this from a flying point of view. It’s a pain landing out in a valley with no cell coverage and having to use someone in the air with a radio to figure out where people ended up.

Looking at the suggestions we have a couple different use cases

  • Glider location, synchronised up, potentially with OGN or another network/tool
  • Using the device as a vario

The first one seems pretty straight forward and an easy use of meshtastic. The second case is a little more complex. When using the device as a vario are you getting visible/audible alerts from it to identify changes in altitude? Is this being relayed to another device via bluetooth aka xcsoar, or is it just being used as additional information for something like the open glider network or a team based tracking?

I’m personally thinking of adding track logging, barometer an a buzzer to use it as a dedicated vario device.

Welcome, Dave!
I’m personally less interested in meshtastic-as-a-vario use case: there are already so many varios available (commercial and otherwise), adding yet another one doesn’t seem to add much value. But this is my opinion only.
I think for paragliding most interesting use cases are:

  1. Retrieve coordination: exchange pilots and drivers locations and exchange text messages. In the US, cellular coverage is very poor in the places we fly and satellite comms have a very high latency.
  2. Team flying: location, altitude and vertical velocity of other pilots in the team.
2 Likes

I am building a weather station that is connected to a tbeam that would automatically send messages with wind data every x minutes. My hope is I could place it at the LZ and have it send wind data to my tbeam while on launch and flying! Or you could put it on a launch and be able to easily monitor conditions.

2 Likes

Hi, see the nodered flow to live track and forward messages to telegram I posted in development. Let me know if anyone would like to see it in action.