neorecon

Thanks for the quick response! It is greatly appreciated!

Pete, I use an ACARS system from flyingtigersgroup.org. It has always worked well with FSUIPC. Part of its features is reporting our v/s upon landing. This has worked great until recently. Before I redid my pc (upgraded to 64bit os) I was using a version of FSUIPC prior to 4.4. Now I am running the latest version, 4.417 with wideclient 6.781. Now their acars system is reporting very goofy vertical speeds. The code for the ACARS system hasn't changed, and the only new variable is that I updated to the latest FSUIPC version. For example on my two most recent flights the V/S reported in at -750351101 and 813761054. I've also asked the ACARS developer if he could let me know what fields / variables ect. he uses to calculate the VS in his program as it talks directly to your FSUIPC program. This is the call they use in their ACARS program: FSUIPC_Read($030C, 4, @(vertical_speed.t_d), dwResult); Let me know what I need to do to generate a log file for you. This seems to be happening on every flight since the update, so I can do a quick 15min flight someplace to get you the data. Thanks. Jason L.

We'll do....now go enjoy your holiday!

I don't think it is tied to the brakes, it seems I the problem returned when I went to using FSUIPC to manage the controllers (Yoke, Throttle, and pedals). I will forward this information on to microsoft, and again I appreciate your assistance. Over the weekend on the remote chance this is something Vista or driver related I'm going to do a test run on Windows XP with the exact same setup to eliminate any hardware issue on my end. Thanks again for your assistance with this!

Well as soon as I resorted back to using FSUIPC to manage my controllers I got a crash. Before I enabled them in FSUIPC I had completed several long flights with no issues. Some of the long flights included using a client PC running AI Smooth via Wide FS. I was able to reduce my 'sessions' down to two: One Global and One Local: 0.00000 SimConnect version 10.0.61259.0 0.01407 Server: Scope=global, Protocol=IPv4, Address=192.168.1.14, Port=500, MaxClients=64 0.02009 Server: Scope=local, Protocol=IPv4, Address=127.0.0.1, Port=51990, MaxClients=64 But a few seconds before landing the following occurs...and according to the logic you mentioned above, these all look to be happening to the 'local' port of simconnect, which is the one that FSUIPC connects through? < 6699.85736 [127] >>>>> EXCEPTION=2, SendID=76560, Index=0 <<<<< Unrecognized Data Received. [127, 76560] > 6699.85742 [127, 76561]TransmitClientEvent:ObjectID=23318, EventID=65731, dwData=1, GroupID=1, Flags=0 > 6699.85744 [127, 76562]TransmitClientEvent:ObjectID=23318, EventID=65869, dwData=-475, GroupID=1, Flags=0 < 6699.86371 [127] ObjectData: RequestID=14 DefineID=14 dwSize=376 < 6699.86374 [127] ObjectData: RequestID=24 DefineID=24 dwSize=96 < 6699.86398 [127] ObjectData: RequestID=14 DefineID=14 dwSize=376 < 6699.86399 [127] ObjectData: RequestID=24 DefineID=24 dwSize=96 < 6699.86421 [127] ObjectData: RequestID=14 DefineID=14 dwSize=364 < 6699.86423 [127] ObjectData: RequestID=24 DefineID=24 dwSize=96 < 6699.86449 [127] EventFrame: 0 12.710634 < 6699.88603 [127] ObjectData: RequestID=7 DefineID=7 dwSize=48 < 6699.88606 [127] ObjectData: RequestID=9 DefineID=9 dwSize=64 < 6699.88608 [127] ObjectData: RequestID=10 DefineID=10 dwSize=1432 > 6699.93905 [127, 1634739258] < 6699.93908 [127] >>>>> EXCEPTION=5, SendID=1634739258, Index=61259 <<<<> 6699.93910 [127, 1644167160] < 6699.93913 [127] >>>>> EXCEPTION=5, SendID=1644167160, Index=61259 <<<<> 6699.93914 [127, 55] < 6699.93915 [127] >>>>> EXCEPTION=5, SendID=55, Index=61259 <<<< Suggestions?

Quick update after a weekend of testing: Here's what I did: Step 1: Reinstalled FSX up to SP2, Installed FSUIPC 4.272. I did not configure FSUIPC for the CH Controllers. I flew from KMSP to PHNL (8+ Hr flight) with no issues. Step 2: Installed some of my scenery add-on's including UTX, GEX, and MyTraffic X 5.1b. Configured Traffic to 88%. Flew a flight from KMSP to PHNL again with no issues Step 3: Installed WideFS 6.76 on client computer and ran AI Smooth. Flew flight from KMSP to PHNL again with no issues. Step 4: Tonight will configure CH Controllers through FSUIPC and will fly same long haul flight again. Final Step: Add Active Sky X to the mix to have programs connecting through WideFS and SimConnect.

Took some tinkering to get it to finally configure correctly, but I have my simconnect configured as suggested IP & Pipes LOCAL and one IP GLOBAL 0.00000 SimConnect version 10.0.61259.0 0.01549 Server: Scope=global, Protocol=IPv4, Address=192.168.1.14, Port=500, MaxClients=64 0.03492 Server: Scope=local, Protocol=Pipe, Name=\\.\pipe\Microsoft Flight Simulator\SimConnect, MaxClients=64 0.04292 Server: Scope=local, Protocol=IPv4, Address=127.0.0.1, Port=59591, MaxClients=64 I'm going to try with this and also with pipe disabled as you suggested today. Hopefully one of these will get the problem resolved. Thanks again for all of your assistance.

From the top of the config: 0.00000 SimConnect version 10.0.61259.0 0.01439 Server: Scope=global, Protocol=IPv4, Address=192.168.1.14, Port=500, MaxClients=64 0.01931 Server: Scope=local, Protocol=Auto, Address=::1, Port=49942, MaxClients=64 0.03655 Server: Scope=local, Protocol=Pipe, Name=\\.\pipe\Microsoft Flight Simulator\SimConnect, MaxClients=64 0.03994 Server: Scope=local, Protocol=IPv6, Address=::1, Port=49943, MaxClients=64 0.04635 Server: Scope=local, Protocol=IPv4, Address=127.0.0.1, Port=49944, MaxClients=64 It's interesting because I did not specify IPv6 or Pipe in my simconnect.xml. It must enable them by default if it isn't specified? And from the bottom where the error occurs: < 646.47949 [128] >>>>> EXCEPTION=2, SendID=11683, Index=0 <<<<< Unrecognized Data Received. [128, 11683] > 646.47953 [128, 11684]RequestSystemState:RequestID=1, szState="Sim" < 646.48651 [128] ObjectData: RequestID=14 DefineID=14 dwSize=292 < 646.48654 [128] ObjectData: RequestID=24 DefineID=24 dwSize=96 < 646.48659 [128] ObjectData: RequestID=14 DefineID=14 dwSize=292 < 646.48662 [128] ObjectData: RequestID=24 DefineID=24 dwSize=96 < 646.48667 [128] ObjectData: RequestID=14 DefineID=14 dwSize=292 < 646.48669 [128] ObjectData: RequestID=24 DefineID=24 dwSize=96 < 646.48675 [128] ObjectData: RequestID=14 DefineID=14 dwSize=292 < 646.48677 [128] ObjectData: RequestID=24 DefineID=24 dwSize=96 < 646.48737 [128] EventFrame: 0 10.296438 < 646.50543 [128] ObjectData: RequestID=9 DefineID=9 dwSize=72 < 646.50557 [128] ObjectData: RequestID=7 DefineID=7 dwSize=48 < 646.50559 [128] ObjectData: RequestID=10 DefineID=10 dwSize=1504 > 646.56970 [128, 1778608580] < 646.56974 [128] >>>>> EXCEPTION=5, SendID=1778608580, Index=61259 <<<<> 646.56976 [128, 1800271806] < 646.56977 [128] >>>>> EXCEPTION=5, SendID=1800271806, Index=61259 <<<<> 646.56979 [128, 35652893] < 646.56980 [128] >>>>> EXCEPTION=5, SendID=35652893, Index=61259 <<<<

Sounds good. I think I may have overloaded the TCP side of things as I had removed the 'pipes' line from my simconnect.xml and was using TCP exclusively for both local and global connections. I will reconfigure from scratch and see what happens. I was rather frustrated by everything yesterday so I'm starting with a fresh install of FSX and FSUIPC and will slowly add third party add-on's and test to ensure that they will work correctly... Looks to be a fun weekend indeed. Thanks for your assistance with this issue and I will post back with my results. I'm guessing it was probably my elimination of the pipes configuration that could have caused the errors, especially if the communications were not as efficient through TCP. I'm assuming that there is alot of data that gets passed through as when I had the logging on for Simconnect, my 2 hour flight generated a rather large log file.

So would you suggest just having the SP2 SimConnect installed then and not install the SP1A and RTM versions? I've read conflicting information on this whole topic online.

Thanks Pete... I'm running an Orthos Stress test on my PC today testing out the ram and the CPU. Since this seems to only happen when I'm simming for 2+ hours I'm going to run the stress test for 3-4 and we'll see what happens. Also, do you suggest using simconnect via Named Pipes? I'm in the IT industry and I had always figured that TCP would be a better protocol to utilize. But based on your comments, it appears that I may wrong. In my Simconnect I've been utilizing IPv4 strictly, but may reconsider if you think it may help.

OK I thought everything was working ok until I did a longer flight from MSP to SLC. I had simconnect set to log and here was the place where errors started showing up: &gt; 646.47948 [128, 11683] &lt; 646.47949 [128] &gt;&gt;&gt;&gt;&gt; EXCEPTION=2, SendID=11683, Index=0 &lt;&lt;&lt;&lt;&lt; Unrecognized Data Received. [128, 11683] &gt; 646.47953 [128, 11684]RequestSystemState:RequestID=1, szState="Sim" &lt; 646.48651 [128] ObjectData: RequestID=14 DefineID=14 dwSize=292 &lt; 646.48654 [128] ObjectData: RequestID=24 DefineID=24 dwSize=96 &lt; 646.48659 [128] ObjectData: RequestID=14 DefineID=14 dwSize=292 &lt; 646.48662 [128] ObjectData: RequestID=24 DefineID=24 dwSize=96 &lt; 646.48667 [128] ObjectData: RequestID=14 DefineID=14 dwSize=292 &lt; 646.48669 [128] ObjectData: RequestID=24 DefineID=24 dwSize=96 &lt; 646.48675 [128] ObjectData: RequestID=14 DefineID=14 dwSize=292 &lt; 646.48677 [128] ObjectData: RequestID=24 DefineID=24 dwSize=96 &lt; 646.48737 [128] EventFrame: 0 10.296438 &lt; 646.50543 [128] ObjectData: RequestID=9 DefineID=9 dwSize=72 &lt; 646.50557 [128] ObjectData: RequestID=7 DefineID=7 dwSize=48 &lt; 646.50559 [128] ObjectData: RequestID=10 DefineID=10 dwSize=1504 &gt; 646.56970 [128, 1778608580] &lt; 646.56974 [128] &gt;&gt;&gt;&gt;&gt; EXCEPTION=5, SendID=1778608580, Index=61259 &lt;&lt;&lt;&lt;&gt; 646.56976 [128, 1800271806] &lt; 646.56977 [128] &gt;&gt;&gt;&gt;&gt; EXCEPTION=5, SendID=1800271806, Index=61259 &lt;&lt;&lt;&lt;&gt; 646.56979 [128, 35652893] &lt; 646.56980 [128] &gt;&gt;&gt;&gt;&gt; EXCEPTION=5, SendID=35652893, Index=61259 &lt;&lt;&lt;&lt; Does that make any sense? From what I've read it looks to mean that I have something that is trying to use a different version of Simconnect, or was writen for a different version with my PC. ASX and FTGACARS are both listed as SP2 compatible. Both of my machines have 3 installations of simconnect (as I read you should have them installed this way) Is that incorrect? Either way I'm not sure why this suddenly happened. I flew two flights earlier today KMSP-KDLH and back, and then KMSP-KEAU without any problems. Very odd to say the least. This was using your 4.27x version of the dll and the rudder/brake pedals mapped straight through to FS (not the Direct FSUIPC optioin) Also had this in the fsuipc log file: [code] 16115 Broadcasting service every 1000 mSecs 1435833 **** ERROR! Sumcheck or length fails on received socket 9168 block, len=96 (time=11941150)

Sorry about the 'latest' comment. I'll re-download tonight when I get home and try again. If everything continues to work well after a few flights I will revert back to having FSUIPC manage the rudder/breaks and see what happens.

Well I'm not sure what to tell you. I updated my video drivers and I changed how the rudder pedals were configured in FSUIPC...Instead of direct (managed by FSUIPC) I changed them to send direct to FS. So far I've finished one short hop (1hr) and am now in the middle of a return flight with no problems. Tomorrow, I'll try reconfiguring my rudder pedals back to the usual way in FSUIPC and see what happens.

Doing some more research on this. What video cards is everyone here that has this problem using? What OS? I'm running Vista Home Premium 32Bit w/ an Nvidia 8800GTS (174.74 Drivers) From browsing around this could be a video driver issue too.. so I'm going to try a few different scenarios and see if I can't narrow down what causes the crash. I did get it to crash again but it was shortly after takeoff this time, so there seems to be no pattern whatsoever. I'll let you know if I find anything out. I did apply your latest .dll update.