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

Nor would I! Sounds good to me. (I take it to mean I'm not just wasting your time.) Disappointing, indeed. And an awkward number to work with. I would prefer something that would divide evenly into 1000 msec. 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. Does anybody really know what time it is? (Chicago) Yeah, I've certainly got my work cut out for me. 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). 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, 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. 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

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... 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. 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. 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 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. 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.

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