1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Position Syncing and SimConnect Errors

Discussion in 'SimConnect' started by 997R8V10, 19 May 2017.

  1. 997R8V10

    997R8V10

    Joined:
    11 Aug 2016
    Messages:
    8
    Country:
    unitedstates
    I'm attempting to sync two simulator's positions up using SimConnect. Currently, I have it set up to manually step the position every 10ms on the client side. The server side sends data every 100ms to the client, and the client calculates the velocity required based on that. However, there seems to be a sort of stuttering that occurs every time data is received from the server. Does anyone know how to create an algorithm that can smoothly sync position? (Maybe using extrapolation or something).

    Also, occasionally, SimConnect will through a COMException in various places (It's random) with the code 0xC00000B0, and I have no idea what that means. It's unfortunately not documented anywhere...

    Any help is greatly appreciated.
     
  2. Capn_Geoff

    Capn_Geoff

    Joined:
    15 Jan 2007
    Messages:
    74
    I too have a similar situation. I am updating at 8FPS from my server and you would think it would be very minor... but:
    1. when on the flight deck of a moving ship with "chocks on" wherein the two platforms maintain relative position - it is a very tiny motion. And I mean hardly noticeable.
    2. when on the flight deck of a moving ship with brakes on - there's a bit of stuttering - maybe a 3" movement. (which might be caused by the double precision variables(.000001degrees = about 3") - I don't know if P3Dv4 with it's bigger 64 bit float would solved that.
    3. When on short final approach the stutter is significant with the ship apparently sliding back and "jumping" forward in what I would say is about a 3 second cycle. I have shed tears over this and do not know why it happens. Again, maybe 64 bit would solve it... but it just seems like FSX/P3D doesn't pay attention to the updates and then decides to.

    edit *note: by relative position i mean a bearing/range from the "center" of the ship - ie where the model thinks 0,0 is. Until the chocks are set I use the lat/lon of the two platforms. Once chocked, though, I need to maintain the correct heading of the aircraft in relation to the ship.

    Sorry can't help with the COMException... I've no idea
     
  3. 997R8V10

    997R8V10

    Joined:
    11 Aug 2016
    Messages:
    8
    Country:
    unitedstates
    I do have my variables set to float64 to prevent that exact same thing. But, it seems more like a calculation issue.
     
  4. Capn_Geoff

    Capn_Geoff

    Joined:
    15 Jan 2007
    Messages:
    74
    Mmm, now that you've brought it up - I wonder if I should try using relative positions rather than lat/lon when, say, within 1NM of the ship. The only reason I think that the stutters occur is that there is a synchronization problem since we are using SimConnect which is a server/message passing scheme with SimConnect doing god only knows what behind the scene. But, again, as I say, with the "chock" set and using relative position there is essentially no stutter at all... but then the position info is derived from the ship's position and not from both the ship and the aircraft lat/lon. <sigh> I dunno - worth an experiment once I get some other problems solved in the P3D4V.

    Good luck and post if you solve it - I will do so as well.
     
  5. kabekew

    kabekew

    Joined:
    16 Mar 2010
    Messages:
    52
    Country:
    unitedstates
    997R, it sounds like you're doing client-side prediction with dead-reckoning, which probably isn't the best way unless you need absolute time synchronization with all displays showing the exact identical scene (or as close as the system can get, for example if they are side-by-side networked displays which the user can easily detect are out of sync -- although in that case you're probably on a LAN and can just increase the update rate from the server to 10ms instead of 100).

    If you do need that precise time synchronization, client side prediction will give you the closest result, but you will also have mispredictions from the dead reckoning you will need to store and smoothly correct over time instead of just jumping the object to the newly-updated position (which sounds like what you're doing now). For example, at time 0.0(ms) you get an object update from the server, and it's velocity vector (let's say for example, "straight ahead") and you start stepping that object straight ahead along the vector every 10ms. At 20ms, the object on the server starts to turn right, but you won't know that until the next update, so you keep showing it stepping "straight ahead." At time 100.0ms, you get the new update which says the object is to the right of where you've been stepping it along. The difference between your stepped-along (dead-reckoned) position and the new "actual" position you would save as the error delta. The next "step" would continue from the last dead-reckoned position (not the new updated position), but along the newly updated velocity vector, PLUS you add a fraction of the saved error delta (e.g. half the remaining error delta each step, then halving that saved value so you get a continuous, smooth "correction" curve the user hopefully won't notice).

    If it's okay for the client to be slightly behind the server, you can avoid all that by caching one of the updates and extrapolating from the 2nd previous update to the last update. You won't have any mispredictions or "sliding" as objects correct their update errors, but in your case the client will be seeing the scene 100ms behind the server. That might not matter though to your users.

    0xC00000B0 is a Windows kernel "disconnected pipe" error. I'm pretty sure SimConnect uses named pipes internally, and it probably automatically reconnects so I bet you can just ignore it. .

    Capn_Geoff, the sliding and stuttering of a remote object that you're showing locally can happen if you're not freezing physics processing by sending the FREEZE_LAT_LONG / ALTITUDE / ATTIDUE events for that object. I think the FSX physics loop happens at some sparse rate (4HZ? 1HZ?) where it determines new velocity and accelerations, but it's drawn more frequently of course, and I think the drawing loop extrapolates positions and orientations like above, based on those stored velocity and acceleration values. If you're just updating position and orientation, I found it will keep "extrapolating" the object toward the previous position while you keep trying to move it the other way. Freezing lat/long/altitude/attitude solves that kind of stuttering, anyway.

    Other jittering can happen if you're switching between 64 bit position variables and 32 bit. FSX does store position internally as 64 bit values (double precision float). If you are calculating in 32 bits, you lose the precision when it casts back to 64 bits and objects will seem to jump instead of move more smoothly.

    Another frustrating problem with floating point underflow can happen if you're updating positions too frequently and the velocity is really small. It can be noticeable with slow taxiing aircraft like at 1 or 2 knots -- a very small time interval times very small angular velocity relative to earth underflows even the 64 bit value and it will round to 0.0 and not move at all. I don't get those problems with 60HZ position updates, but started to at 100 or 120HZ.

    I hope one of these ideas might fix your problem or give you some other ideas.
     
    Last edited: 19 Jun 2017 at 00:45
  6. 997R8V10

    997R8V10

    Joined:
    11 Aug 2016
    Messages:
    8
    Country:
    unitedstates
    kabekew, it's not really dead reckoning. The way I am currently doing it, is to induce a delay on the client side, of say 500ms. This way, the client will always have the next 5 positions from the server. Thus, the client knows exactly where it has to be in 50ms and can start stepping there. However, I think something is wrong, because it still causes a lot of overshoots, even though theoretically, it should know EXACTLY where it has to be. That's what's really getting me confused. Also, I solved the repeated simconnect errors, which was caused by passing 3pi :) into the rotation. Solved that by making sure that the value is between 0 and 2 pi for heading, and -pi and +pi for pitch and bank.

    The main problem I am having is the fact that SimConnect calls are asynchronous, and can sometimes take up to 60ms to actually come back. This causes some problems with getting exactly a 50 or 100ms sync because the time varies so greatly.
     
  7. ddawson

    ddawson Resource contributor

    Joined:
    27 Sep 2006
    Messages:
    609
    Country:
    canada
    You will probably get better results setting the client's velocity values, rather than setting position directly.
    If you know where the client is supposed to be in 50ms, you can set its speed, course and vertical speed to the values required to get it there. Because you never explicitly move the client from one position to another, you should not see any of the stuttering you are currently noticing.
     

Share This Page