Pete Dowson

Did you look at the receipt carefully? These days their operation is completely automated and the information in included in the receipt, not a separate email as it used to be. Pete

Check your receipt. Are you sure you purchased FSUIPC4 and WideFS7? Are you entering your name and email EXACTLY as shown on the receipt? 99/9% of all such reports are down to folks not spelling their name exactly the same each time. All three fields must be exactly correct! Try using cut-and-paste from the receipt, to save making such mistakes. Pete

ErPlease start Again, RESET stuff in FSUIPC, get it working in the right direction in FS!! As with all FSUIPC joystick calibrations, you really do need to get things working reasonably well in FS beforehand! FIRST thing you do is: In FS-Options-Controls-Assignments-Joystick Axes-Flaps Axis-Change Assignment, move lever, check "Reverse", press OK. Check that it is working in the right direction in FS before ever going near FSUIPC. Only THEN go to FSUIPC and calibrate. Do not REVerse twice! The FSUIPC reverse reverses the final output, which is fine for turning the device around. FS's Reverse reverses the values before FSUIPC sees them. Sorry if I misled you earlierthe FSUIPC reverse is post-calibration. Regards Pete

Version 3.50? That's VERY old! When did you purchase your registration? If in 2006 then that is the reason -- 3.53 was released on Jan 1st 2006 and is needed AT A MINIMUM for all this year's registrations. If your Keys are from before 2006 then there is something wrong with them -- the indications are that they are incorrect. Please zip up your FSUIPC.KEY file and send it to me at petedowson@btconnect.com. The currenly supported version of FSUIPC3 is 3.71, and an interim update (of the DLL only) to 3.711 will be posted here later today. Regards Pete

Bad virus program then. The ZIP is compressed with a compressed and encrypted, securely signed program inside. No virus. The codesigning absolutely prevents it being altered without telling you via the certificate. That's why these certificates cost so much money! Regards Pete

You don't mean WideFS server surely. WideServer is a DLL run inside FS. You presumably mean WideClient. The conflict won't be with WidevieW, because WidevieW needs to run in FS. You must have FS running to run WidevieW. WideClient is run on a PC where you are NOT running FS. You cannot run WideClient and FS on the same PC. You are missing the whole point of WideFS! Please read the important notes on the first page of the WideFS dpcumentation about what WideFS is. WidevieW connects multiple FS installations. wideFS connects NON-FS clients to an FS server. If you want to use external Gauge programs, just run them. They'll connect directly to FSUIPC on the FS on that PC. Though since you have FS running there you could use FS's own gauges, couldn't you? Regards Pete

That's a message from Squawkbox, not from FSUIPC, so I have no idea what it is checking and finding wanting. You'll need to ask them I think. In FS9 or FSX? Is it in the modules folder? Is there a Log? If so, does it say anything interesting? Pete

Not sure why you have one of those in any case. the whole purpose of me paying for a proper certificate is so you can check the option to trust all software from me. The trusted status then gets lodged into Windows (inspectable via Internet Explorer, and you never get any more security prompts on updates. You didn't find Simconnect.MSI then? Is yours a Standard or Deluxe edition? It would be quicker to opt fro the Repair first in any case -- find that Simconnect folder in the Windows SxS system and delete it, then run the FSX installer and select repair somewhere. Regards Pete

There's a freeware one called MixW comEmul which I include in the GPSout ZIP and in the downloads section above. Not sure why that should be. All I know is that COM1 and COM2 never appear to be available on any motherboard BIOS's, whether or not they actually have any incorporated. I think most have headers for them, though, and the chipsets support them even if they aren't brought to header pins. Regards Pete

That doesn't sound right. I'm think I get PortMon monitoring on virtual ports. I'm not sure how you got virtual ports COM1 and COM2. Those are usually system-reserved, for motherboard COM ports (even if there aren't any there). It's to do with fixed BIOS addressing for theo ld hardware COM1/2 ports. On most of my PCs I'm usually lucky to get virtual ports lower than COM7 or 8 -- the USB ports reserve some of them too! Regards Pete

According to the SimConnect dox, that goes in the same folder as your FS saved Flight files, as already discussed. The reasons I suggested trying some other folder names was to see if we could tie down a SimConnect bug -- as it obviously wasn't obeying the INI when you put it in the right place. But this is a Microsoft problem, not yours, so if it confuses you please don't bother to try to help them. Just report that it doesn't work and let them figure it out. I just thought we might find a work-around, but it isn't looking very likely. You expect to see it wherever you directed it in the SimConnect INI file. It isn't magic. To keep the FSUIPC4 log and SimConnect log together I always suggest directing it to the FSX modules folder. But you can put any path you like in, and any filename. Er, this question is related to the last. The path in the SimConnect INI is the path (AND filename) for the Log. If this is so confusing, forget the Log. Try the Console option if you like, but otherwise forget all about it and report the whole mess to Microsoft. Obviously they have even more problems with SimConnect on a non-English install of XP than they do on the US/UK install! :-( Regards Pete

and presumably "D:\Flight Simulator X" is where your FSX is? If that is where the Flight files are saved, then, yes, that would be correct. wouldn't the path then be something like "C:\Eigene Dateien\Flight Simulator X Dateien"? Hmmm. Strange. It sounds like Simconnect isn't runningbut then I don't know how the DLL would return a successful indication to FSUIPC4's Open. In fact if Simconnect isn't running then FSUIPC4 wouldn't even be loaded. Just to be sure it isn't just the file being misplaced because of the different folder naming, you could try setting "Console=Yes" in that INI file instead. It should make FSX open a Window displaying the live logging. You may need to run FSX in Windowed mode to see it. If that doesn't work, then certainly Simconnect isn't seeing the INI file. Possibly (but unlikely i would have thought) it actually looks in "My Documents\Flight Simulator X Files" explicitly, so it might be worth temporarily creating such a folder and putting the INI in there. If your FS files folder is NOT named 2flight simulator X Files" possibly tring "Eigene Dateien\Flight simulator X Files" too? No, becasue it is seeing an OK return from the Open,and in any case that wouldn't explain the missing Log file. that's possible I suppose, though in all the other cases like that it has stopped Simconnect even running, which doesn't see to apply here -- you seem to have little bits running. However, if you can find the Simconnect.INI file on the DVDs and execute that, you should be able to force a good install. OI know it's available on the Deluxe set, in the SDK part. alternatively you could try to do a repair. From another source (Jason Jacobs in the FSX Forum) there's this hint: On your last: "FSX is installed on the D: drive, while the my documents folder is on the C: drive", no, that cannot be a problem. On one of my PCs I have FSX on the G: drive, and My Documents on the I: drive, with WinXP on the C: drive and I used to have Win2K Pro on the D: drive too (but that's gone now. I needed the space! ;-) ) No, because it is Simconnect which loads FSUIPC4. No, it doesn't use Simconnect. It does install the Microsoft traffic explorer DLL which is from the FSX SDK, and that is loaded by Simconnect, but it doesn't use it except for loading. Well, it must be at least partly installed and partly working, or those DLLs wouldn't be loaded at all. The Logging was supposed to tell us more and maybe which. Try the simconnect CONSOLE logging, try the other locations for the INI, try the Simconnect.MSI or if not found the repair, and lastly try a complete re-installation. Then please report all this to tell_fs@microsoft.com. Regards Pete

It's going to be a process of elimination then -- commenting out different parts of what your program does to FS till you find the culprit. I caould only help by seeing what you WRITE to in FSUIPC offsets. Possibly you are writing to some undocumented and unknown place in FS, maybe a wrong offset or more likely a wrong length. I did suggest such a thing earlier on if you read back. Use the FSUIPC IPC Write logging and check each write against the offsets list. It would be nothing to do with any fonts your program uses. The displays in FS are graphics fonts generated for use in Direct3D modes. If it only happens when your program is running it is pretty sure to be because you are writing to someplace in FS you shouldn't be. Regards Pete

You evidently forgot to calibrate the extremes, then -- you need to calibrate both ends with a degree of "play" (to allow for variations). AFTER having established the complete range, and got it working correctly 100% of the time, only then do you want to start doing the interim detente positions. Seems like you are trying to "divide the cake" without first knowing its size! That should have been Reversed to start with then. You can reverse levers either in the FS assignments, or in FSUIPC. Just don't do it in both, else it will reverse twice and come out backwards again! Unfortunately you needed to do that BEFORE calibrating detentes. Your best bet now is to clear it all and start again. Calibrate the lever as a normal un-detented lever, make sure it works the correct way around and you can reach both extremes consistently (ALWAYS leave a little leeway each end to be sure). This is all documented, step by step. THEN set the detentes. Pete

When did you first notice this? You say "every version since 3.70", but I've only just published 3.71 which is the first official release since 3.70. If you mean you've been downloading and testing interim TEST beta versions from here, and not even bothering to report any problems, how do you expect me to cope? The whole point of pre-releasing updates is to get feedback! It's rather late now. I won't be able to work much on the FS2004 version for a while. There's absolutely nothing I can do in any case without information. First, yes, you do need to eliminate SB3 from the equation. If it doesn't occur without that, or some other add-on, then it's the interaction between that add-on and FSUIPC which needs looking at. Perhaps the SB3 code is making some assumption about something which has changed now. I don't know. I need also to know WHEN it changed: 3.701, 3.702, 3.703, .... which? Any logs? If the crashes are actually IN FSUIPC, then they are trapped and FSUIPC logs all the details. If not then the crash will be elsewhere -- again, possibly SB3. :-( Pete

I've never managed to get anything working with my iPaq either. No idea how to make it work. I didn't know PocketFMS were giving official instructions even. I'm not sure how even to check USB ports. For a regular serial port I would advise you to download PortMon from http://www.sysinternals.com, run that before all the above, and check that regular output is appearing. But I'm not certain that PortMon deals with things not even named "COMx". Worth a try though. Oh, you are suspicious of it being a specific problem with SimConnect? Why? Have you had this working with FS2004 and the separate GPSout module? Even if Simconnect data updates weren't arriving you would simply get the same position being sent all the time. However, to check this, go into the FSUIPC4 options, Logging page, and use the Monitoring facilities to monitor a typically changing value there -- e.g. offset 02B6 as type U16. Set the option for FS display and it will show the Ground Speed (in metres/sec) on the screen. If that changes as you fly, then Simconnect data is okay. In that case it will be something between FS and the USB port. Regards Pete

Not sure why PM's program is seeing a data rate of only 11 when the FS rate is 24 and: The WideFS frame rate AVERAGES 23, which is excellent for FSX. I would be suspicious of the balance in the PM program between its video updating (90 fps?) and its perceived data changes (11 fps). Why on Earth is it updating the video screen 8 times more often than the data which it is displaying is seen changing (by it)? You need to use the PM support channels to find out how to balance that a bit better I think. It looks like it is spending so much time re-drawing the same data that it isn't reading the incoming changes fast enough. None at all with WideFS. Over to PM now I think. Regards Pete

What has the FSUIPC offset 0810 to do with it? Are you writing a program to interface to FSUIPC? If so, just write 1 to 0810 to ARM, write 0 to disarm. Your program will have to detect the switch going off to on, and on to off, and take the appropriate action. "Signal". Sorry, that is not an appropriate term to understand in this context. What is a "signal" to a piece of software? If the switch is recognised, through the Windows joystick interface, as a "button", then you can program it in FSUIPC's Buttons facilities. If you look you will see the you can program the "Press" separately from the "Release" of a button. Did you look? A toggle switch, such as the one you describe, is effectively "pressed" when you switch it from off-to-on. Program that to set Autothrottle Arm. When you switch it from "On" to "Off" that is like releasing the button. Program that for Autothrottle disarm. Now, as it happens, FS only provides a TOGGLE control for Autothrottle, so effectively you have to program both press and release to use the SAME FS control, "Autothrottle Arm". Then then the only thing to be sure of is to synchronize the switch with the state of the A/T Arm switch in FS. Once you''ve done that it should stay in sync. The alternative is to use the FSUIPC added control "Offset Dword Set". Assign that with offset x0810 with a parameter of 1 on press and 0 on release. No, of course not. You are only changing one condition. FSUIPC recognises off-to-on as Press and on-to-off as Release! Didn't you notice the facilities for both settings in the options? They are actually documented too! Pete

Problem is that this only exists on the Deluxe Edition! :-( Pete

Ah, that's just my "EXTRAS" client. There are 7 other client PCs, running: PM MCP PM CDU PM RCDU PM PFD Pilot PM PFD CoPilot PM PFC Eicas Jeppesen FliteMap feeding off GPSout via WideFS and MixW. No. the same data is used by all clients wanting it. Wideclient maintains an "image" of FSUIPC's data, but only the combined total of the data reqested by the client programs. There is a discussion about that in the documentation for WideFs. But then those programs are causing lots of process switching, which WideServer doesn't do AT ALL! I think you'll find WideServer is more efficient! ;-) Regards Pete

Sorry, until I can find the time to totally re-write the jostick stuff in FSUIPC (and WideClient) to use DirectInput instead of the far simpler (and faster I think) basic Windows joystick API, there's no way it can see that other axis at all. Ah, if you can assign it to some other, unused axis function, in FS, then you can use the "RudderTrimcontrol" facility in FSUIPC4's INI to tell FSUIPC4 which control to "steal" and use for Rudder Trim. Here is the applicable section from the FSUIPC3 Advanced User's Guide. I think I missed much of this out in the FSUIPC4 edition as I thought it wouldn't be needed now: Looks like I should consider adding some of this documentation back, for controls with 7 or more axes such as yours? The FSX controls list is installed in your FSX modules folder. Regards Pete

I don't know if anyone has tried to reach any limit. There's no limit built in. I suspect the main factors would be other resources on that PC that they share, like video drivers, processing, whatever. If most of them don't do much most of the time I would have thought they could be innumerable! ;-). There may come a point where one or more of the programs are hogging the interface to WideClient and therefore making the others stall or run jerkily. I've seen that happen with the Project magenta Glass cockpit programs (PFD.EXE), but there are parameters in the INI files for those programs to make them cooperate better. That's totally dependent on how much free time FS is leaving you for other programs. On a dual core or X2 PC I should think you could fill up the lesser used half before impinging greatly on FS, provided none of them used the video drivers much. Only 4? Phew, that's chicken feed! ;-) I have one client PC on which I run: FSRealTime SA_WXR ActiveSky Radar Contact PMsystems PMsounds AIsmooth and they all run fine. I have no extra programs on my FS PC. It really does depend so much on what they do and what the PCs are. In general I would say keep them all on the client, but only trying things will really answer your questions. Regards Pete

I'm sorry, then. I'm out of my depth. I do not really understand why you are using FSUIPC for joystick calibration if the calibration is effectively doing nothing (just stretching the values by the look of it -- something which should be done by Windows calibrations in any case, if you did it properly there). Just press the "Reset" buttons on each axis in FSUIPC and allow the values to go directly through. I am lost herethere's no "timing" issues in FSUIPC4 itself -- if it is asked to calibrate an axis it intercepts the value, modifies it and sends it on. Unless you engage the "filter" option (where timed samples are taken and computed values sent on), there is no timing coming into it. Or are you thinking of the build-up of delays reported by several folks, which appears to be related to the TCP/IP processing in SimConnect, the one I warn about in my Read-Me? If it is this, then it sould be occurring whether or not you calibrate in FSUIPC -- so that would be a good test. If you still have problems with FSUIPC not calibrating, then, until we get a solution from Microsoft, I'm afraid the only thing you may be able to do is to tell FSUIPC to stop intercepting axes altogether (NoAxisIntercepts=Yes in the [General] section of FSUIPC4.INI). Unless, that is, you can manage to eliminate the cause of the delays, which must be down to some security or privacy hooks in the TCP/IP stack (probably still there even with software disabled). Altenatively, could there be something wrong with the saved flight instead? Try renaming it before loading FSX, to stop it loading by default. Then make yourself a new one. Oh, one other thing. Please use the Axis logging facilities (Logging options page, left-hand side) to see what values are being used, and when. Maybe there will be a clue there. You should be able to understand the Log well enough. If you also want to see the Events transmitted on to SimConnect, for comparison, then you will need to add these lines to the [General] section of FSUIPC4.INI before loading FSX: Debug=Please LogExtras=16 The number in "LogExtras" can be adjusted in the Logging options once "Debug=Please" is present. Try to keep tests with such logging short, else you will be rather swamped with the amount of information. Concentrate on one axis at a time. Regards Pete

Thanks. Odd that -- no matter what I did it insisted on including the '.' in the link. I've had to make it an unterminated sentence! Pete

Erall FSUIPC clients have to be on the same PC as FS in any case, so they are in the same workgroup by definition. None of the SimConnect TCP/IP blocking problems I list in the read-me are anything to do with WideFS. Pretty much anything that blocks network traffic will obviously be a problem for stuff on networks. I don't know much about all this "workgroup" business. I always thought ALL computers you wanted to talk to each other needed to be on the same workgroup -- else what is the point of them? All mine have always been on the same workgroup. Tell me why you'd expect separate workgroups to be able to freely exchange data please. If they can, why have separate workgroups? Maybe if I understood that I could write about it. As far as WideFS is concerned I think I assumed that if your computers could talk to each other they MUST be on the same workgroup (as well as on the same IP subnet, for TCP/IP protocols anyway). Regards Pete