New sources of data and new devices types

[acasadoalonso]

Folks,

With the advent of new devices pushing data to the OGN APRS like: SPOT, SPIDER, Capturs, LT24, Naviter/LX, Skylines (XCsoar), etc, ... it is needed to define the source of the data, so the different app parser can parser the new messages.
We started a new repo:

https://github.com/glidernet/ogn-aprs-protocol

with all the data and as forum to discuss the different issues that we can find in the way

However one area that we need to deal at registration time, it is how we are going to register all of those new devices and how we are going to be dealing with the fact that a glider, can have at the same time different devices, for example a Flarm, an OGN tracker, an SPOT and a LX9000 or Oudie all of them transmitting the position to the OGN APRS servers, we do not want to display in our web apps like http://live.glidernet.org 4 gliders on the same position with the same registration, etc, ...
We need to find a way to relate all of those devices to a single glider (when I say glider, may be a tow plane, a chopper, a paraglider, etc, ...) ...
Here some ideas of a new schema for the DDB, essentially consist to add a new table, lets call it PLANES table for the time being, that contains all the data about the plane like: registration, competition id, aircraft type, etc, and the DEVICE table contains only the ID, device type, link to PLANE table and device password as some device requires that.
The other tables AIRCRAFT type and USER will remain the same.
On the PLANES table will have a link to the primary device ID, that way we can maintain the compatibility with the previous design and the download format will be the same.
Of course, we need to develop a new download process.
Please find attached the initial design docs,
Your comments or suggestion will be deeply appreciated.

AC/.

ddb schema.pdf

OGNNEWDDB.TXT

[kerel-fs]

We shouldn't store the association of different devices belonging to the same plane in a central database, since it is rather not needed:
Instead the state should be stored inside the devices themself and send alongside the stream of fixes, rendering a central database unneeded.

[acasadoalonso]

Fabian, Your proposal will means to increase the size of the transmitted package with info that is always repetitive, adding no value, it will means to increase the size of the transmitted package beyond of the nRF905 compatibility format. The current schema of transmitting only the DEVICE_ID is very efficient. AC/.

…

On 16 Oct 2017, at 15:37, Fabian P. Schmidt ***@***.***> wrote: We shouldn't store the association of different devices belonging to the same plane in a central database, since it is rather not needed: Instead the state should be stored inside the devices themself and send alongside the stream of fixes, rendering a central database unneeded. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#36 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHw8Zxu5tsRuplWsktuBJKo6_jY4otbqks5ss1wpgaJpZM4PcSHk>.

[kerel-fs]

Afaik there are already multiple device_id's in each packet (e.g. aprs-address & real_address of the FLARM)? Maybe the protocols can be updated to define an unique identifier? Tbh this is just some random idea.

Edit: Here I'm only speaking about the packet format in the APRS-network itself (the OGN-"core").