Featurrequest: Connectability to flightgear

merspieler commented 6 years ago

It would be great if it would work with flightgear as well. If you intend to do not so, feel free to close the issue.

albar965 commented 6 years ago

That was my plan on the beginning (open source program for an open source flight simulator), to support FlightGear. I have to see when I can find time to add this. The issue will definitely stay open.

merspieler commented 6 years ago

I'll collect here some information that might be useful Flightgear uses the Same Navdatabase as X-Plane About internals of the Routmanager Explanation of the property tree (here in is everything you'll need) Data can be accessed via http. To work, this needs fg to start with --httpd=<PORT> (usually port 8080) telnet is possible as well via --telnet=<PORT>. Useage of Routemanager

merspieler commented 6 years ago

Any update on this?

albar965 commented 6 years ago

No. Otherwise the issue would be assigned to a milestone. I'm already too busy supporting the current simulators. Alex

slawekmikula commented 5 years ago

@albar965 Hi alexander. I've created something similar for VfrFlight planner (in java). Basically getting information from flightgear is done (mostly and most simple) by using generic protocol and UDP communication. Steps to get information about plane:

define protocol file (examplary for vfrflight (rename to xml): vfrflight.txt
start flightgear with option e.g. --generic=socket,out,1,localhost,3333,udp,vfrflight
it means, start flightgear and start sending UDP packets, 1 per second, to port 3333, UDP, according to protocol file (vfrflight)
on the other side there should be UDP listener on defined port and parse the data. In this protocol new data is separated by newline and parameters are separated by comma.

I can work on this issue in my free time. I've got successfully compiled lnm source code on linux and can do some work with this, but I would like to get some guidance how this should be done with lnm the best way. If you can take a look at the above process and plan, where to put some code/ui to be best use. Another question is what kind of data should/can be used by LNM. I could prepare protocol file for flightgear as well.

albar965 commented 5 years ago

Hi Sławek, thank you for the information. I'll have a look at it.

All the data transferred across the network between LNM, LNC and LXPC is here in the classes: https://github.com/albar965/atools/tree/master/src/fs/sc The root of all data packets is here: https://github.com/albar965/atools/blob/master/src/fs/sc/simconnectdata.h

All is transferred as binary data but the protocol can be used by other languages as well since there is no Qt specific in there.

Connection is only one part of the FG work. I also have to read the scenery library which is also a lot of effort to implement. Will get back to you. Alex

albar965 commented 5 years ago

Sławek, also have a look at https://github.com/albar965/littlexpconnect . This X-Plane plugin could be used as a template for a FG connector. LNM and LNC connect to this plugin using shared memory. Data is serialized using above mentioned classes. The whole transfer across the SM is very simple. Alex

slawekmikula commented 5 years ago

Thanks, I'll take a look at it. Do not expect quick results as RL is quite busy, but when I have some time i'll try to implement aircraft position data transfer. Importing scenery library as working in LNM is impressive but not in this issue :)

merspieler commented 5 years ago

@slawekmikula have you had a look at it?

slawekmikula commented 5 years ago

@merspieler Sorry RL. Only preliminary check and start cleaning littlexpconnect code to make room for FG code. Unfortunately i haven't code in c/c++/qt for a long time and don't feel comfortably with it. No ETA for my work (whole on my own).

merspieler commented 5 years ago

ok

slawekmikula commented 4 years ago

@slawekmikula have you had a look at it?

@albar965 Alexander, sorry for this late reply but right now i've finished some of my biggest projects and have some time to dig into it. May I ask how do you find this kind of approach before implementing it. Please bear in mind that my C++/Qt skills are very rusty and the best thing right now is to look at similar implementation in Your code and stitch it together to do something usable.

So i've looked at the source code and this is something that comes from my understanding how it works:

On the littlenavconnect side:

current simconnect implementation is using *.dll from the SimConnect API and use it to get the simulator data. It is using direct connection.
current xpconnect is using shared memory to access data that is fed from the xp plugin
worker thread (DataReaderThread) is using above code to iteratively get the data from simulators

On the littlexpconnect side:

it is a XPlane compatible plugin and it is loaded directly into the simulator, it fetches the data and write it to the shared memory, which littlenavconnect read

This is how (I suppose) the work flows in order to feed the data to the LNM.

Flightgear on the other side works as follows:

there is no such thing as DLL (simconnect) or official plugin API to implement C++ code. There is something as "nasal" - internal scripting language but without good http sending capability.
mostly the communication with the external sources or receivers are made with the "Protocol" data. There are some specific implementation but most used (and which I know of) is generic protocol which can export data from property tree (everything in FG is modelled as properties in the tree form) in csv,xml,binary format with definable output.
It can then send it to external received through tcp/udp connection

SO my take is to modify littlenavconnect (lnc) and atools (at) to implement communication with flightgear with this steps:

implement in (at)/fs/sc/ new classes to communicate with flightgear: fgconnecthandler.h, fgconnecthandler.cpp which implements ConnectHandler. I'll use code from NavServer to implement TCP server to wait and parse connection from Flightgear.
modify UI at (lnc) to use additional connector as above. Modify Windows version to add buttons to choose XP/FG and add in NON-Windows code the same code as in windows (with buttons to select source)

Please take a look at it and take your opinion. Is it OK to do this way ?

Additionally - can you point me to your source code for any proper XML parser (sorry as I said C++/Qt is not my strong side) to take a code ? I'll have to parse incoming xml data from FG.

albar965 commented 4 years ago

Yes, basically you have to specialize and implement a ConnectHandler which reads the data from FG and fills a SimConnectData object. XpConnectHandler is a good and simple example for this. It reads SimConnectData objects from the shared memory segment provided by the Xpconnect plugin. This is all completely independent of Navconnect or Navmap so far.

Don't look too close at the Navserver. This is a bit messy and I plan to do some heavy cleanup in the future. If possible pull the data from FG and avoid threading if possible. You can use the Qt event queue in a first draft.

You don't have to change Navconnect or Navmap. I can do this.

This shows how to use the Qt XML API https://github.com/albar965/atools/blob/master/src/fs/pln/flightplanio.cpp#L824 But I'd rather user a simpler text format or even binary. XML and JSON come with some overhead.

Thanks for helping out! Alex

slawekmikula commented 4 years ago

Thanks, but AFAIK the littlexpconnect is a standalone plugin that needs to be run inside XPlane. I cannot do this with flightgear. I can start FG with option to send some data to other endpoint which has TCP/UDP connection open. So creating something similar as littlexpconnect i had to create standalone app with its own main loop to open tcp connection, listen to fg incoming data and then send it through shared memory as littlexpconnect is doing. Is this your proposal ?

User then have to: a) define output in flightgear b) open new application (let's say littlefgconnect) and starts it (it's own GUI) c) open littlenavconnect d) open littenavmap

If i want to implement a) and b) directly in the FG source code I don't think it would be accepted by core FG developers. So that's why my proposal was to implement it in littlenavconnect. Of course if by design you dont' want to do it directly in the littlenavconnect code there is solution:

I can implement everything in the code similar to littlexpconnect (create tcp server, listen to fg data, parses it, create LNM data and feed it to the shared memory but I need something to call me and create my instance e.g. modification in the littlenavconnect to define external "plugin" to get the data.
Basically in littlexpconnect the XPlane API has functions that starts/stops the process.

What's your opinion ?

albar965 commented 4 years ago

Is there really no pull option in FG? Simply connect and fetch the data? What about the telnet interface?

Sorry, but I don't like this command line configuration stuff or defining output manually by the user in FG. Very error prone on the user side. This can cause a lot of support work for me and plenty of emails here. Hope you understand.

Best way would be LNM to connect to a running FG and fetch data (probably after automatic output configuration). Could the telnet interface be used for this?

I'm not proposing to use shared memory. I suggested the XpConnectHandler as a programming example for a ConnectHandler.

Ignore Navconnect for now. It uses the same mechanisms as LNM to connect to simulators and should not be required at all to connect to FG.

User should be able to connect to a local FG without using Navconnect, without plugins and without shared memory. Just (local) network traffic between LNM and FG should suffice.

Alex

slawekmikula commented 4 years ago

Telnet would be too slow. One had to query each property. There is better solution which I propose. Use generic output (http://wiki.flightgear.org/Generic_protocol). User does not have to configure it manually (configure data structure). There would be provided protocol xml file which defines what should be parsed and send to the other side (LNM). It is common thing with other integration in FG to use this solution (and I have some ideas to simplify this even more).

This is basically the thing i propose. I'll create protocol definition for flightgear. Then user will have eg. littlenavmap.xml file. He drops this in FG fgdata/Protocol folder and run flightgear with option (defined in the GUI) as (https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Docs/README.IO#l30): --generic=socket,out,10,localhost,6000,tcp,littlenavmap

So flightgear after starting will be sending data which conforms to littlenavmap structure (can be xml or binary) via tcp to localhost port 6000 10 times per second (10Hz).

I have to create endpoint on the LNM side.

OK, other issue - after reading your last post I see, that i misunderstood navconnect purpose. As I read it, one does not have to run littenavconnect in order to use XPlane/FSX connectors in LNM right now. They use the same code located in atools but normally LNM is able to run it. Navconnect is only needed for transport the data from external machine.

So if I implement code in atools similar to XpConnectHandler - the LNM and navconnect could use it. Then my task is to look at the atools/fs/sc and do something to work like xpconnecthandler.cpp (on LNM side).

Of course there should be some modification on LNM GUI (and possibly navconnect GUI) to use this code but right now it's not that important (you can help with this later).

So, may I ask - is there some helper test runners or something that I can use to implement FgConnectHandler and test it without touching anything in LNM main code yet ?

albar965 commented 4 years ago

This is basically the thing i propose. I'll create protocol definition for flightgear. Then user will have eg. littlenavmap.xml file. He drops this in FG fgdata/Protocol folder and run flightgear with option (defined in the GUI) as (https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Docs/README.IO#l30): --generic=socket,out,10,localhost,6000,tcp,littlenavmap

Sounds like a plan. :-) Placing the XML should be good enough for users. We could even add an option later to start FG with correct command line from LNM (maybe). Just an idea: Think about pipes instead of sockets. This rules out firewall issues on Winblows.

OK, other issue - after reading your last post I see, that i misunderstood navconnect purpose. As I read it, one does not have to run littenavconnect in order to use XPlane/FSX connectors in LNM right now. They use the same code located in atools but normally LNM is able to run it. Navconnect is only needed for transport the data from external machine.

Absolutely right. Navconnect is only needed for networked connections.

So if I implement code in atools similar to XpConnectHandler - the LNM and navconnect could use it. Then my task is to look at the atools/fs/sc and do something to work like xpconnecthandler.cpp (on LNM side).

Yes.

Of course there should be some modification on LNM GUI (and possibly navconnect GUI) to use this code but right now it's not that important (you can help with this later).

Yes. I could do this since it affects quite a few places in LNM and not only GUI. People will also use this without simulator database (Navigraph only). This will also require a few changes. Have to see how this can be done.

So, may I ask - is there some helper test runners or something that I can use to implement FgConnectHandler and test it without touching anything in LNM main code yet ?

Sorry, no test runners for simulator connections. I only have a test framework based on Qt test which I use to develop and test basic atools functionality (https://github.com/albar965/atoolstest).

There are some tests using network connections which also show how to use the Qt event loop: https://github.com/albar965/atoolstest/blob/master/src/tests/updatetest.cpp Maybe you can extend these.

Alex

slawekmikula commented 4 years ago

Thanks, That is enough for me right now. I'll start this tomorrow.

From what branch should I start with ? atools/master or atools/release/3.6 ?

albar965 commented 4 years ago

Currently working on the master branch which I consider development/unstable branch. I create branches starting with a beta for a major releases. Release branches are prefixed with "release/"

I know this is completely the opposite what the rest of the world is doing with Git. :-)

Alex

slawekmikula commented 4 years ago

Roger. I'm doing the same, so not whole of the World ;)

slawekmikula commented 4 years ago

@albar965 Alexander, only FYI. I'm working on it, but slowly - needs to learn/remeber anything what I forgot from Qt world

albar965 commented 4 years ago

@slawekmikula : No problem. Take your time. Feel free to ask if something is not clear. Alex

slawekmikula commented 4 years ago

Alex, small info. I'm working also with the FG guys to enable integration in better way. Something is already done (ability to enable protocols via addons and not with special commandline options). I'll be working with this and with LNM integration together.

albar965 commented 4 years ago

@slawekmikula Sounds great. A plugin/addon like Xpconnect is the better solution compared to the command line parameters IMO. Alex

slawekmikula commented 4 years ago

Alex, some holiday free time and this is so far:

But I need your help with the code. Sorry, but Qt is not my field of experience and it will take me much more time without help. Current progress:

protocol to export data from flightgear - OK - protocol is csv format, with ; as a separator. c.a. 70% of xplane data is right now exported. I've dig inside FG to find a way to get aircraft physical data (if available)
plugin to flightgear with the protocol - OK (but it will be available at best with next release of flightgear because of changes/implementation in the core source code in FG to enable this) - at this moment it can be run from commandline
source code in atools and littlenavmap - somewhat correct

Please take a look at what is done in these branches: https://github.com/slawekmikula/littlenavmap/tree/feature/138-flightgear https://github.com/slawekmikula/atools/tree/feature/138-flightgear

What is not working:

UDP server (listener) for data from flightgear. I've created simple UDP server in java and can verify that the data goes out of FG with the encoding as in the exemplary string in the fgconnecthandler code - i've implemented UDP server, i think it is running but somewhat I cannot receive data
all of the code from receiving data to parsing is not done. Done is parsing from data which I received in java testapp
getting UDP port from UI - i've modified littlenavmap UI to define connection to flightgear and persist it, only not getting this in fgconnecthandler

i'm stuck with the UDP code and if you find some time to look at it I would be grateful.

albar965 commented 4 years ago

@slawekmikula Will look at it. Gimme a few days. Alex

slawekmikula commented 4 years ago

Take your time. It's not that urgent. I think (AFAIK) the problem with UDP is either slot/signal connection or something with threads. Don't know exact structure of threads for connecting and maybe i done something wrong. Maybe UDP server have to be run in main Qt thread and it is not running. "Broadcastreceiver" project from Qt examples works OK and receives the data. Code was copied from this in the last commit. Of course please suggest other implementation. I've done everything (so far) in one file fgconnecthandler but architecturally it should (?) be divided into three classes (fgconnecthandler, udpserver, messageformatter).

Anyway take your time.

albar965 commented 4 years ago

Looking at it and see no obvious issues. Note that this will work only in LNM or any other application which has an event queue running (app.exec()). It will not work in a plain main method. Doing more research now. Never worked with UDP so far. Happy new year! Alex

slawekmikula commented 4 years ago

If you want i can paste somewhere java code for sending the information instead of flightgear. It can be used for testing - anyway the code right here (udp server and packet parsing) is not connected and any UDP packet that comes to the receive method is a solution for me :)

I was testing it inside LNM (that's why i've implemented also GUI in the LNM code)

Let's rephrase my assumptions:

UDP service creation works - i'm testing it on linux with nc -z -v -u localhost 7755 and it reports the port is open when LNM starts and UDP port is initialized.
signal connection does not throw anything suspicious
receive handler is not called :(

I've tried creating Qt UDP server with different parents (same threads ? different threads ? no main thread ?). Without any luck. Exemplary code from Qt (broadcastreceiver) when I start it on port 7755 it reports new packages arrives and displays it.

On the other side - does LNM have something implemented in REST/Websocket area ? I'm looking for a tcp rest consumer with json parsing. I'm looking at a way to get AI/MP information from FG through embedded http server.

albar965 commented 4 years ago

I have to compile, debug it and play around a bit.

atools has a HTTP server (third party code): httpserver and the templateengine. Good enough for REST but no Websockets. LNM has it integrated.

I think about dumping the whole TCP protocol too and using the webserver and HTTP instead for Navconnect but I'm a bit scared of the HTTP overhead.

albar965 commented 4 years ago

[2020-01-02 12:34:04.098 default WARN ] unknown:0: QObject: Cannot create children for a parent that is in a different thread.
(Parent is atools::fs::sc::DataReaderThread(0x22ae580), parent's thread is QThread(0x1508530), current thread is atools::fs::sc::DataReaderThread(0x22ae580)

The handler is started by the DataReaderThread which inherits from QThread. The code is executed in the thread context but the FgConnectHandler / QObject derived from QThread is owned by the main thread. This is a Qt speciality/nuisance which I have to fix somehow. This keeps the socket from sending signals across threads. Probably by using the thread worker model which will also include a thread private event loop.

Loosely related to #327.

This will take a while. :-(

slawekmikula commented 4 years ago

Yep, I've suspected that and as I said I was fiddling with the "parent" for the UDPSocket in order to get rid of this message. I thought in the latest code i've got rid of this message (hm, maybe i haven't look close enough to the log) by providing the UDPSocket "parent" from the main thread, I think I was wrong.

Take your time. Maybe there is some "dirty" workaround in order for me to finish the messaging code in the working state - so there will be left only the bare network code ?

As for #327 - there is also info about JSON - so right now there is no JSON parser in LNM available ? It could be also a path for connecting to FG (http call to JSON or websocket with JSON push) but does new tcp connection from FgConnectHandler also would be hit by the signal sending through.threads ?

albar965 commented 4 years ago

I think the problem is the missing event queue. The socket simply does not work without one. Using a worker can enable this. Actually I enabled the message again by changing the parent. Anyway it does not work.

You can try to use a blocking socket connection which does not use signal handlers. See QAbstractSocket Class and look for blocking. This might be even a good solution but I have no idea what happens if the thread is blocked for a long time. Worth a try.

Qt provides a JSON parser.

slawekmikula commented 4 years ago

Ok, I'll take a look at QAbstractSocket and implement it in a blocking mode. Sometime in the weekend.

I'll dig also the JSON path, but i've to ask FlightGear main developers on the possible method - is it possible and not to make too much overhead on FG side.

albar965 commented 4 years ago

Lemme know how it's going. This can save me the change to a worker thread which can have side effects. Digging into other stuff for now (#466).

slawekmikula commented 4 years ago

Not so good. I was trying to forcefully use direct methods from QUdpSocket (blocking). First - the bool FgConnectHandler::connect() should return immediately. If I enter there in infinite loop the UI signals "Connecting". But this is something to resolve.

But I was using methods udpSocket->waitForConnected() udpSocket->waitForReadyRead()

Does not block anything :) (as https://doc.qt.io/qt-5/qabstractsocket.html#waitForReadyRead) it should block. Nonetheless there was no wait and I immediately enter QByteArray arr = udpSocket->read(100); and got error "I/O not open". So nothing substantial from my side :(

I was looking at other ways to get the data (websocket/mirroring propertytree) but without any good idea. Anyway i'll next try this communication for AI/MP but first user airplane info.

slawekmikula commented 4 years ago

@albar965 Alex, i've some free time to dig this issue with UDPSocket. Only as a example, i've found a way to correctly bind UDPSocket and receive data. I've moved QUDPSocket to connectclient.cpp (creating and binding signals). After that socket receives data which i'm sending. Code is here: https://github.com/slawekmikula/littlenavmap/commit/c62c4184e1a02b4a727796474064066d986635d8

It's only sketch. So the main problem is with connecting signals and slots during method connect() which is run by the DataReaderThread (different threads, error as above).

My humble question - do you see any option to somehow use this observation and give me advice how to restructure code in order to make it work and do not look ugly ? This attempt is bad as hell regarding encapsulation. I've moved logic from fgreader code to main app.

Hope this helps move things forward.

slawekmikula commented 4 years ago

Another option is to create totally standalone application (as littlexpconnect but not a plugin but standalone app) to write to shared memory. There everything can be configured. Is this solution OK for you (additional application) ?

albar965 commented 4 years ago

Hi Sławek, glad to hear back from you! Seems we have two options:

Create a worker thread (not derived from QThread, see Qt doc) inside the DataReaderThread thing. This allows to run a Qt event loop which handles the socket. No need to use signals to feed packages to the main application. You can store the data and use a mutex to limit access to the data field for the DataReaderThread. Nice integrated solution but can be only published with the next major LNM release which is still a bit away.
Create a standalone application as a connector using shared memory as you proposed. This can be released as soon as it is finished, independent of any LNM release.

Actually, I like your proposal number 2. The code can be merged into the main application later. For 2: The Little Navconnect project can be used as a template which already contains the build configuration for all three platforms (Linux, macOS and Windows).

There might be issues merging since I did an insane amount to changes in atools and LNM. I also changed the communication protocol, i.e. the data format of SimConnectAircraft and related. If you're aiming for a faster release you can put your changes into release/2.4 branch.

Alex

Edit: Did not look at your code yet but will do once I'm done with my current task.

slawekmikula commented 4 years ago

@albar965 OK. I'll try with standalone app. Everything I align with master branch.

albar965 commented 4 years ago

@slawekmikula: I changed the data format again (SimConnectAircraft) but did not update the protocol version since it is still a debug version anyway. Just want to let you know before you run into crashes.

Lsalvan commented 3 years ago

Hello

I'm a FG user; I have just downloaded LNM, is there finally a possibility of connecting FG to LNM ? Thanks

albar965 commented 3 years ago

No. I have not time to support that many simulators and did not get any help yet.

If nothing happens here I'll try it for the 2.8 release (next after 2.6). But I cannot promise anything.

Lsalvan commented 3 years ago

Thanks anyway, i can imagine it's pretty time consuming.

For your information, maybe you know that, but skyvector can be used with FG in "simulation mode", selecting the "X-Plane" option; it means FG apparently uses the same "connectors" as X-Plane; i don't know if it can help

Laurent

Le mer. 9 déc. 2020 à 12:13, Alexander Barthel notifications@github.com a écrit :

No. I have not time to support that many simulators and did not get any help yet.

If nothing happens here I'll try it for the 2.8 release (next after 2.6). But I cannot promise anything.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/albar965/littlenavmap/issues/138#issuecomment-741704741, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASBY27JNHHRSVBJCEPSDBCLST5LW3ANCNFSM4EA5PZUA .

slawekmikula commented 3 years ago

Hi all, Sorry but from my side RL prevents me from digging at it again.

The code at this point is on my forks: https://github.com/slawekmikula/atools/tree/feature/138-flightgear and https://github.com/slawekmikula/littlenavmap/tree/feature/138-flightgear but already mentioned here, the tcp/udp listener won't run inside littlenavmap because of the threading/Qt interop issues. So what was concluded the best thing is to create standalone app similar to the littlexpconnect and listen there for UDP packets from Flightgear side and write to the shared memory the same as xp addon. The protocol file and addon for it was also created.

In the meantime i begun work on the Phi interface in the flightgear source code (Phi is a web browser interface to the flightgear and it is a base FG feature) in order to correct some errors there and also to extend it's web API to feed the data to e.g. littlenavmap without additional plugins/protocols. The work in the current state is on my FG forks on the sourceforge.

So that's all. Nonetheless the parsing code in my LNM forks and protocols for flightgear is working and only if the threading/udp issue could be somehow resolved it would be the fastest way to make it working - but only "own" plane information - without AI objects or integration with FG navdb. It can be only done via the Phi web interface (that's why I started looking at it).

Lsalvan commented 3 years ago

Thank you.

Le mer. 9 déc. 2020 à 15:00, Sławek Mikuła notifications@github.com a écrit :

Hi all, Sorry but from my side RL prevents me from digging at it again.

The code at this point is on my forks: https://github.com/slawekmikula/atools/tree/feature/138-flightgear and https://github.com/slawekmikula/littlenavmap/tree/feature/138-flightgear but already mentioned here, the tcp/udp listener won't run inside littlenavmap because of the threading/Qt interop issues. So what was concluded the best thing is to create standalone app similar to the littlexpconnect and listen there for UDP packets from Flightgear side and write to the shared memory the same as xp addon. The protocol file and addon for it was also created.

In the meantime i begun work on the Phi interface in the flightgear source code (Phi is a web browser interface to the flightgear and it is a base FG feature) in order to correct some errors there and also to extend it's web API to feed the data to e.g. littlenavmap without additional plugins/protocols. The work in the current state is on my FG forks on the sourceforge.

So that's all. Nonetheless the parsing code in my LNM forks and protocols for flightgear is working and only if the threading/udp issue could be somehow resolved it would be the fastest way to make it working - but only "own" plane information - without AI objects or integration with FG navdb. It can be only done via the Phi web interface (that's why I started looking at it).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/albar965/littlenavmap/issues/138#issuecomment-741788809, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASBY27OKKS3WJCQ5JXIZD5DST57HHANCNFSM4EA5PZUA .

slawekmikula commented 3 years ago

Ok, I've something done regarding this issue.

There is the repository: https://github.com/slawekmikula/flightgear-addon-littlenavmap with the Add-On to the FlightGear There is the repository: https://github.com/slawekmikula/littlefgconnect for application that connects to this Add-On and mimicks XPlane connector (via shared memory) in order to give the information to the LittleNavMap

Manual for this connection is here: https://github.com/slawekmikula/flightgear-addon-littlenavmap/blob/master/doc/manual.md

There is some issues:

not every data is covered with current state of the code. The protocol file shows from what properties the data is taken from (https://github.com/slawekmikula/flightgear-addon-littlenavmap/blob/master/FGData/Protocol/littlenavmap.xml). If someone from FG community can check it/correct it/add missing data it would be great.
the AI craft (and online crafts) are not send right now (but in the future it can be done but with quering http server on FG side)

If anyone can test it and report what can be corrected/what is not working it would be super ! Alex, if you can take a look at the fgconnect code and correct it/make better it would be OK. The code is based on littlenavmap and littlexpconnect code with my code to get/parse the data from the FlightGear.

Sneak peek: littlenavmap

Have a great New Year :)

Lsalvan commented 3 years ago

Hi

Great, i’ve juste seen your post on fg forum.

I will try asap.

Thanks for that.

Le sam. 2 janv. 2021 à 16:41, Sławek Mikuła notifications@github.com a écrit :

Ok, I've something done regarding this issue.

There is the repository: https://github.com/slawekmikula/flightgear-addon-littlenavmap with the Add-On to the FlightGear There is the repository: https://github.com/slawekmikula/littlefgconnect for application that connects to this Add-On and mimicks XPlane connector (via shared memory) in order to give the information to the LittleNavMap

Manual for this connection is here: https://github.com/slawekmikula/flightgear-addon-littlenavmap/blob/master/doc/manual.md

There is some issues:

not every data is covered with current state of the code. The protocol file shows from what properties the data is taken from ( https://github.com/slawekmikula/flightgear-addon-littlenavmap/blob/master/FGData/Protocol/littlenavmap.xml). If someone from FG community can check it/correct it/add missing data it would be great.

the AI craft (and online crafts) are not send right now (but in the future it can be done but with quering http server on FG side)

If anyone can test it and report what can be corrected/what is not working it would be super ! Alex, if you can take a look at the fgconnect code and correct it/make better it would be OK. The code is based on littlenavmap and littlexpconnect code with my code to get/parse the data from the FlightGear.

Sneak peek: [image: littlenavmap] https://user-images.githubusercontent.com/157701/103460772-50336a00-4d19-11eb-87d3-bba0fc282b20.png

Have a great New Year :)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/albar965/littlenavmap/issues/138#issuecomment-753488343, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASBY27LQEDIBHEG2O3AN7ODSX45CPANCNFSM4EA5PZUA .

slawekmikula commented 3 years ago

@albar965 Alex, I hope you've seen updated on this thread. I've got additional questions. One user successfully compiled and is using it in the FlightGear but have two observations.

LNM has an option to collect aircraft performance data. atm this doesn't seem to work though
LNM did update the a/c position on the map just fine. but it seems it didn't notice the flight had been started (when flying with a flight plan created in LNM but hand-flying in FG, Cessna 172P). iirc there was a text shown in LNM sth like "Location: airport, parked" while i was already flying

How can I handle it ? Aircraft flags ? More on the topic here: https://forum.flightgear.org/viewtopic.php?f=6&t=38535&p=379319#p379317

albar965 commented 3 years ago

@slawekmikula Sorry. I had no time yet to look at it. Too busy. :face_with_head_bandage:

I quickly looked over my code and performance collection needs fuel flow. Both values, gph and pph. LNM does not look at fuel tanks. What is also really needed is ground speed, the altitude above ground and the ON_GROUND flag. These are used to detect the start and end of a flight for the logbook.

Logbook and fuel calculation should do well if these values are present. These at least come to my mind so far. Alex

albar965 / littlenavmap

Featurrequest: Connectability to flightgear #138