Meshtastic

Paragliding / PPG specific requirements

#1

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?

1 Like
#2

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)

2 Likes
#3

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

1 Like
#4

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

1 Like