Pete Dowson

Glad you got it sorted. Worrying though that we don't know what the problem was. Thanks for letting me know. Pete

That seems okay. I just remembered about one other user who had a problem with an old Game Port type joystick driver, which was causing FSUIPC to hang. but in his case it was only when he went into the FSUIPC "buttons" or "joystick calibrations" options. Just in case it is related to button scanning, could you edit the FSUIPC.INI file, and add this line into the [buttons] section (add the [buttons] line as well if you have none): PollInterval=0 Then try running FS again. I'll keep thinking. Meanwhile, I ask again, is there an FSUIPC Log file produced at all? If so is there anything in it? Regards Pete

Okay. The log files confirm that it is definitely the Key which FSUIPC does not like. But I cannot understand why, when the KEY data you sent to me before works fine here, and the Key is okay according to all other checks. This is a real puzzle. I may have to add more code to log details of what is going on differently in your system to all the others which work fine. But first, we can try two experiments. First could you again remove the KEY file and register, this time, only WideFS. Do exactly the same tests (don't use WideFS, just run SB3 locally -- if FSUIPC doesn't like the WideFS key either, the problem will remain. Then I can try sending you a different FSUIPC Key to try. Even if that worked, which seems a little unlikely as the first works okay here, I'd need to try to get to the bottom of this mystery. Regards Pete

Eryou mean you uninstalled and re-installed FS completely? did you delete the file areas FS uninstall does not, like add-ons, flights, and so on? Did you load FS with them set as default, though? If the corrupt WX file is loaded by FS, and not used, it can still wreck thiings. Best test is to delete or rename the FS9.CFG file. did you try that? Don't send me any DLLs. If you completely uninstalled FS and re-installed it, the ONLY DLLs there will be those of FS itself, and of course FSUIPC. Strange, yes, but it doesn't explain anything at all I'm afraid. I think I need more information. Version of Windows? Other things added? Pete

This really does nearly mean the registration is in error, which I don't understand because it is fine here. SOMETHING is mucking up the checking procedures somehow. I have never met such a problem before. I am really not sure how to proceed at present. Okay. I'll look at them next. But I am very worriednothing at all like this has happened before. It is acting as if the key is not valid, but it works fine here. I cannot imagine what is so different there. The same key-checking has been going on now for 3.5 years with no similar problems. It is very strange. I may have to start adding extra logging to see what is going on. It could take some time. Meanwhile, can you please tell me more about your system -- what Windows version, especially. Oh, one other thing. You said, earlier: Can you recall what version it was you had in September? Would it have been 3.70? It would still be a puzzle as the only difference between 3.70 and 3.71 in terms of registrations is that there is no need for Application Registration in 3.71 -- the checks are removed. User registration ihas not changed since 3.01. Regards Pete

FSUIPC has always counted from 0. The button numbers are actually bit numbers in a 32-bit DWORD supplied by the Windows API for joysticks. Bit 0 is the least signifcant bit and gives me button number 0, and so on up to a maximum of 31 for the top bit. The button number is actually used to produce a mask to test for the bit to change, so it must accord to the bit being seen from Windows. No, it isn't your system, and it won't cause any problems whatsoever as it is just an identity used to relate a button indication to some action in FSUIPC. I could have called them after characters in Alice in Wonderland (button TweedleDee and TweedleDum, for example ), but it would have taken more space. I thought numbers would be okay! :-( It is probably repeating -- "G" is a Gear toggle. Why convert buttons to keypresses which are then assigned in FS to FS controls? You never need to use any key presses for such things -- look down the list of FS controls and assign it directly! Please do peruse the documentation provided. It is all explained in there. Why on Earth would you want to? It is totally irrelevant. Just program whatever buttons you want, then go fly. Why worry about the numbers? No of course not!!! Use one or the other, not both! If you are assigning them in both places you wil get double actions!! No wonder your Gear button doesn't work! :-( I really don't know why you are using FSUIPC for button assignments, but a light perusal of the relevant sections of the documentation might help if you intend to. For the sorts of things you are talking about, what is wrong with FS assignments anyway? Regards Pete

What screen is showing at the time? How long does the hard disk operate before it appears to hang? Is an FSUIPC.LOG file made, with the correct timestamp, in the FS Modules folder? FSUIPC isn't actually doing anything until some time after FS loads, so I can only think you have a corrupted copy. There have never been any reports of FSUIPC managing to cause FS to hang during loading. Could you try downloading 3.715 from the "Other downloads" Announcement above and using that, please? Let me know. If it is still the same, try running FS without FSUIPC, but switch FS to Windowed mode instead of full screen (ALT+ENTER). Then close, reinsert the FSUIPC.DLL, and run FS again. Maybe there is a Window appearing which cannot be seen in full screen mode? After that, I would need to know what FSUIPC-using add-ons you might have. Possibly one of the Gauges in your default flight is causing a problem when it loads. To check this, again run FS without FSUIPC and select a default flight using only default aircraft, no extra gauges. Make sure it is set as default, then close FS, restore FSUIPC, and run FS again. It may even be a couupted weather file (WX) associated with your default flight. So you could, instead, try deleting that. You could also get the same effect as either of the above, as a test, by temporarily renaming your FS9.CFG file so that FS makes a fresh copy with default settings. If it is still a problem, I need to know what additional DLLs are installed in the Modules folder -- maybe there is some conflict with another add-in program. But let's check the other things first. Regards Pete

Okay. I couldn't sleep so I looked at your log. All these values are of course minute1 degree drift would be about 182. FSInterrogate should write 2 bytes for a 16 bit value. How are you doing the writing? FSI2 has about three ways of doing it. Or maybe it is being clever and not writing bytes after the first if they are the same -- but that would be wrong. No, it can't do that else a lot of things won't work. It doesn't here .... The "default" error seems to be around 3. Or maybe that's just because that's what is stored in the Flight file. sorry, I don't know. It that actually a problem? Can you actually measure that on the gauge? It would be about 0.19 degree Yes, this is my error. I currently do try to write directly to the FS offset, which doesn't work. I'll change that so where you read is the FS offset and where you write is the place in FSUIPC which I then use to compute the parameter to use in the GYRO DRIFT SET control -- that's the only way I have of altering this. Note that the GYRO DRIFT SET control takes only degrees as a parameter, and it is the DIFFERENCE between the current drift and the required drift I need to send. The current drift is 34, you need 51, so I send 17 converted to degrees -- which is 0. So nothing changes. Yes, this is because I can only send increments in degrees and 17 is way too small. All my tests have been with much larger numbers, which seem to work okay. Are you really concerned with adjustments of less than 1/10th of a degree (which is what 17 is)? I can see a misunderstanding, but what is actually the real problem? If you ensure a minimum change of 1 degree then you should be fine. Do you need higher accuracy? I really don't know of any way of getting directly at the obviously more accurate value I am able to read back. Regards Pete

No, the problem is (was) a bug in Radar Contact and is to do with hot-key assignments. Both use FSUIPC's facilities for detecting keypresses on the FS PC, no matter where they are running. Things are okay if RC is running first, as it allocates the first few key slots, but it goes wrong if something else has already started using them. It assigns the keys it needs properly, but references them afterwards as if they were the first batch. I though JD had fixed that by now. It's been around ofr quirte some time. I'm not aware of any other problems between them. Regards Pete

What version of FSUIPC? What version of WideFS? What Windows operating system? Any log files? So let me get this right. SB3 has never ever worked whether on the FS PC or on a Client PC, and it doesn't make any difference whether FSUIPC or WideFS is registered? Is this correct? If so, are you sure that it isn't something more to do with Multiplayer, or some part of SB3 wrong or missing? Why do you think it is the FSUIPC connection in all these circumstances? Run SB3 on the FS PC, beforehand enabling IPC read and write logging in FSUIPC's logging page. Try to do this with no other FSUIPC using add-ons such as PMDG. Since you say it is the same on the FS PC, let's concentrate on that first, worry about WideFS later. Even remove the WideFS key but leave the FSUIPC key in the KEY file. Pete

What does "don't answear" mean please? Can you describe what happens in rather more words? Please also tell me the VERSION number of FSUIPC.DLL you are using -- right click on it, select Properties then Version. Pete

For FSUIPC4 (FSX) there will be a list of FSX controls installed in your FSX Modules folder. For FSUIPC3 the list is a document included in the FSUIPC.ZIP file. It is called (possibly obscurely? :-) ) "List of FS2004 Controls.pdf". For earlier versions of FS you will find lists on http://www.schiratti.com/dowson Panning controls are FS controls used to pan the view in VC mode. They tend to have the word "PAN" in the name. Just do a search. The AXIS controls, which will be akin to what TrackIR is using, are AXIS_PAN_HEADING, AXIS_PAN_PITCH and AXIS_PAN_TILT. Axis controls need a 32-bit parameter too, generally in the range -16384 to +16384, corresponding to the reading from a calibrated joystick. Incremental controls include PAN_DOWN, PAN_LEFT, PAN_LEFT_DOWN etc . They don't need a parameter. Offset 3110 is where you write the Control number, given in the Lists, offset 3114 is where you write the parameter if one is needed. They must either be written together, as 8 bytes using an array of two 32-bit values (DWORDs), or you need to write the parameter first. The incremental controls don't need a parameter. The controls are assignable in FSUIPC's "Buttons" and "Keys" sections, so you could experiment first, see precisely what they do. There are also some EYEPOINT_controls, all incremental (no parameters). These may also relate to what you want to do, but I'm afraid I've really no idea about those. They are relatively new (in the history of FS). If you are only concerned with FSX then you will find the SimConnect interface offers greater direct control with actual camera settings with 6 degrees of freedom in structures. I believe the FSX version of TrackIR uses those. You would need the Deluxe version of FSX and install the Simconnect SDK. You don't need FSUIPC for that method. That's about all I can tell you I'm afraid. Regards Pete

Okay. Thanks! Pete

Good. Yes. It looks like something is keeping SimConnect from sending me data for several seconds initially. So I re-connect. Then two repeated re-connects occur because I think I don't allow enough time after re-connecting. Hopefully the changes I am making to the timings will get rid of both of those symptoms. Thanks, Pete

Okay. Thank you. Pete

Okay. Thank you. I tested your keys and they are fine. I even registered myself as you with your keys in FS2004, and everything worked okay too. The only differences, I think, between your setup and mine are: 1. I am using FSUIPC 3.715 2. I am using an English or US version of FS and WinXP. I can't really see any reason for (2) to have any different effect in this matter, as there are many users with non-English versions of both or either of FS and Windows. Can you please re-test with FSUIPC 3.715, available in the Downloads announcement above, and let me know? If that still gives a problem I will start asking you to switch on a variety of different special logging options, but this will then take some time. I have no other reports at present like yours. Regards Pete

No, there's been no change and nothing to corrupt. I can read the version number directly in FSUIPC - it's 3.71 I'll do so.... Please include a complete FSUIPC.LOG file as well -- from start to FS closedown. Regards Pete

Well, it should certainly work, but the title must match exactly -- there's probably some slight difference you made. In any case, there is a much better way. Check this part of the Advanced User's document: If I were you, I'd delete all the extra copies you made, change the name in the originals to, say "737" (or maybe "PMDG 737" is that will cover them all), and set ShortAircraftNameOk=Substring. Try searching on the supplied documents. I'm sure you'd have found it then! ;-). Regards Pete

Well, I do it by copying the whole Panel folder, within the Aircraft part, and naming the new one "Panel.none". THEN I delete all the parts from that PANEL.CFG that I don't wantmore about this below. After all, some bits are to do with views, and you will probably still want those. Then, finally, I edit the Aircraft.CFG file, and change the line(s) "Panel=" to "Panel=None". This makes it select the Panel.none folder instead of the regular one. For more flexibility, I actually create another [fltsim.n] entry first, in numeric sequence, and give the new one a new title, including "(no panel)" somethere in that title. then you can still select all the original aircraft, or the one with no panel. Here's my Panel.CFG file for the PMDG 737. I think this is derived from one made for FS2004 by Steve Reyling (check the Project Magenta downloads page, right near bottom left). Regards Pete [Views] VIEW_FORWARD_WINDOWS=MAIN_PANEL VIEW_FORWARD_DIR=-2.25, 0.0, 0.0 VIEW_FORWARD_ZOOM=0.50 VIEW_FORWARD_RIGHT_DIR=-2.25, 0.0, 45.0 VIEW_FORWARD_RIGHT_WINDOWS=30 VIEW_FORWARD_RIGHT_ZOOM=0.50 VIEW_RIGHT_DIR=-2.25, 0.0, 90.0 VIEW_RIGHT_WINDOWS=31 VIEW_RIGHT_ZOOM=0.50 VIEW_REAR_RIGHT_DIR=-2.25, 0.0, 135.0 VIEW_REAR_RIGHT_WINDOWS=32 VIEW_REAR_RIGHT_ZOOM=0.50 VIEW_REAR_DIR=-2.25, 0.0, 180.0 VIEW_REAR_WINDOWS=33 VIEW_REAR_ZOOM=0.50 VIEW_REAR_LEFT_DIR=-2.25, 0.0, -135.0 VIEW_REAR_LEFT_WINDOWS=34 VIEW_REAR_LEFT_ZOOM=0.50 VIEW_LEFT_DIR=-2.25, 0.0, -90.0 VIEW_LEFT_WINDOWS=35 VIEW_LEFT_ZOOM=0.50 VIEW_FORWARD_LEFT_DIR=-2.25, 0.0, -45.0 VIEW_FORWARD_LEFT_WINDOWS=36 VIEW_FORWARD_LEFT_ZOOM=0.50 VIEW_UP_WINDOWS=37 VIEW_UP_DIR=-15.0, 0.0, 0.0 [Default View] X=0 Y=0 SIZE_X=8192 SIZE_Y=2600 [Window Titles] window00=Main Panel [Window00] visible=0 ident=MAIN_PANEL size_mm=0,0 file=main.bmp file_1024=main.bmp position=1

Hey, that is useful information! Thank you. I should put that into my WideFS documentation -- you don't mind me quoting you do you? Best Regards Pete

I have good results using a pair of those electric socket Ethernet adapters, which use the electric mains cable already in your house. I have Devolo ones. (see for example http://www.expansys.com/p.aspx?i=123925 ), but they are for UK mains. See what you can find for your country. Regards Pete

Thanks frank! Maybe you could translate back my replies? Thankyou! Aha! Problems with Actigate have been reported before. I asked the author to look into that. I really have no idea what it is doing, but possibly there is another version available, as I couldn't make it go wrong here. Could you ask via the Actigate support, please? This is a sure indication that either one of the keys is bad, or that, in fact, the version of FSUIPC you are actually using is earlier than 3.53. Please ZIP the FSUIPC.KEY file and I will check them, and double-check that your 3.71 version of FSUIPC has not been overwritten by something you have installed since. Is that two keys, one for WideFS and FSUIPC? I don't keep records here so this order and date information is no use to me. I need to see the KEY file. But be sure to ZIP the FSUIPC.KEY file, else it won't get through (KEY files look like Registry hacks). Thanks! Best Regards Pete

Thanks for the FSUIPC4 and SimConnect log files. Oddly enough, even though you say the problem occurred 1 hour into the flight, there are many problems right from the start. In fact it looks like the double FSUIPC menu entry might have been there since the 520th second, or thereabouts -- there are 4 reconnections around the startup! I find it very very odd that there is then apparently no trouble whatsoever for 3060 seconds (51 minutes). It certainly seems that something is "building up"which brings me again to this: Yes, but when are you checking these figures? Did you ever check the memory usage early in the FS session, thaen around the 1 hour into it? That was why I asked when you checked it. To look for memory leakages we need two figures at least. Anyway, apart from this: I am embarking on some changes to FSUIPC4 which probably won't help but which may tell us more. In particular I will lengthen the time-outs on re-connection following a re-connection, so that one doesn't precipitate a cascade of them. This may even "recover" from the SimConnect blockage which is certainly occurring, but it cannot avoid it in the first place. I will also make the reconnection remove the previous menu entry and close the previous connection properly -- in case the only reason for it is a very slow response. Meanwhile, I note from the logs that you have three distinct SimConnect clients running simultaneously, two of which are very heavy SimConnect users (FSUIPC4 and TractIR). Now I do have one system with both of these on, and get no problems, so I wonder about the third one you have: the one creating an "AddOn Manager X" menu entry, and called "BGLMANX.DLL". Have you tried without that? If not, could you? It appears to be located in your main FSX folder -- just temporarily changing the name will do, before loading FSX. Look out for the next Interim release of FSUIPC4, in the announcement above. I'll try and get this done by the end of this week (things are a bit slower at present, as my 92-year old father went into hospital before Christmas and I am visiting regularly, which takes several hours per day out of my working time). Regards Pete

Seems as if your wireless connection is not good. These errors: are indeed a very bad sign -- the data arriving, despite being "guaranteed" by the TCP system, is corrupted -- bytes missing, changed or (less likely) added. I too have a wireless connection from my laptop, but it works quite well. Not as fast as any wired connection, of course, but using the latest "g" type adapters with MIMO it gets better than a 10mbps wired connection, but still no where near a 110 mbps. This accords with the reviews of wireless kit I've read, which measures them as varying enormously from 10 to 30, but never anywhere near the quated 54 in practice. However, I've also found them unreliable for continuous connection, needed for stuff like music from my music server -- there's always stutters, brought on by simple things like folks walking in the room. I've returned to using wired for that -- though the electric wiring connection adapators such as those from Devolo work well too, at about 85 mbps. Well, network printing and internet browsing have no time constraints on them like flying. And ActiveSky is probably the heaviest WideFS user you can apply when it is sending all the METAR data for all the weather stations. I really think that is probably the worst candidate you could think of to run across a wireless link, unless that link is perfect. Simpler WideFS applications, akin to printing and browsing, would probably be okay. For example, driving some unessential but useful gauges or a moving map. Good timing is essential for the flight simulator link I'm afraid. I suspect, from the log, that there are plenty of TCP retries going on and that these are slowing the whole thing down even further to the point of critical timeouts. Different channels on your wireless network might help too. Sometimes one channel more than another gets interference from stuff like microwaves, teelphones, monitors, and metallic objects in general. I had no end of problems with two wireless devices only 3 feet from each other and in direct view, but half surrounded by metallic shelf supports. I suspect that signals were bouncing of these and causing severe interference. There are some freeware wireless network measuring programs around. I don't recall their names offhand, but with those you can see the varying and generally low level of your connection. They would also help you possible choose an alternative channel for the wireless connection. But even without them you could try changing channels one by one till you found one that works well. Else try upgrading to MIMO which automatically finds better routes, or look out for the new "N" wireless routers and adapters which promise better speeds and reliability. I'm sorry, but there is really nothing I could do to help with slow, poor or simply bad connections from within WideFS. If all it needed to do was exhange information and take its time about it there wouldn't be a problem. It is the real-time nature of the application which imposes the constraints. Regards Pete