#19 interfacing with XDR streams

open
nobody
None
5
2010-11-22
2010-11-22
Anonymous
No

We would like to populate a display with data from another application that already uses XDR for encoding messages for transmission via UDP sockets.

We are hoping this would be possible from a UA client script, without a lot of Java programming.

We have taken a look into the source code, and our understanding is that" common.arinc661.com" is the right place for this?
There seem to be various protocol wrappers provided already. The question now is how to best go about adding a new type that is ALSO accessible from UA scripts?

The idea would be to instantiate a new UDP/XDR "channel" and then use a UA script for getting out the fields from the XDR stream. For example, to parse the lat/lon pairs of the stream and send them to the CDS.

There seems to be an AbstractProtocol wrapper already, could you add another wrapper on top of this that also exposes this for use by scripts?
Something like "ScriptableAbstractProtocol".

This would have all the power of the current implementation, but make the I/O system available to and customizable from scripting space, so that users could instantiate and parameterize scripts without having to modify the Java code or creating new plugins.

Supporting XDR seems like a good idea in general, because it is an important standard that is in wide use.

http://en.wikipedia.org/wiki/External_Data_Representation
http://java.freehep.org/freehep-xdr/apidocs/hep/io/xdr/XDROutputStream.html

Discussion

  • Hervé Girod

    Hervé Girod - 2010-11-22

    Do you want to pass the ARINC 661 buffer as an XDR stream from:to the UA to/from the Server ? In that case, it's normally "simple" to write a custom Protocol and use in in a Client or a Server. Looking at XDR, it seems in that case that the method required to read the stream of bytes would be readFully (and write() for the DataOutput). Am I right ?

    However, the protocol is entirely transparent to the UA after it has been defined which protocol you will use, I will create one or two articles about this in the wiki tonight ;)

     
  • Hervé Girod

    Hervé Girod - 2010-11-23

    I should al;so add a custom protocol in the demos ;)

     
  • Nobody/Anonymous

    the idea was to access the XDR stream ONLY from the UA, for populating an existing MapHorz display with positions of moving objects (aircraft), so that the display can be used for "live" data.

    This is for a TCAS-like display. So the XDR stream would be just INPUT that is to be processed by the UA for generating the widgets on the CDS so that we can test the instrument with sample data.

    The original idea was:
    - instantiate a new UDP connection to a server (which provides the traffic feed)
    - instantiate a new XDR wrapper for the UDP connection
    - customize fields/values to be parsed out of the XDR stream (lat,lon,alt)
    - associate these with A661 widgets

     
  • Nobody/Anonymous

    ok, thanks for the tutorial.
    I looked into it, it seems that these protocols are not meant to be to UA clients or even client-side scripts in the first place?
    It seems the protocol interface is specifically meant to be used as the transport for the communications between the CDS and the UA. We were on the other hand looking for a way to use the protocol system to connect to a "live feed" with traffic that can be used for instantiating objects in the UA and driving the CDS accordingly.

     
  • Hervé Girod

    Hervé Girod - 2010-11-24

    OK, I understand now. Well I think that even if it would not be related with the default protocols in the project (as you said, meant to be used in Client/Server communication), I guess you could copy the DatagramProtocol (which deals with UDP), the AbstractDatagramProtocol, use or copy the threading stuff in the base directory, and get rid of what you don't need (Channels for example), and then you would be able to use it for your own needs.

    The architecture of the Protocol stuff allow to store the queue of incoming events (up to a value defined for the protocol) to be able to continue to process datas and avoid to lost any.

     
  • Hervé Girod

    Hervé Girod - 2010-11-25

    After some thinking, I think that my answer was maybe not the best I could offer. You are not obviously the only one who would like to connect the Client to an external source / provider, and the project already has some kinds of (maybe not generic enough) protocols who already manage background threading, message reception, etc... SO I think that a good idea would be for the Project to propose some kind of framework to help people to do this, not with XDRSteam of course, but it would be great if you only add to specify a few methods to be able to communicate with an external source. What do you think?

     
  • Nobody/Anonymous

    Thanks for the response.

    The idea you outline sounds very useful.
    In the meantime the forum announcement regarding scripting seems interesting, so maybe we could simply use that instead for making an XDR handler accessible to scripts?

     
  • Hervé Girod

    Hervé Girod - 2010-11-27

    With the last changes making an XDR handler accessible to scripts, so maybe you can try with this now. Of course I will continue to investigate to offer some generic way to access an external source provider.

     
  • Hervé Girod

    Hervé Girod - 2011-01-15

    Now that the DataProvider framework ihas been done (and even if there is a lot of areas of improvements there), I hope to be able to provide an XDR DataProvider in contribs

     
  • Nobody/Anonymous

    Just FYI: Anybody interested in looking into this, should know that you can also easily use FlightGear to test XDR connectivity, because FlightGear has built-in XDR support, too:

    In fact, its built-in multiplayer protocol uses XDR internally. So you could connect to a FlightGear multiplayer server as an "observer" and display "live" multiplayer traffic, even without having to run FlightGear or the multiplayer server locally. Obviously, that would require an internet connection - but that would still be the easiest way to get a live "traffic" feed from a fairly active flight simulator network (just go to KSFO (San Francisco Intl.).

    Basically, all that is needed is an UDP socket and support for decoding XDR-encoded packets, the protocol specs are fairly simple actually:

    http://wiki.flightgear.org/Multiplayer_protocol
    http://wiki.flightgear.org/Multiplayer

    - Hooray

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks