20,741
edits
Property Tree/Native Protocol Slaving: Difference between revisions
Jump to navigation
Jump to search
Property Tree/Native Protocol Slaving (view source)
Revision as of 19:15, 26 March 2013
, 26 March 2013no edit summary
No edit summary |
No edit summary |
||
| Line 15: | Line 15: | ||
There is no synchronization in the native-fdm and native-ctrls protocols used for multiple displays. The master instance just transmit to the slaves, who process the data when and in the order it is received. This ought to work without problems in a local network. | There is no synchronization in the native-fdm and native-ctrls protocols used for multiple displays. The master instance just transmit to the slaves, who process the data when and in the order it is received. This ought to work without problems in a local network. | ||
native_ctrls is what gets sent to a remote fdm (i.e. the control positions) and native_fdm is what gets sent back to flightgear (i.e. the fdm data.) There's no reason you can't send both in your application if you need to. | |||
The FDM defines the control surface position (deflection) so that data is passed to FlightGear in the native_fdm structure. | |||
I will not claim that the existing FG interfaces cover every possible case. They have been designed to try to serve existing needs with some sort of logical consistency. | |||
If you have a specific need that doesn't easily fall within the existing interface structure, it's not all that hard to add your own custom interface. There are several examples (i.e. native_ctrls, native_fdm, native_gui, etc.) which you can copy and modify to suit your needs. If the new interface is of general interest or if you make a persuasive argument, we could probably add it to the FG code base. | |||
We have discussed a more flexible (xml configurable) udp binary interface, but no work has commenced on that front. | |||
It might not be a good idea to throttle the frame rate to the data rate - FG will only check for input (at most) once per frame and that could easily fall out of sync with the producer in this case (if data arrives too late in some frames). If FG consumes all pending data it finds that could explain the jerks. Can you try throttling to 2x the data rate? | It might not be a good idea to throttle the frame rate to the data rate - FG will only check for input (at most) once per frame and that could easily fall out of sync with the producer in this case (if data arrives too late in some frames). If FG consumes all pending data it finds that could explain the jerks. Can you try throttling to 2x the data rate? | ||