Network output data

  • We have published an example dll project in our sdk which receives data from the simulation. You could use this example project and expand it to send the data through udp or through other means of communication.


    What kind of applications do you want to power with data from Aerofly?

    It should be possible to power basic instruments like airspeed, attitude, altitude, vsi, turn indicator, heading, frequencies on the radio stack, etc. We also provide position data for map applications. Data like for engine instruments is not sent through to the external dll. If you need just few more data sources (e.g. engine rpm, manifold pressure) we may be able to add that in.

  • Thanks Jan,

    The convenient thing is that users do not have to install extra dlls, only that they activate the sending of broadcast data and my application collects them, it is what I currently do with other simulators and I would like to be able to include yours in my catalog. I will also look at the example DLL to see what can be done.

    Regards,

    Peix

  • Hi, im not sure if this helps but I modified the DLL for my own external cockpit display that sends broadcasts all of the available messages to UDP.


    Peixacu, which messages do you require exactly? If the messages are available I could develop a DLL that broadcasts these over UDP.


    Andy

  • Hello Andy,


    Thank you very much, in fact I need all available messages, i.e: pitch, roll, yaw, ias, altitude, heading, turn rate, sip/skid, etc,

    all engine parameters, i.e: rpm, man press, oil temp, oil press, fuel, electrics, etc.

    all navigation, i.e: vor crs, dme, adf bearing, etc

    all autopilot params.


    You can contact me at peixsoft@gmail.com


    Best regards

    Peix

  • Hi, im not sure if this helps but I modified the DLL for my own external cockpit display that sends broadcasts all of the available messages to UDP.


    Peixacu, which messages do you require exactly? If the messages are available I could develop a DLL that broadcasts these over UDP.


    Andy

    Hi Andy,


    as you’re up to speed on the messages available, are you able to confirm if it is possible to obtain all of the following at a reasonable update frequency. There’s been a fair bit of confusion.


    pitch

    Roll

    Yaw

    Rate of pitch

    Rate of roll

    Rate of yaw

    Heave acceleration

    Sway/ lateral acceleration


    it would be great to get my motion platform moving again after a couple of years out of action.


    phil

  • Phil,


    did you see the external dll sample from the sdk ?

    At line 73 of this source file, you will find the list of datas you could retrieve in theory...


    Cheers

  • looks promising thanks - any chance you could determine the frequency of them sending these? Everyone’s platforms stopped being useful when it dropped from 10+ hz to around 1hz

  • Hello,

    i just signed up.

    since i am currently writing a motion plugin for the SFX-100 platform (opensfx.com) i had a fight over many hours with the provided data.


    The external dll itself is called in about 50+hz frequency.

    The update interval is around 10hz for the majority of values.

    Some values are updated only 1hz interval (Aircraft.Acceleration or G forces for example).


    I tried the 10hz values and of course the rig is stuttering...

    Even tried to interpolate values but the resulting lag is also a problem.


    In my opinion the telemetry data is not usable with the current update rate for motion rigs.

    Is there a mapped memory file or something? I am currently exporting the data via udp.

    Am i missing something? Am i doing something wrong?



    If so - please tell me :)


    Best regards, Alex

  • Yes its really awesome. Built one by myself and wrote some plugins and extensions.

    Oh well i dont know if that is 6dof yet but there are users with additional custom built surge, traction loss and belt tensioning systems. :)


    But back to topic: Is here an admin, developer or some other guy who is in response for this issue? Please Help.

    Is this a known problem and on schedule to be fixed? I would accept any type of fix to crank up the update frequency.


    Thanks and best regards, Alex

  • don’t hold your breath sorry. We get excited about it now and then but have to resign ourselves to the fact its low priority to ipacs. Search the threads for ‘motion platform’

  • As we stated in the past, the external dll was never meant to support motion platforms and we made some optimizations to reduce the amount of data being send through to the dll in order to improve the connection to other external apps like FSWidgets that internally use a similar interface and share some of the code (as far as I'm aware). I'm not familiar with the implementation details myself, so please forgive me if I'm wrong here.


    We are really sorry that this also affected already existing motion platforms but we weren't aware how many actually already existed at the time. We usually make these sort of optimizations before the feature is ever released to the public. That is one reason why we don't show off everything that we work on all the time. It get's people excited but if we decide not to release the feature the disappointment is also huge. In this case we took away an unofficial/unintentional feature which affected the already released product. We'll try and be more careful in the future to not accidentally release unintended features that may brake with future updates.


    As mentioned above you can still interpolate between the individual messages that you receive and still have the option for a smooth motion platform without jerkiness if the receiving code doesn't just output the received data one-to-one to the motion platform. There may be a delay, yes.