Re: [Jsbsim-devel] Matlab-JSBSim Interface

[D W. <hdw...@gm...>]

Good points, Tim (I'd expect nothing less from a GT guy!).  Meeting
'hard' timing constraints with sockets is a real chore.  However, I
*think* Philippose is only attempting to use Simulink as a really,
really, really, really expensive strip chart recorder at the moment.=20
A TCP "chug" every now and then ought not stop the show.

Stay tuned, however, because Jon will eventually charm the poor
unsuspecting lad into integrating full Simulink models with JSBSim (to
be accompanied by newsletter articles, of course) and we'll be awash
in timing issues and... wow... I'm getting all giddy just thinking
about it!!   :-)

D

--------
On 2/20/06, gt...@ma... <gt...@ma...> wrote:
> > If your Simulink app is running in lock-step with the JSBSim (i.e. -
> > you use a blocking socket read) then you get the sync for free...
> > right?  Every packet lands on the Simulink side of the fence at 1/120
> > of a second intervals.  Is more than that required?
>
> I must admit, I haven't really kept up with the coding of this project as=
 much
> as I would like to (those AE classes are getting in the way)... is the so=
cket
> interface for use on the same machine? If so, then you are correct, it wi=
ll come
> at the same time, 1/120 of a second intervals.
>
> If the purpose of the socket is to transmit across a network interface, t=
hen you
> are running into latency, bad packet order (requiring reordering and henc=
e more
> time), or damaged packages (if using TCP/IP, it will retransmit, if using=
 UDP,
> maybe missing a few is okay), all of which add a variable amount of time.
>
> Ideally, you are correct, but if the goal is robustness and use over a ne=
twork,
> then packet delivery timing may or may not be consistant.
>
> Sorry if this has no application here, but I thought I might just take a =
stab at
> it in case I happen to be right :)
>
> Tim Gallagher
> Georgia Institute of Technology
> School of Aerospace Engineering
>