sending external fdm data in the form of UDPpackets

[Thomas Biwer]

Umesh,

I am not quite sure but I think I've read something a long time ago that a
guy had the same kind of problem
and got rid of it by switching to another version of flightgear.
I think version 0.9.2 is quite obsolete. Maybe you should try changing to
0.9.10.

Otherwise, it would be nice to have some more detailed information about
the problem flightgear causes: Is it simply dying and closing
or hanging up? You might want to run FG with the --log-level=debug option
and tell us what the last message is you get from that.

Best,
Thomas

Hi,
I have interfaced external fdm(running separately on other PC) with

Flightgear by sending UDP packets to flightgear.i am currently using
Flightgear version 0.9.2 and 0.9.3 for >that purpose.however I have found
that although the packets reach the destination Pc,flightgear is not
running. I would like to know whether I am correctly forming and sending

the UDP packets.I am pasting some parts of the code related to UDP packets

sending.

<snip>
D:\FlightGear 0.9.3\bin\Win32\FGFS.EXE --native-fdm=socket,in,30,,5500,udp

--fdm=external

Please help......
Regards,
Umesh

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[umesh pandey]

I checked using Flightgear 0.9.8 but could not run it successfully.The few
lines of log data are as follows:

Running Main Loop
======= ==== ====
Updating time
Current Unix calendar time = 1164188445 warp = 0
Current GMT = 11/22/2006 9:40:45
Current Unix calendar time = 1164188445 warp = 0
Current GMT = 11/22/2006 9:40:45
Current Julian Date = 2.45406e+006
COURSE: GMT = 10/22/106 9:40:45
March 21 noon (GMT) = 1142922600
Time since 3/21/106 GMT = 246.132
days = 246 hours = 9.67917 lon = 0 lst = 14.0792
COURSE: GMT = 10/22/106 9:40:45
March 21 noon (GMT) = 1142922600
Time since 3/21/106 GMT = 246.132
days = 246 hours = 9.67917 lon = 0 lst = 14.0792
Current lon=0.00 Sidereal Time = 13.7616
gst => 181.762
Current LOCAL Sidereal Time = 13.7616 (13.7618) (diff =
Elapsed time interval is = 38000, previous remainder is =
Model iterations needed = 5, new remainder = 1346
Warning: read() not enough bytes.
interpolate(): lookup error, x to small = 0
interpolate(): lookup error, x to small = 0
Updating Sun position
Gst = 13.7616
t->cur_time = 1164188445
Sun Geodetic lat = -0.351519 Geocentric lat = -0.34935
sun angle relative to current location = 0.639324
Updating Moon position
t->cur_time = 1164188445
Moon Geodetic lat = -0.484999 Geocentric lat = -0.4822
moon angle relative to current location = 0.951894
Updating adjusted fog parameters.
FGTileMgr::update()
State == Running
FGTileMgr::update()
State == Running

interpolate(): lookup error, x to small = 10
Cockpit: code 1 status 0

Post by Thomas Biwer
Umesh,
I am not quite sure but I think I've read something a long time ago that a
guy had the same kind of problem
and got rid of it by switching to another version of flightgear.
I think version 0.9.2 is quite obsolete. Maybe you should try changing to
0.9.10.
Otherwise, it would be nice to have some more detailed information about
the problem flightgear causes: Is it simply dying and closing
or hanging up? You might want to run FG with the --log-level=debug option
and tell us what the last message is you get from that.
Best,
Thomas

Hi,
I have interfaced external fdm(running separately on other PC) with

Flightgear by sending UDP packets to flightgear.i am currently using
Flightgear version 0.9.2 and 0.9.3 for >that purpose.however I have found
that although the packets reach the destination Pc,flightgear is not
running. I would like to know whether I am correctly forming and sending

the UDP packets.I am pasting some parts of the code related to UDP

packets
sending.

<snip>
D:\FlightGear 0.9.3\bin\Win32\FGFS.EXE--native-fdm=socket,in,30,,5500,udp

--fdm=external

Please help......
Regards,
Umesh

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Jorge Van Hemelryck]

On Wed, 22 Nov 2006 15:20:08 +0530

Post by umesh pandey
I checked using Flightgear 0.9.8 but could not run it successfully.The few

<snip>

Post by umesh pandey

Post by Thomas Biwer

D:\FlightGear 0.9.3\bin\Win32\FGFS.EXE--native-fdm=socket,in,30,,5500,udp

--fdm=external

Can you confirm that FLightGear is running, but waiting UDP packets,
probably in the middle of the ocean (lat=0, lon=0) ?

I can't remember if version 0.9.3 already had several log levels. Maybe
not. Anyway, it should reach a point where it announces that it is
opening a socket to listen on.

Then, it would be nice to check several things concerning the fdm_data.
First of all, your version of the protocol and of the struct definition
seems wrong. You should have FGNetVersion = 13, and some variables are
missing.

If you don't have the source code for FlightGear and are just
running a binary, get the source code for the exact version you use,
and look at src/Network/net_fdm.hxx. Note that it is C++ code, and it is
the only file to look at if you use 0.9.3. You will have a net_fdm.h,
in C, if you get a more recent version of FlightGear, and using this C
file should be even easier.

If it still doesn't work, check that your definition is correctly
adapted from the source code (net_fdm.h[xx]). Check the size of the
struct you send. I had that problem using UDP packets I sent from an
IRIX machine to 0.9.3 running on a Windows or Linux PC, the struct was
too big because of the enum I had left in the middle of the declaration.

Hope some of all this turns out to be helpful...

[umesh pandey]

What is the difference if I implement a structure given in net_fdm_mini.cxx
source code and send this struct as a UDP packet for interfacing with
Flightgear?????or is it necessary to use complete structure given in
net_fdm.cxx????? I have taken a look at native_fdm.cxx file also and found
that we have to do htonl
or htonf before sending the packets......is it necessary????I am a newbie in
this area.......I also would
like to know about what are the padding differences and network byte order
mean?????

Post by Jorge Van Hemelryck
On Wed, 22 Nov 2006 15:20:08 +0530

I checked using Flightgear 0.9.8 but could not run it successfully.Thefew

<snip>

Post by Thomas Biwer

D:\FlightGear 0.9.3\bin\Win32\FGFS.EXE--native-fdm=socket

,in,30,,5500,udp

Post by Thomas Biwer
--fdm=external

Can you confirm that FLightGear is running, but waiting UDP packets,
probably in the middle of the ocean (lat=0, lon=0) ?
I can't remember if version 0.9.3 already had several log levels. Maybe
not. Anyway, it should reach a point where it announces that it is
opening a socket to listen on.
Then, it would be nice to check several things concerning the fdm_data.
First of all, your version of the protocol and of the struct definition
seems wrong. You should have FGNetVersion = 13, and some variables are
missing.
If you don't have the source code for FlightGear and are just
running a binary, get the source code for the exact version you use,
and look at src/Network/net_fdm.hxx. Note that it is C++ code, and it is
the only file to look at if you use 0.9.3. You will have a net_fdm.h,
in C, if you get a more recent version of FlightGear, and using this C
file should be even easier.
If it still doesn't work, check that your definition is correctly
adapted from the source code (net_fdm.h[xx]). Check the size of the
struct you send. I had that problem using UDP packets I sent from an
IRIX machine to 0.9.3 running on a Windows or Linux PC, the struct was
too big because of the enum I had left in the middle of the declaration.
Hope some of all this turns out to be helpful...
--
Jorge Van Hemelryck
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Anders Gidenstam]

Post by umesh pandey
What is the difference if I implement a structure given in net_fdm_mini.cxx
source code and send this struct as a UDP packet for interfacing with
Flightgear?????or is it necessary to use complete structure given in
net_fdm.cxx????? I have taken a look at native_fdm.cxx file also and found
that we have to do htonl
or htonf before sending the packets......is it necessary????I am a newbie in
this area.......I also would
like to know about what are the padding differences and network byte order
mean?????

When you send data between two computers it is extremely important that
what the sending side sends is formated _exactly_ as the receiver expects.
Otherwise the receiver cannot interpret the message correctly.

If both of your computers have the same architecture, run similar
operating systems and both programs are compiled with the same compiler
(and same version) then one can be reasonably sure that just sending the
in-memory representation of a struct between the computers will succeed.

However, for a multiplatform application like FlightGear one has to do
something better. That is, to define exactly how the sent messages should
be formated (i.e. their binary representation) and ensure that this can be
encoded/decoded on every platform. So, yes you have to use htonf, etc :)

Sorry for the rant.. :P

I think I remember a similar discussion on this list earlier this year.
I'll see if I can find it.

/Anders
--
---------------------------------------------------------------------------
Anders Gidenstam
mail: andersg(at)gidenstam.org
WWW: http://www.gidenstam.org/FlightGear/JSBSim-LTA/

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[Martin Spott]

Post by Anders Gidenstam
If both of your computers have the same architecture, run similar
operating systems and both programs are compiled with the same compiler
(and same version) then one can be reasonably sure that just sending the
in-memory representation of a struct between the computers will succeed.
However, for a multiplatform application like FlightGear one has to do
something better. That is, to define exactly how the sent messages should
be formated (i.e. their binary representation) and ensure that this can be
encoded/decoded on every platform. So, yes you have to use htonf, etc :)

I don't have a solution at hand, still I'd like to point to a place in
FlightGear where this stuff "simply works": The current multiplayer
network interface allows to set IRIX/N32 against Linux/AMD64 and
they both communicate nicely to each other.
This setup includes different word-size, different byte order and
different compiler. The guys who have designed this interface
definitely did an excellent job,

Martin.

[umesh pandey]

After converting FGNetFDM structure(given in net_fdm.cxx) by using
htonf,htond or htonl, do we need to convert the structure into char packets
and send to FGFS. I am using FGFS 0.9.3.

Post by umesh pandey

Post by umesh pandey
What is the difference if I implement a structure given in

net_fdm_mini.cxx

Post by umesh pandey
source code and send this struct as a UDP packet for interfacing with
Flightgear?????or is it necessary to use complete structure given in
net_fdm.cxx????? I have taken a look at native_fdm.cxx file also and

found

Post by umesh pandey
that we have to do htonl
or htonf before sending the packets......is it necessary????I am a

newbie in

Post by umesh pandey
this area.......I also would
like to know about what are the padding differences and network byte

order

Post by umesh pandey
mean?????

When you send data between two computers it is extremely important that
what the sending side sends is formated _exactly_ as the receiver expects.
Otherwise the receiver cannot interpret the message correctly.
If both of your computers have the same architecture, run similar
operating systems and both programs are compiled with the same compiler
(and same version) then one can be reasonably sure that just sending the
in-memory representation of a struct between the computers will succeed.
However, for a multiplatform application like FlightGear one has to do
something better. That is, to define exactly how the sent messages should
be formated (i.e. their binary representation) and ensure that this can be
encoded/decoded on every platform. So, yes you have to use htonf, etc :)
Sorry for the rant.. :P
I think I remember a similar discussion on this list earlier this year.
I'll see if I can find it.
/Anders
--
---------------------------------------------------------------------------
Anders Gidenstam
mail: andersg(at)gidenstam.org
WWW: http://www.gidenstam.org/FlightGear/JSBSim-LTA/
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Anders Gidenstam]

Post by umesh pandey
After converting FGNetFDM structure(given in net_fdm.cxx) by using
htonf,htond or htonl, do we need to convert the structure into char packets
and send to FGFS. I am using FGFS 0.9.3.

Hi!

Well, when you have used hton*() on your struct it should (hopefully[1])
have the right (i.e. the one you should send) represantation in memory so
you can just reinterpret your struct as a char array of the right form:

typedef struct {...} mystruct_t;

mystruct_t anInstance;

char * sendbuffer = (char *)&anInstance;

This pointer could then be passed to sendto(2) or similar.

[1] The critical point here is to be sure that the compiler does not
insert any padding into the struct. Alternatively one could manually
and explicitly move the contents of the struct into a char array to be
sure it has exactly the right form (this is what I would do since
it also documents the actual packet format a bit more clearly).

Cheers,

Anders

[umesh pandey]

Hi,
I am using FGFS 0.9.10.I tried sending FGNetFDM structure(given in
net_fdm.cxx)(after doing htond or htonf) from one computer to another
computer running Flightgear but couldnt get it running. I tried Packet
Analyzer to check whether packets are reaching the particular PC or
not.Ifound that packets are reaching the PC running
Flightgear.Is there anyway I can verify on the destination PC that the
packets are in correct format...Can anyone provide me with sample UNIX
program to run Flightgear from external fdm data in the form of UDPpackets.

Post by Thomas Biwer

Post by umesh pandey
After converting FGNetFDM structure(given in net_fdm.cxx) by using
htonf,htond or htonl, do we need to convert the structure into char

packets

Post by umesh pandey
and send to FGFS. I am using FGFS 0.9.3.

Hi!
Well, when you have used hton*() on your struct it should (hopefully[1])
have the right (i.e. the one you should send) represantation in memory so
typedef struct {...} mystruct_t;
mystruct_t anInstance;
char * sendbuffer = (char *)&anInstance;
This pointer could then be passed to sendto(2) or similar.
[1] The critical point here is to be sure that the compiler does not
insert any padding into the struct. Alternatively one could manually
and explicitly move the contents of the struct into a char array to be
sure it has exactly the right form (this is what I would do since
it also documents the actual packet format a bit more clearly).
Cheers,
Anders
--
---------------------------------------------------------------------------
Anders Gidenstam
Algorithms and Complexity Group Phone: [phone]
Max-Planck-Institut für Informatik Fax: [phone]
http://www.mpi-inf.mpg.de/~andersg
---------------------------------------------------------------------------
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Martin Spott]

[...] Can anyone provide me with sample UNIX
program to run Flightgear from external fdm data in the form of UDPpackets.

Another instance of FlightGear ? ;-)
To my understanding the NetFDM wasn't really designed to be driven by
anything but FlightGear on the same type of hardware, so this really
might the best choice,

Martin.

[Curtis Olson]

Post by umesh pandey

[...] Can anyone provide me with sample UNIX
program to run Flightgear from external fdm data in the form of

UDPpackets.
Another instance of FlightGear ? ;-)
To my understanding the NetFDM wasn't really designed to be driven by
anything but FlightGear on the same type of hardware, so this really
might the best choice,

The NetFDM packet structure is designed to work across platforms and the
data field sizes and types are somewhat carefully chosen to avoid packing
differences between compilers. There is a very good chance this
communication mechanism will work between any two platforms you have access
to.

Curt.

[Martin Spott]

Hi Curt,

Post by Curtis Olson
The NetFDM packet structure is designed to work across platforms and the
data field sizes and types are somewhat carefully chosen to avoid packing
differences between compilers.

Hmmm, isn't NetFDM the "copy the struct to a network packet"-interface
or did I mix between two different network interfaces of FlightGear ?
At least this is what I read from earlier explanations and actually
this is as well the reason why I cancelled one project that was meant
to drive FlightGear as its display system ....

Cheers,
Martin.

[Curtis Olson]

Post by Martin Spott
Hi Curt,

Post by Curtis Olson
The NetFDM packet structure is designed to work across platforms and the
data field sizes and types are somewhat carefully chosen to avoid

packing

Post by Curtis Olson
differences between compilers.

Hmmm, isn't NetFDM the "copy the struct to a network packet"-interface
or did I mix between two different network interfaces of FlightGear ?
At least this is what I read from earlier explanations and actually
this is as well the reason why I cancelled one project that was meant
to drive FlightGear as its display system ....

Yes, NetFDM is what you say, but we've made sure all our data aligns on 4
byte boundaries, we only use 4 or 8 byte data structures, and we send
everything in network byte order. With these rules, you would be hard
pressed to find a system that is incompatible. (This actually was prompted
by some developers at mathworks who have a lot of customers that want to use
FlightGear to visualize their simulink flight dynamics models.)

Regards,

Curt.

[Martin Spott]

Post by Curtis Olson
Yes, NetFDM is what you say, but we've made sure all our data aligns on 4
byte boundaries, we only use 4 or 8 byte data structures, and we send
everything in network byte order. With these rules, you would be hard
pressed to find a system that is incompatible. (This actually was prompted
by some developers at mathworks who have a lot of customers that want to use
FlightGear to visualize their simulink flight dynamics models.)

.... errrm, and, at least some of them don't even dare to think of
using current versions of FlightGear. I was told they're afraid of
running into the hassle of reworking half of their interface with every
new version of FlightGear, because the interface actually is not what
people would call a stable protocol.

Actually this matches with the result of an experiement that I did
earlier. I picked a few network packets with the network analyzer and
fed some of them into a running FlightGear instance on the same
platform as the packets were generated (FreeBSD/i386). I managed to
'move' the aircraft by manually tweaking some bytes with the hex editor
and returning the captured packets to FlightGear on the same platform,
but it didn't work by feeding the same, "hand-selected" stream to
FlightGear neither on Linux/AMD64 nor on IRIX/N32.

Don't get me wrong: I don't intend to shoot you about inabilities of
this network protocol - well, I once was attepted to do so several
years earlier, but this is another story ;-) - but we might save
people valuable time if we make sure they don't get mislead.

Cheers,
Martin.

[Curtis Olson]

Post by Martin Spott
.... errrm, and, at least some of them don't even dare to think of
using current versions of FlightGear. I was told they're afraid of
running into the hassle of reworking half of their interface with every
new version of FlightGear, because the interface actually is not what
people would call a stable protocol.

The biggest issue is that people with proprietary software on one end get
locked into a specific version of FlightGear because as FlightGear evolves,
their proprietary tools can't or don't follow very quickly.

That said, the most recent version of the aerospace blockset for simulink
supports multiple versions of FlightGear including v0.9.10. However, some
people don't or can't upgrade because of the software costs.

Actually this matches with the result of an experiement that I did

Post by Martin Spott
earlier. I picked a few network packets with the network analyzer and
fed some of them into a running FlightGear instance on the same
platform as the packets were generated (FreeBSD/i386). I managed to
'move' the aircraft by manually tweaking some bytes with the hex editor
and returning the captured packets to FlightGear on the same platform,
but it didn't work by feeding the same, "hand-selected" stream to
FlightGear neither on Linux/AMD64 nor on IRIX/N32.

Work was done to improve the NetFDM structure prior to v0.9.10 so if you did
your experiements earlier than that, the picture has most likely changed.
Mathworks actually tested their tool on quite a few different platforms
(including Mac OSX) and made a few recommendations to improve the situation
which we followed up on.

Don't get me wrong: I don't intend to shoot you about inabilities of

Post by Martin Spott
this network protocol - well, I once was attepted to do so several
years earlier, but this is another story ;-) - but we might save
people valuable time if we make sure they don't get mislead.

No, say whatever you like, joking or not, and I'm not offended. There isn't
a single one-size-fits-all communcation protocol. That's why we have
several mechanisms available in FlightGear. The NetFDM is perfect for
certain situations and applications, and completely the wrong approach for
other situations.

There is some work (moving very slowly because involved) to create an xml
specification for a binary protocol so an external application can feed
flightgear an xml file to produce binary output matching exactly what that
external app wants and expects. Kind of like the "generic" protocol only
the underlying data is transmitted in binary form.

Curt.

[Martin Spott]

Post by Curtis Olson
Work was done to improve the NetFDM structure prior to v0.9.10 so if you did
your experiements earlier than that, the picture has most likely changed.

I did most of my tests way before 0.9.8. Does this mean the current
NetFDM is safe for use with 64bit- as well as big-endian systems ?

Post by Curtis Olson
There is some work (moving very slowly because involved) to create an xml
specification for a binary protocol so an external application can feed
flightgear an xml file to produce binary output matching exactly what that
external app wants and expects.

This is a very advanced approach !
Martin.

[Curtis Olson]

Post by Martin Spott
I did most of my tests way before 0.9.8. Does this mean the current
NetFDM is safe for use with 64bit- as well as big-endian systems ?

I don't have the ability to personally test a lot of combinations, but yes,
this should all work well as of v0.9.10.

Endianess is definitely handled. And even for 32 vs. 64 bit systems, they
all still use a similar convention where integers and floats are 4 bytes and
doubles are 8 bytes. As long as we confine ourselves to ints, floats, and
doubles (and use an int for boolean values, etc.) then we should have an
extremely high probability of getting any two machines to talk to each other
successfully.

I do know of one exception ... the X-Scale architecture seems to swap the
first 4 and last 4 bytes of doubles, so they aren't using a standard big or
little endian representation for double floating point numbers. But if you
know that in advance it's pretty easy to work around (since you will be
running your own code on this processor, not flightgear.)

Regards,

Curt.

[Martin Spott]

Post by Curtis Olson
Endianess is definitely handled. And even for 32 vs. 64 bit systems, they
all still use a similar convention where integers and floats are 4 bytes and
doubles are 8 bytes. As long as we confine ourselves to ints, floats, and
doubles (and use an int for boolean values, etc.) then we should have an
extremely high probability of getting any two machines to talk to each other
successfully.

We should probably write the current state down, define it as "The
NetFDM Protocol" and shoot everybody who breaks it .... Yet another
task on the TODO ....

Thanks, Curt, for taking the time to make things clear,

Martin.

[umesh pandey]

At last,I tried a sample program to send external fdm data to Flightgear
0.9.10.I now could see Flightgear responding to packets.However problem came
that as soon as the packets are arrived the time of day automatically
changes to night and I need to readjust the settings.

I would also like to know that at what sample time should I send the
external fdm data and at what rate should the Flightgear receive the
packets.I suppose this depends on hz option in following command:
--native-fdm=socket,in,30,,5500,udp (in this case 30).
I tried to send packets from my host computer every 1ms and used the
following option for Flightgear command.however,i couldn't get smooth
movement of aircraft.
I suppose this is related to packet sending rate at the source computer and
receiving rate at the destination computer.....

using log-level option I could see that packets are correctly being
identified by Flightgear!!!!!!!

Post by Martin Spott

Post by Curtis Olson
Endianess is definitely handled. And even for 32 vs. 64 bit systems,

they

Post by Curtis Olson
all still use a similar convention where integers and floats are 4 bytes

and

Post by Curtis Olson
doubles are 8 bytes. As long as we confine ourselves to ints, floats,

and

Post by Curtis Olson
doubles (and use an int for boolean values, etc.) then we should have an
extremely high probability of getting any two machines to talk to each

other

Post by Curtis Olson
successfully.

We should probably write the current state down, define it as "The
NetFDM Protocol" and shoot everybody who breaks it .... Yet another
task on the TODO ....
Thanks, Curt, for taking the time to make things clear,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[umesh pandey]

ypedef struct {...} mystruct_t;

mystruct_t anInstance;

char * sendbuffer = (char *)&anInstance;
At the source computer I tried to print the char* sendbuffer by using

printf("Data=%s",sendbuffer);

But I cannot see any data packets formed.Is that i am using wrong format for
printf or is the problem with something else!!!!!Please help!!!!!

Post by Thomas Biwer

Post by umesh pandey
After converting FGNetFDM structure(given in net_fdm.cxx) by using
htonf,htond or htonl, do we need to convert the structure into char

packets

Post by umesh pandey
and send to FGFS. I am using FGFS 0.9.3.

Hi!
Well, when you have used hton*() on your struct it should (hopefully[1])
have the right (i.e. the one you should send) represantation in memory so
typedef struct {...} mystruct_t;
mystruct_t anInstance;
char * sendbuffer = (char *)&anInstance;
This pointer could then be passed to sendto(2) or similar.
[1] The critical point here is to be sure that the compiler does not
insert any padding into the struct. Alternatively one could manually
and explicitly move the contents of the struct into a char array to be
sure it has exactly the right form (this is what I would do since
it also documents the actual packet format a bit more clearly).
Cheers,
Anders
--
---------------------------------------------------------------------------
Anders Gidenstam
Algorithms and Complexity Group Phone: [phone]
Max-Planck-Institut für Informatik Fax: [phone]
http://www.mpi-inf.mpg.de/~andersg
---------------------------------------------------------------------------
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Anders Gidenstam]

Post by Anders Gidenstam
ypedef struct {...} mystruct_t;
mystruct_t anInstance;
char * sendbuffer = (char *)&anInstance;
At the source computer I tried to print the char* sendbuffer by using
printf("Data=%s",sendbuffer);

Hi Umesh,

That printf() is quite unlikely to produce anything sensible (and unless
there is a 0 byte somewhere in anInstance it might try to print your
computers entire memory..). Us telling the compiler that it
should consider anInstance as an array of char:s does not mean that it
becomes a zero-terminated string that we could give to printf.

To determine whether anInstance got the right format or not you should
test to decode it with the same code as FlightGear uses. Either by copying
it to your application or by tracing fgfs or adding some temporary
printouts to it. (I'd do the latter as that would also tell me whether my
UDP-packets got through at all.)

Post by Anders Gidenstam
But I cannot see any data packets formed.Is that i am using wrong format for
printf or is the problem with something else!!!!!Please help!!!!!

I have a simple application that sends UDP packets to FlightGear here:

http://www.gidenstam.org/FlightGear/HeadTracking/

However, it does not talk to NetFDM but to a head tracking component that
only exists as a patch somewhere at the moment.

/Anders
--
---------------------------------------------------------------------------
Anders Gidenstam
mail: andersg(at)gidenstam.org
WWW: http://www.gidenstam.org/FlightGear/JSBSim-LTA/

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV