• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Asynchronous data problem

S

Simon853

Messages
516
Hi,
I've got an application working using FSUIPC4 that moves an aircraft and sets the virtual cockpit view direction and zoom at a rate of 20 Hz, getting its data from a UAV (unmanned aerial vehicle) control station and vehicle simulator. (I'm using FSX purely for the simulated display.)

However, FSX often appears to draw a frame halfway through receiving a message, i.e. the position or view has changed but not both, (even though I send them all through a single FSUIPC4 "Process".) This causes a graphic jitter lasting a single frame.

Pete Dowson was very helpful on his forum and explained that it's because data is being transmitted via SimConnect asynchronously, even though I'm despatching it synchronously to FSUIPC4.

So, does anyone have any ideas how I could get around this? If I were to rewrite my application using SimConnect directly, are there any tricks I could employ to stall FSX acting upon new variables until all the positional and view parameters had been updated? (I've not done any SimConnect programming as of yet, so don't really know what it's capable of.)

Thanks for any advice!

Si
 
You can define structures in SimConnect to send/receive data. The structure is sent/received in one call to SimConnect. Not sure this is the solution but it's perhaps worth a try.
 
Using SimConnect you could send all the data to FSX in one SetDataOnSimObject request and it will arrive at the same time.
From what you say it seems like FSUIPC sends separate SimConnect requests for each FSUIPC write.
 
rhysa said:
Using SimConnect you could send all the data to FSX in one SetDataOnSimObject request and it will arrive at the same time.
From what you say it seems like FSUIPC sends separate SimConnect requests for each FSUIPC write.
Click to expand...

Actually that depends. If all the data is writeable via SimVars -- i.e. via "SetDataOnSimObject" then it can be made to be in one request. I do batch them where it seems obvious that this should be done, but mostly it isn't. There are very few things that can be written via SetDataOnSimObject which are ever likely to be noticeably worse in separate calls.

In this case I think we may be talking about several things which cannot at present be controlled via SimVars writes, and thus cannot be batched in one "SetDataOnSimObject". The vast majority of things you can do via SimConnect are only possible by using TransmitClientEvent to send system events (i.e. FS controls or KEY_EVENTs).

I can of course double check this if I know the FSUIPC offsets being written in this case. But I assume they are:

0560-0583: Aircraft LLAPBH (Lat/Long/Alt/Pitch/bank/Heading) -- all of which are okay via SimVars, plus

3126 View Direction -- only settable by Events

02B2 Zoom factor -- only settable by Events

The view setting is not very good in any case, because the view direction is only usable via the standard 8 direction controls -- the facilities requested for direct control aren't provided yet. The alternative of panning is more flexible but less controllable.

I'm not sure if it is these offsets to which Si refers. If not, and if I can batch those he is using into a single structure for SetDataOnSimObject I will certainly look at doing so, but it doesn't look likely and certainly cannot be so treated if Events are involved.

More specific information please, Si?

Regards

Pete
 
Thanks Pete, and everyone else who's contributing to this.

The FSUIPC4 offsets I'm writing into are:

All the LLAPBH,
And then I'm using 0x3110, id's 66504 (vc relative heading) and id 66503 (vc relative pitch)

A little more background info:
I receive information from a simulation of a UAV aircraft running on a Linux PC. The UDP data packets arrive at a rate of 20Hz and contain all the current LLAPBH and relative camera direction information. The camera sits on the nose of the aircraft and gimbles according to operator requests on the ground, and maintains a "stare at" hold on the selected point on the ground as the aircraft moves. So as the aircraft changes lat/long etc. the camera direction, (which I translate into vc direction) is corrected to maintain the view.

Note that to save FSUIPC4's workload, I only send data that has changed at 20Hz. So for example the altitude is rarely sent unless the aircraft is actively climbing or descending. I am sending all the changed values using a single FSUIPC Process event.

The jitter is only noticeable when the (vc cockpit view) camera is zoomed in towards a point on the ground (up towards x64 zoom at a range of 2 km+), as a disparity of a small fraction of a degree (which equates to a few feet at distance) is only noticeable if those few feet fill up a large portion of the view. (Does that make sense - sorry if I'm not clear?)

Regards and thanks again for the help,

Si
 
Last edited:
Simon853 said:
The FSUIPC4 offsets I'm writing into are:

All the LLAPBH,
And then I'm using 0x3110, id's 66504 (vc relative heading) and id 66503 (vc relative pitch)
Click to expand...

The 3110 offset is used to send controls to FS. It does this via TransmitClientEvent. Each control needs a separate such call. There's no way to set the values you want to set using the SetDataOnSimObject system, so there's really no way of avoiding the possiblity of part of your set of three value types getting split by a frame change.

I receive information from a simulation of a UAV aircraft running on a Linux PC. The UDP data packets arrive at a rate of 20Hz and contain all the current LLAPBH and relative camera direction information.
Click to expand...

And what frame rate are you getting in FSX? If you could try feeding FSX at twice the frame rate FSX is achieving then the fragmentation of your inputs may occur less often. I honestly don't think you can eliminate it altogether, simply because you cannot guarantee to get all new data between frames.

Another thing to try would be to write the 3110 controls twice -- once before the LLAPBH values and again after, in the same Process call. Maybe that will make the change occur in the same frame more often. Again I can't see it ever being totally eliminated.

[LATER]

One thing has occurred to me. I could think about implementing a facility to try to synchronize my calls to SimConnect to the visual frame rate. I'd have to experiment with this, but suppose I have an offset you write to which effectively says "write all the following (in this Process call) in the next Frame". It wouldn't be simple to implement because it would mean building a queing mechanism into FSUIPC4, with all of the memory management associated with that, but compared with SimConnect's complexities (using TCP/IP etc) I don't suppose it would notice, performance-wise.

It may not work of course, depending on the latency in the SimConnect transmissions to my code (notifying me of the Visual Frame change) and the latency of my transmissions back tvia SimConnect. If those two added together approach the time for one frame, then it won't help.

Let me know if this is something you'd like me to investigate. It would need to be worthwhile, as it isn't a trivial proposition.

Regards

Pete
 
Last edited:
Pete,
Thanks for your reply.

I can command frame rates anywhere from FSX's minimum slider setting of 10 fps up to over 60. (I have a Core2Quad @ 2.66 GHz for this, and am using photo scenery so have no autogen.) You are right in saying that lowering the rate diminishes the effect. I would like to run it at 25 Hz to match the PAL video output that I'm generating (that's fed back in to the UAV's control station for display in a window and overlaid with HUD info), but the 10 fps minimum is acceptable.

At 10 fps the jitter is markedly reduced but still very apparent. (Enough that I get hassled about it.) Considering that, if you could time the transmission to between frames, that would be fantastic. I realise though that you are essentially a dedicated hobbyist, and I am using this for commercial purposes, so if it were something you would require paying for then please let me know and I can see if I can get funding for it. Or if we would then require an FSUIPC application licence (as opposed to the single user licence which I have paid for at the moment - I'm the only one using it) then again let me know, PM me if you like. I'm just the programmer and not someone who makes financial decisions, but I have influence. I suspect it might be something we would willingly pay for if it could be proved to work first.

(BTW - we have no intention to supply FSX and FSUIPC as part of a commercial product. Our product is the UAV control system, and we just use FSX and FSUIPC to demonstrate it in the absence of an aircraft.)

Sending the view commands twice is something I hadn't considered, and can try reasonably quickly. So I shall let you know soon if that helped.

Regards,

Simon

EDIT: I've implemented the change to send the view params twice (once before the aircraft params and again after) in the same Process call, and it has reduced the jittering slightly, by about 30%.
 
Last edited:
Simon853 said:
I can command frame rates anywhere from FSX's minimum slider setting of 10 fps up to over 60. (I have a Core2Quad @ 2.66 GHz for this, and am using photo scenery so have no autogen.) You are right in saying that lowering the rate diminishes the effect.
Click to expand...

The higher the FS frame rate, obviously the more likely your multi-part request will be split between frames.

if you could time the transmission to between frames, that would be fantastic.
Click to expand...

As I said, I still don't know if the latency in SimConnect would mess even that up, but it would be more likely to work at lower FS frames rates than higher ones. Other difficulties could be due to variations in the loading on the PC, but with a quad core PC you should be okay with your other processes. If nothing else is using TCP/IP protocols (no Networking?) then hopefully any latency there might be should be consistent. If it is then possibly an adjustable offset timing from the frame notification would help -- to place the change in the middle of the following frame, for instance, should it not be possible, given latenciers, to make it in time for the current one..

I realise though that you are essentially a dedicated hobbyist, and I am using this for commercial purposes, so if it were something you would require paying for then please let me know and I can see if I can get funding for it. Or if we would then require an FSUIPC application licence (as opposed to the single user licence which I have paid for at the moment - I'm the only one using it) then again let me know
Click to expand...

Well, any commercial use should be by agreement, with an appropriate royalty (if it is sold) or a one-off fee when merely installed in a commercial venture. Yours sounds like the latter.

Please, write to me at petedowson@btconnect.com, reminding me of what I have suggested here, and I'll do some investigations first. I can file an email into my Pending list, which wil work better than me trying to refer to this thread.

Regards

Pete
 
You must log in or register to reply here.
Back
Top