Attempting to calculate groundspeed with lat/long/time

[skydragon]

Greetings,

I am new to the forums and to using FSUIPC, so please bear with me. I've looked around a bit but have been unable to find a solution to my problem.

I am using FSUIPC 4.53 with FSX SP2. I am connecting (to FSX via FSUIPC) an external application that I am writing. The application is (among other things) calculating ground speed of the aircraft by using the basic Rate=Dist/Time equation.

The problem is that I am seeing jumps in my calc'd GS. I am trying to figure out if I am doing something wrong, or if I am facing a limitation of FSUIPC (or FSX).

In general, here's what I'm doing:

start loop

FSUIPC_Read: 0x0560 = latitude, 0x0568 = longitude, 0x04A8 = timestamp

convert read values to human units

calculate delta values (lat, lon, time) from last iteration

groundspeed = distance traveled / elapsed time

save values from this iteration

sleep for a bit

end loop

I've been comparing the resulting calculated GS to the value I get from FSUIPC at 0x02B4. The numbers don't match up (although they are in the same ballpark), which is moderately annoying/confusing. But what really is a potential show stopper is the jumpiness of my GS. EG, flying at 250 kts I am seeing calculated values of roughly 235 to 265 knots (sometimes even more).

Hopefully, some light can be shed on this situation.

Thanks,

Sky

[Pete Dowson]

I am using FSUIPC 4.53 with FSX SP2. I am connecting (to FSX via FSUIPC) an external application that I am writing. The application is (among other things) calculating ground speed of the aircraft by using the basic Rate=Dist/Time equation.

Is this as an exercise? The Ground Speed is provided by FS and readable in an FSUIPC offset.

I've been comparing the resulting calculated GS to the value I get from FSUIPC at 0x02B4. The numbers don't match up (although they are in the same ballpark), which is moderately annoying/confusing. But what really is a potential show stopper is the jumpiness of my GS. EG, flying at 250 kts I am seeing calculated values of roughly 235 to 265 knots (sometimes even more).

What show is it stopping? Won't the provided GS do you as a substitute? It is the one FS computes after all.

The problem in FSX is that FSUIPC4 gets these values from SimConnect, which sends them via a Pipe (or via TCP/IP in FSX base or base+SP1). They arrive asynchronously. The elapsed time is read by FSUIPC from a gauge token, so it is pretty near synchronous. Depending on your "sleep" interval you will get varying values, especially with a processor under any significant load, as things work through at different times. The longer your sampling interval the more the value will be smoothed of course. The shorter, the more variable.

I'm assuming you request all the items of data in one FSUIPC_Process call. If you don't they will likely all be related to different frames, even, let alone slightly different times.

For highest accuracy what you really need is a timestamp on the SENDING of the specific data from SimConnect to FSUIPC. I did request this, and it was on the list of things "to be done" in SimConnect, but the originally planned quarterly updates to it never came about (everyone moved onto FSXI), and of course then the team was disbanded.

Regards

Pete

[skydragon]

Thanks for the reply Pete. I consider it a privilege to have a few moments your time. And I must take this opportunity to say "Thanks" for contributions to the flight sim community. Now, hopefully I can figure out how these forum quotes work...

I am using FSUIPC 4.53 with FSX SP2. I am connecting (to FSX via FSUIPC) an external application that I am writing. The application is (among other things) calculating ground speed of the aircraft by using the basic Rate=Dist/Time equation.

Is this as an exercise? The Ground Speed is provided by FS and readable in an FSUIPC offset.

Other than an exercise in futility :) the bigger picture is: I'm one in a group of participants using HLA (high level architecture). The real need here is a regular, periodic snapshot of my AC's state values. The other participants may be (make that: are almost certainly) running at a different update (or frame) rates than me. Some participants incorporate my data into their system using dead reckoning and smoothing algorithms.

So what they want is for me to tell them where (and eventually roll/pitch/yaw) I am at a corresponding when I'm there. Based on preliminary testing, my aircraft's track was jumping in their system. I've been tracing the data upstream and found the described GS anomaly (yes, as you say, as an exercise). My suspicion was just as you describe, asynchronous access of the data values.

i've been comparing the resulting calculated GS to the value I get from FSUIPC at 0x02B4. The numbers don't match up (although they are in the same ballpark), which is moderately annoying/confusing. But what really is a potential show stopper is the jumpiness of my GS. EG, flying at 250 kts I am seeing calculated values of roughly 235 to 265 knots (sometimes even more).

What show is it stopping? Won't the provided GS do you as a substitute? It is the one FS computes after all.

Yeah, I have the FSX GS value, and it is part of the data exchanged among participants. (sigh) Unfortunately, it doesn't meet the requirements of my fellow participants. As I mentioned, I really desire a timestamp that coincides with my position (state data) at that timestamp.

The problem in FSX is that FSUIPC4 gets these values from SimConnect, which sends them via a Pipe (or via TCP/IP in FSX base or base+SP1). They arrive asynchronously. The elapsed time is read by FSUIPC from a gauge token, so it is pretty near synchronous. Depending on your "sleep" interval you will get varying values, especially with a processor under any significant load, as things work through at different times. The longer your sampling interval the more the value will be smoothed of course. The shorter, the more variable.

I have been playing with the sampling interval and have noticed such behavior. Our optimal sampling rate is yet to be determined (a WAG is 10 Hz). I have been told that consistency of the time interval between updates is important, perhaps even more so than a higher frame rate.

I'm assuming you request all the items of data in one FSUIPC_Process call. If you don't they will likely all be related to different frames, even, let alone slightly different times.

I'm proud to say that I did consider that. I even went so far as to do a FSUIPC_Read of the entire chunk (~700 bytes) of data encompassing my variables in one shot and then parse out the few I needed from there.

For highest accuracy what you really need is a timestamp on the SENDING of the specific data from SimConnect to FSUIPC. I did request this, and it was on the list of things "to be done" in SimConnect, but the originally planned quarterly updates to it never came about (everyone moved onto FSXI), and of course then the team was disbanded.

Bummer. If I understand you correctly, then I may be out of luck. One of the options I was considering was switching from FSUIPC to SimConnect, but it sounds like my results would be no better there. True?

Another possibility I had considered was using the FSUIPC timestamp found at 0x3374. Based on some preliminary testing, it appears to result in more stable AC motion. Yet another thought I had was grabbing the PC system clock upon return from FSUIPC_Process. Any input you might have on these ideas would be appreciated.

A final footnote is that our ultimate platform with be using ESP. (It has been easier thusfar to do the development on FSX.) Off hand, do you know if my results there would be better?

Thanks again for your time.

[Pete Dowson]

Thanks for the reply Pete. I consider it a privilege to have a few moments your time. And I must take this opportunity to say "Thanks" for contributions to the flight sim community. Now, hopefully I can figure out how these forum quotes work...

You select the text you want to quote then use the "Quote" button above, the one after B for Bold, I for Italic and U for Underline.

As I mentioned, I really desire a timestamp that coincides with my position (state data) at that timestamp.

Actually it was I who suggested you needed that. Unfortunately there's no way you can get that from FSX.

I have been told that consistency of the time interval between updates is important, perhaps even more so than a higher frame rate.

Normally the best results would be a poll rate exactly the same as the frame rate. To get that you need to lock FS's frame rate to a value that it can always maintain. Probably less thna 20Hz, in other words. The time you read and the Lat/Lon you read would then always be correct SOMEWHERE in that frame period. you'd need to smooth the data for variationsd within it. Don't compute "instantaneous" GS, that is meaningless. I don't think even real aircraft systems would do that. You'd use a value smoothed over the last N readings, where N allows the time considered to be extended over a reasonably period, like 500 mSecs or even a second or so.

I'm proud to say that I did consider that. I even went so far as to do a FSUIPC_Read of the entire chunk (~700 bytes) of data encompassing my variables in one shot and then parse out the few I needed from there.

That actually may be slower than you think, not because of the data parcel size but the way things have to be sought and put together internally. It is usually best just to ask for what you need, only reading interim unwanted stuff when it genuinely is trivial and small, and even then you might be surprised. The overhead is only in the Process calls, not the processing inside FSUIPC of the different read/write calls.

Bummer. If I understand you correctly, then I may be out of luck. One of the options I was considering was switching from FSUIPC to SimConnect, but it sounds like my results would be no better there. True?

True, as far as I've discovered. If you find out differently please do let me know. There may be a difference, but it would be one you could deal with via FSUIPC in any case. You say you are only reading at 10Hz. This means that the time difference between the Lat/Lon you get and the elapsed Timer could often be at its maximum. If you read a LOT LOT faster but only took notice when the LAT/LON changed, I think you might achieve much better results. SimConnect only sends FSUIPC the LAT/LON when it sees it changed. If you are reading fast enough you will get it "hot off the press", and therefore more likely to tie in with the time you read.

For a local EXE program interfacing to FSUIPC you should easily be able to achieve 25 to 40 Hz without any noticeable deterioration in FSX performance. But another alternative it to write your program as a Lua plug-in, which runs as a thread in FSX's own process and could achieve much faster rates. Try, for instance, the "display Vars" Lua demo program. Play with its "sleep" constant. FSUIPC's Lua support provides luasocket and of course the full file and io libraries, or you can link, using Lua module facilities, to your own C/C++ DLLs, as you wish.

Another possibility I had considered was using the FSUIPC timestamp found at 0x3374. Based on some preliminary testing, it appears to result in more stable AC motion.

Hmm. Not sure why that would be any better. And of course it doesn't take into account FS's variable elapsed time, pausing, and sim rates.

Yet another thought I had was grabbing the PC system clock upon return from FSUIPC_Process.

That's basically the same as 3374, which is simply the last "GetTickCount" which FSUIPC executed.

A final footnote is that our ultimate platform with be using ESP. (It has been easier thusfar to do the development on FSX.) Off hand, do you know if my results there would be better?

No different. Everything is almost exactly the same.

Regards

Pete

[Pete Dowson]

You say you are only reading at 10Hz. This means that the time difference between the Lat/Lon you get and the elapsed Timer could often be at its maximum. If you read a LOT LOT faster but only took notice when the LAT/LON changed, I think you might achieve much better results. SimConnect only sends FSUIPC the LAT/LON when it sees it changed. If you are reading fast enough you will get it "hot off the press", and therefore more likely to tie in with the time you read.

After I wrote that it struck me that there's another alternative, which might still work well with your 10Hz poll rate.

What if I allocated another 8-byte offset to a copy of the elapsed timer value at the time I received the lat Lat/Lon update from SimConnect? It isn't as good as a timestamp FROM SimConnect, but it's as close as you are likely to get.

Let me know. It isn't difficult and I can add it tomorrow (Friday) if you want to try it.

Regards

Pete

[skydragon]

Pete,

Wow, lots of good info. I've been able to digest some of it. You've given me some helpful insights and some ideas for further testing (the latter will take me some time). I wanted to follow up so as not to leave you hanging.

Based on discussions with my co-conspirators, it does not appear that a locked frame rate will be an option (but I'll keep it in my back pocket for now). Also, I tried to get a better WAG on the poll rate: the current consensus is to try at 20 Hz, and probably go for a higher frequency as the project progresses.

You make a good point (as usual) about instantaneous GS computations. I will likely be (eventually) including a smoothing algorithm, and perhaps some dead reckoning as well (to account for the asynchronous frame vs polling rates). I've been informed that my primary HLA co-participant does almost no massaging of our data sent to them (if we appear to be flying backward in a zigzag helix with radical speed changes, they'll assume that is the case :shock: ).

Knowing a bit more about how FSUIPC processes data internally when it comes to choosing what I ask for in the Read()/Process() calls is a help -- thanks for having provided that insight.

I'm going to try poking at this problem with SimConnect and perhaps Lua (thanks for the heads up on that - I had forgotten about it), but that all may take a while.

What if I allocated another 8-byte offset to a copy of the elapsed timer value at the time I received the [last] Lat/Lon update from SimConnect?

A generous offer! If it is truly not a difficulty for you, then I would be interested in giving it a try. After having given this some thought, I would optimally want at least the six primary pieces of aircraft state data to be sync'd up with the time stamp (ie, lat/lon/alt/roll/pitch/yaw). But beggars must not be choosers! Whatever you can provide would be appreciated. My schedule over the next week is hectic with other obligations, so please do not go out of your way in getting back to me.

Best Regards,

Sky

[Pete Dowson]

What if I allocated another 8-byte offset to a copy of the elapsed timer value at the time I received the [last] Lat/Lon update from SimConnect?

A generous offer! If it is truly not a difficulty for you, then I would be interested in giving it a try. After having given this some thought, I would optimally want at least the six primary pieces of aircraft state data to be sync'd up with the time stamp (ie, lat/lon/alt/roll/pitch/yaw).

Hopefully they would all arrive at the same time. I wouldn't want to have to maintain six different timer copies. If they all change together then I should get them in one package so I'll just copy the time over then. If not then maybe I can include a set of flags to show which ones changed on that timestamp, though I'm not sure that'll do you any good if you don't catch all of the changes. I think really you should assume that those that look the same didn't change. That should work.

I'll let you know. Too late for now. I'll look at it over the weekend.

[LATER]

Okay, I was curious, so I implemented it, including the flags to show what was received. And

... it is disappointing. The granularity of the FS elapsed time is only 1/18th of a second, so it only just keeps up with an FS frame rate of 18 or less. Therefore it only changes at that rate at most no matter how often the LLAPBH values change. In fact you get exactly the same value as you get in offset 04A8 in any case.

At least I have proved that all 6 values, LLAPBH, are updated at the same time if they have changed. so having one timer is not a problem.

So, I am providing the Windows "tickcount" elapsed time instead. This is a bit better, but I don't know if it'll be good enough without smoothing or interpolation. The trouble you've then got to sort out is that it will show real elapsed time, not FS time -- FS can run faster or slower, as you know, and will pause on demand and stop when in menus, etc. You'd have to correct the time differences you measure in the new offset based on the FS differences you get from 04A8.

There's nothing else i can think of which will help I'm afraid. Try the update in any case. It will be version 4.576 in the Updates and Other Goodies Announcement at the top of the Forum, tomorrow some time. I will include Notes on the changes in the Announcement -- scroll down a bit.

Regards

Pete

[skydragon]

Hopefully they would all arrive at the same time. I wouldn't want to have to maintain six different timer copies.

Nor would I!

Okay, I was curious ...

Sounds good to me. (I take it to mean I'm not just wasting your time.)

... it is disappointing. The granularity of the FS elapsed time is only 1/18th of a second...

Disappointing, indeed. And an awkward number to work with. I would prefer something that would divide evenly into 1000 msec.

... all 6 values, LLAPBH, are updated at the same time if they have changed. so having one timer is not a problem.

Yea! :D

After playing around a bit with your new code, I did note that sometimes the bank flag is not set. Particularly this occurs when sitting (stationary) on the runway, and occasionally in straight-and-level flight. (Not a big deal -- what would I expect after all?)

I also noticed that the new timer (0x0588) freezes when I'm sitting stationary on the ground. Since part of our simulation involves ground movement (or the lack of movement :wink: ), I'll need to account for that. Oddly, the other flags are still set when I'm parked. Hmm.

... Windows "tickcount" elapsed timereal elapsed time smoothing or interpolationFS timestop when in menus, etc ...

Does anybody really know what time it is? (Chicago) Yeah, I've certainly got my work cut out for me.

Try the update in any case. It will be version [4.577]

Got it! Thanks for the fast response. I didn't expect such wonderful service (I'm embarrassed to admit).

I have as yet only had a small amount of time to experiment with your new offset values. A couple findings are noted above. I've also noticed that the 0x0588 value appears to fall into "bins" that are separated by approx 15 msec, and is somehow tied to my EXE's polling rate and the FSX frame rate that I select in the Settings menu.

The 15 msec delta jumped out at me because it was the granularity of the "clock()" value I observed in a related test program (perhaps it is only a coincidence?). I mention this in case you might be interested in pursuing the matter further (if only for your own sake). Likewise, there appears to be some potentially noticeable overhead in the sleep() call in my polling loop (perhaps you or SimConnect have similar code as well).

There's nothing else i can think of which will help I'm afraid.

Well, you've given me plenty to think of (and work on) for quite a while. I'll keep plugging away using your ideas and new offsets. Thanks again, Pete.

Regards,

Sky

[Pete Dowson]

After playing around a bit with your new code, I did note that sometimes the bank flag is not set. Particularly this occurs when sitting (stationary) on the runway, and occasionally in straight-and-level flight. (Not a big deal -- what would I expect after all?)

The flags are only set if SimConnect sends me a new value, and it won't send a new value if it was exactly (and I mean EXACTLY) the same as the previous one! Sorry, I thought that was implied. All i was saying was that if they are all changing the changed values all get provided at once, not one after the other. If they don't change you get nothing. You can see this in slew mode. No change initially. Raise the aircraft -- only the Altitude flag is set. And so on.

When you don't see a "new" value the old one is still current.

I also noticed that the new timer (0x0588) freezes when I'm sitting stationary on the ground.

The "timer" is a timestamp. It records the time of the last CHANGE to one of those 6 values. If they don't change, why on Earth would the time in 0588 be changed? You seem to miss the point of it.

Since part of our simulation involves ground movement (or the lack of movement :wink: ), I'll need to account for that. Oddly, the other flags are still set when I'm parked.

I'm sorry, but you seem to be misunderstanding something here! :-(

The FLAGS show which values CHANGED at the TIME shown in 0588. If none change subsequently, those flags and timestamp are still correct. Obviously, surely!!!

Does anybody really know what time it is? (Chicago)

25 or 6 to 4.

Yeah, I've certainly got my work cut out for me.

I think only because you seem to have missed the point of the changes.

I have as yet only had a small amount of time to experiment with your new offset values. A couple findings are noted above. I've also noticed that the 0x0588 value appears to fall into "bins" that are separated by approx 15 msec, and is somehow tied to my EXE's polling rate and the FSX frame rate that I select in the Settings menu.

It is recording the time FS changes the values, so if you have a steady frame rate then of course it should be spaced reasonably regularly! Sorry, all this seems obvious -- are you and I on the same wavelength anymore?

Ideally each packet of information from SimConnect should be timestamped, so you know the exact time the information provided was accurate. They didn't implement that. I explained it to you if I remember correctly. What I've done is the next best thing -- provided a timestamp on the arrival in FSUIPC of the packet. This will be more accurate than you reading any timer anywhere when you are polling, because your poll will hardly ever coincide with the actual arrival of data from SimConnect. It cannot, don't you see?

It isn't complicated. If it helps understand, please think "timestamp" not "timer". It is the value of a timer when a particular event occurred -- the updating of those data items.

Pete

[skydragon]

Pete,

Thanks for taking the time to explain in such detail. I had drawn some incorrect conclusions when I first started working with the changes, but I think it is sinking in now. I apologize for any frustration caused by this newbie. :oops:

I believe the new offsets will be helpful; and thanks again for your efforts.

Regards,

Sky