Add a new port number 75 for the AIRBORNE_APP

[pjalocha]

I ask again, after not very succesful yesterday, where I did it at a wrong place, for a new port number.

I propose a new port number for airborne applications like OGN-Tracer or FANET or ADS-L whch have well establilshed compact position packet formats. It is more efficient to put position in this format, which takes like 16 bytes for OGN than use the GPS generic format where many elements are missing like climb rate ro turn rate.

The new port number would allow efficient (low rate) position reports by objects like amateur balloons.

The formatting would be simple: I define ID's for particulat packet type and they would be embedded as a pack of bytes, the decoding of the pack would follow the particular system.

If this gets accepted, I will proceed to define those ID's

Thank you.

BTW. I am beta-receiving Meshtantic on ground receivers of the Open Glider Network (OGN) and I wonder if it would be worth to upload this traffic to a server of yours ?

[thebentern]

@pjalocha can you tell us a bit more about this data format? @geeksville actually started this project partially around the paragliding use case, so it presumably serves that already with the existing Position packets, minus the ones you mentioned like climb rate.

I have a hard time believing that this format will eclipse the uint32 packed lat / lon / alt fields in the native position packets in our existing protobufs in terms of efficiency over the wire. IMO the additional metrics you're interested in would make more sense as optional position flags to be unlocked for this use case. After those are added, you could translate the packets into your interop formats.

[pjalocha]

FANET protocol is here: https://github.com/3s1d/fanet-stm32/blob/master/Src/fanet/radio/protocol.txt
OGN-Tracker procotol is here: https://github.com/pjalocha/ogn-tracker/blob/main/src/ogn1.h
The laater one is 16 bytes for position including climb/sink, turn rate, both AMSL and pressure altitude, DOP, aircraft-type
The FANET is even shorter.
ADS-L position packet in 21 bytes including aircraft address and type.
UAT format could be used as well which is 20-30 bytes

For simple GPS position which I see on Meshtantic it is like 40 bytes long and it does not include many elements like climb/sink, turn rate, both geometric and pressure altitudes, thus I would see a gain of at least factor two if not three.

It could be organized otherwise, I agree, as other types of "position" or "GPS position", thus keep all under one category.

Actually, there could be one reason to do it as a separate application: there are not just position packets in the airborne application, but as well others like aircraft registration and other info, aircraft telemetry, and possibly others.

[geeksville]

@pjalocha oh yeah great you are working on this! Eventually meshtastic I think could be great for glider land for a few reasons:

• FLARMish anti-collision
• Outlanding messaging support (mostly useful for paraglider retrieves) - because as long as any pilot is still in the air their node would route for people on the ground making communication to retreive vehicles possible
• Last known location for emergency location purposes
• Automatic collaborative thermal lift maps based on position and vario data
• the hardware is cheap, so vario manufacturers might someday be willing to build it into the vario

Btw @thebentern sorry but my Chinese class is kicking my ass so I haven't been able to volunteer for meshtastic this month. I should hopefully have more time for hobbies by Jan? I hope you and everyone else is doing great!

[fifieldt]

@geeksville 加油！

[geeksville]

btw @pjalocha and @thebentern: For any airborne applications I think it might make sense for the 'application layer' (not the routing layer) of meshtastic to set max-hops for most messages sent by the airborne node to 1 or 0 (i.e. request minimal / no routing / suppress mesh forwarding). Because when airborne the odds are very high of GREAT line-of-site (so excellent for routing for ground based nodes, but no need to forward messages from other nodes in a gaggle).

This behavior would ideally be controlled automatically by the node detecting is flying vs !flying.

[pjalocha]

I agree, the airborne would not go for hopping, unless for emergency signalling purposes.

As well: airborne might use the faster rate like 250kHz SF7 for air-to-air (like FANET is doing) and slower for air-ground.

[caveman99]

as long as its only location formats, i think we can handle this within position packets. When it's encapsulating another protocol like ADS-* a new portnum would be in order. But as it is now this would only be a portnumber to replace the position_app (which can also be done in an oneof...)

[3s1d]

Hi there!
This was brought to my attention just recently. I must say that the airborne env is a highly dynamic one and it is for sure beneficial to reduce very thing as much as possible. Further reducing the max hops is unfortunately the next logical thing AFTER boiling everything down as good as possible. That is/was, considering my background, all real world stuff incl. real none-technical persons, and hardware variations, the only viable solution for me... FANET spans up a network across the alps using multiple thousand's of nodes (simultaneously). But in order to get it stable max-hop is set to 1 (and can automatically switched to 0 under certain circumstances). I dopped any complex multi-hop routing approach due to the challenging env (and we needed base stations to collect/distribute information relaiably).

TL;DR if you are interested in airborne stuff one should really consider having an extra app. It's way more complex as ground stuff. Just my 2 cents...
Juergen

[snip]

Airborne will be really useful with less impact on the frequency utilization.