Pete Dowson

Yes, its the divisors which control the speed of the changes -- they set the number of increments approaching each computed target. Well, with 100 it should take 5 times as long for the computed targets to be reached -- the increments will be that much smaller. I can't really control that exactly as it has to be in-line with the FSX SIM code, not in a separate thread, and I am dependent upon SimConnect calls for synchronising. The timing is only controlled by assuming I'm being called often enough and then limiting things based on elapsed time since the last update. The evenness of the updates is then obtained by altering the increments according to how long it was since the last. You can see this in operation in the FSUIPC4.LOG if you enable the Smoothing logging. To do this add: Debug=Please LogExtras=512 to the [General] section of the INI file. The log will become pretty big, but it will log the increments it is using, as they are computed. Maybe, but it is odd consdidering it was they who most thoroughly tested my algorithms for me, and approved them. Maybe something got chasnged their end in some recent update? Has there been one? I've not purchased the thing myself (no use for it in a hardware cockpit) but I have one version they supplied for my testing only. But it is also odd that it seems fine here. but as I say, my version of the 747 may be out of date? Is there any way I can tell? Well that would be the same as FSUIPC3 wind smoothing + FS2004. Regards Pete

But 4.285 also had that same change, so FSUIPC wasn't interfering with FS's weather when ASX was running, and therefore its "suppress cloud turbulence" shouldn't have had any affect at all on ASX's options. Yes, but that wasn't relevant to the difference with FSUIPC trying to manipulate ASX's weather. So you've not actually tried or had any wind turbulence? The point is, if you look up through the thread, that folks have been saying the wind turbulence is okay, it's only the cloud turbulence with a problem. and this is where is gets silly, because they are not differentiable anywhere in my code! They are the same, the same code, the one entry point from both causes. The changes underlying the ones you see are at about 3-4 times the frame rate and the 2 knots changes, whatever, will be arrived at through many small increments (as per the parameters). When you say "changing rapidly" how do you mean? If they are slow enough to be seen on screen, they are probably as they should be. Let me play with these (in addition to trying the 4.287 build) and see if I can't conjure up a better result. Okay, but it worries me that the parameters I ended up with were the result of a lot of testing and feedback from PMDG, and they were very pleased with the end results which they said were realistic. I really would hate to mess that up for the majority for the sake of a few who seem to have problems for, so far, unknown reasons. I would like to know what is affecting the few so adversely. The fact that they see a difference in cloud vs wind turbulence is the really mysterious part. Regards Pete

Phew! That is restrictive! Thanks Pete

In that case it is almost certainly going to be your firewalls. Try disabling them both as a test. If that fixes it but you need the firewalls up then you'll need to get Wideclient and FSX permissions. Sorry, I'm not sure how to do that -- I have a router protecting my Network from the outside world and don't like firewalls stopping me talking to me! ;-) Pete

Do you have the option in FSUIPC checked to allow FSX's weather to be changed? It sounds as if you must, because otherwise it cannot inflcuence ASX's weather. This issue would be rather clearer for me if you were to first update to the current FSUIPC increment (4.287 at present, above), as this automatically suppresses FSUIPC's interference in ASX's weather when the latter is running. But the turbulence modelled by FSUIPC is identical for Cloud and Wind turbulence -- in fact it IS the exact same code. The changes are not "sudden" but spread using a Gaussian ("Normal") distribution. The maximum range of change is computed first, then random targets are computed. The targets follow a Normal distribution about the mean. Then the distance to that target is divided by a value (adjustable in the INI file) to provide an increment, and the values are changed by that increment at a frequency also adjustable in the INI file until the tasrget is attained, at which point another target is computed. This rather complex sounding system was derived from studies made by academics on how turbulence behaves, and the default parameters were tuned in cooperation with the PMDG 747 test pilot, as it was the PMDG 747 which seemed to be most sensitive to the results. The FSX turbulence was described by the 747 test pilot as rather unrealistic. In any case, the only reason I added the emulation in FSUIPC4 is that the wind smoothing removes most if not all of FSX's own turbulence. This was the same in FS2004 -- with FSUIPC's wind smoothing enabled you never ever got any turbulence. I was trying to do better in FSX, but I am starting to wish I'd never tried and left it as in FS2004. :-( Well, the 747 seems to cope reasonably well with it here except when it gets to "severe", and the effect is identical for cloud and wind turbulence (as one would expect with the same code operating it). As for "throttling" it, the parameters for this are as originally described in the release notes and now in the Advanced Users guide (see TurbulenceRate and TurbulenceDivisor). Although these are only listed under "Winds" they apply to both Cloud and Wind turbulence, as there is no difference internally -- the only difference is where the trigger comes from, a value in the Cloud parameters or in the Wind parameters (if both together the maximum of the two wins). Regards Pete

Were you assigning Axes in FSUIPC for "direct to FSUIPC calibration"? If not then I think it was a different issue, probably related to a SimConnect mis-installation. The thing in common with all these here is direct assignment. As soon as folks simply change the assignment, still in FSUIPC, to an equivalent FS control, it stops the problems. Regards Pete

Okay, yes please. I'm going at this full time as of now and need information. Could you possibly enable SimConnect logging (as described in the FSX Help announcement above), reproduce the crash, then ZIP up both the SimConnect log and the FSUIPC log and send it to me, please? Also, as I've said elsewhere here, I'm looking for a way to bypass SimConnect completely when assigning axis "direct to FSUIPC". I've a feeling that my joystick axis scanning rate may be exceeding SimConnect's "pipe" capacity and the automatic throttling which should occur is cutting in too late, after corruption. Once the data is corrupted anything can ensue. Meanwhile, there is one other thing you can try to see if it has a beneficial effect: reduce the axis polling frequency (i.e. increase the interval) so that the load on Simconnect is less. In the [Axes] section, set PollInterval=100 This quadruples the interval from 10 mSecs (100 polls per second) to 100 mSecs (only 10 per second). If this makes it too unresponsive to fly properly try 50 (20 per second) or 40 (25 per second). If this severely reduces or even eliminates the crashes/hangs, try a lower number again, say 20 (for 50 polls per second). Thanks! Regards Pete

No, that's a crash. A hang is when nothing happens and you have to forcibly close FS using the Task Manager. Could you possibly enable SimConnect logging (as described in the FSX Help announcement above), reproduce it, then ZIP up both the SimConnect log and the FSUIPC log and send it to me, please? I'm looking for a way to bypass SimConnect completely when assigning axis "direct to FSUIPC". I've a feeling that my joystick axis scanning rate may be exceeding SimConnect's "pipe" capacity and the automatic throttling which should occur is cutting in too late, after corruption. Once the data is corrupted anything can ensue. Meanwhile, there is one other thing you can try to see if it has a beneficial effect: reduce the axis polling frequency (i.e. increase the interval) so that the load on Simconnect is less. In the [Axes] section, set PollInterval=100 This quadruples the interval from 10 mSecs (100 polls per second) to 100 mSecs (only 10 per second). If this makes it too unresponsive to fly properly try 50 (20 per second) or 40 (25 per second). If this severely reduces or even eliminates the crashes/hangs, try a lower number again, say 20 (for 50 polls per second). Thanks! Regards Pete

It is under "Settings", but in the Options menu: see Settings then Controls then Assignments. Click the "Control Axes" tab and you'll see at least 5 throttle controls you can assign to, one generic one and one for each engine. The assignments system in FS should be far easier to understand than FSUIPC's as it was designed by professionals in the User Interface field, and has withstood the test of time over many FS releases. If in FS you cannot find out how to scroll down the list of controls you can assign to and select the throttle for each engine then I'm afraid FSUIPC will be a step too far for you. User Interface design isn't my strong point and it is not going to be anywhere near as easy to do as in FS. Pete

I need to see the WideServer log file from the FS PC and the WideClient log file from the client PC. That will tell all. That is a bit extreme and most certainly not advised if SimConnect is running okay. No connection for WideFS is nothing to do with SimConnect -- if the FSUIPC log shows no errors, and you have an FSUIPC menu entry in "Add-Ons" then SimConnect is fine. You'll do more damage than good messing about with SimConnect files unnecessarily. Didn't you once even think of looking at the Log files, which for all my programs is always where details of what is going on are placed? That is what they are for! I am using Vista64 Ultimate for FSX and my 8 clients are all on WinXP, and there certainly are no issues. You need to make sure the Network is working correctly first, and that you've either disabled the firewalls both ends or provided WideClient and FSX the needed permissions. It is also best if both (all) PCs are in the same Workgroup (i.e. the same named Network workgroup) -- if they aren't then you have to tell Wideclient the Server name and protocol to be used, as it will never receive the FSX PC's broadcasts. Regards Pete

These are hangs, not crashes like before? And only in missions, not free flight? I am trying to figure out some way of getting to the bottom of this, as I've been using direct assignment for everything since FSX started and cannot reproduce any problems. And I know the direct method is used by a lot of folks, so there must be something more to it than just that. some other factor. Pete

Can't you do it in FS itself? It provides the facilities too. For FSUIPC the best place to find out is in the User Guide. If you really don't want to use FS but FSUIPC instead, at least try to follow the instructions. By all means ask specific questions if you get stuck or don't understand something specifically, but i really cannot give more general instructions here that i do in the documentation, which is far more extensive and even has illustrations and simple steps! Pete

Sorry, I cannot support any such hardware directly. FSUIPC isn't a hardware driver. You need to use the driver for your phidgets board. Pete

Ah, right. 64 buttons is the directInput limit i'm aware of, so it is just using directInput I assume. FSUIPC could manage the same if I re-wrote all the button code to use DirectInput, but I fear most current users would need to reprogram their assignments. (things look different through directInput). And it is a very big job, not trivial, and something so seldom needed (very few devices ever have more than the 32 buttons I support in any case) that I really cannot justify the time involved, let alone the possible consequences in terms of reliability if it were not subjected to many months of alpha and beta testing. Regards Pete

That's okay. Sorry, no. It's going to be down to some combination of things which is causing this older SimConnect bug to activate. The log would show the details, I think. You could try a process of elimination, dropping one SimConnect component at a time. Start off with whatever you have running remotely, as that will certainly be using TCP/IP. Pete

"Any device" is far to broad a description. What you say cannot be true. I could go and build a device now, with any sort of parallel or serial interface, and unless I told the clever program how it worked, how to read it, how to interpret the signals, it could not read any buttons I connect to it. As a case in point, take the EPIC USB card -- it would most certainly not be able to read 112 of its 512 possible buttons unless it had specific code in to deal with the EPIC protocol. Perhaps you mean any standard xxxx interface device, where "xxxx" would need to be specified? Just a quick browse for "Mjoy16" in Google reveals comments like "Has anyone used the MJoy16 and the assiciated keyboard devices for their cockpit. I know I will need more than this (mainly for displays) but it looks like a great product at a great price combining 8 axis, 64 buttons, 16 toggles and 4 rotories in one USB device (and you can connect up to 4)." Now 8 axes, 64 buttons and so on is what I know as the DirectInput limit for a HID deviceare you perhaps getting to 112 by somehow adding up all these separate aspects? Even then, counting rotaries possibly as 2 each, I can only see 96 "things", not 112. Another site lists the capabilities of the MJoy16 application as follows: Main features of this MJoy16 Application C1 are: - 64 pushbuttons support - 16 double-action toggle switches support - 4 double-action rotary switches support for convenient frequency control - 1 8-position hatswitch - 2 controls mapping modes - Axes centering disabling possibility - Auto calibration - Additional support options for multiple MJoy16-C1 controllers on one computer Again, the 64 is the DirectInput limit I'm aware of. FSUIPC, of course, currently uses the standard Windows API where the limit is 32. It is possible, of course, that since I looked at DirectInput (DX8 times, for FS2004), the limits have been changed or even abolished. I really don't know. If this MJoy16 program states a specific need for a particular version that might be a clue. Regards Pete

Tried what too., exactly? You need to be more specific. You only described what happens in the FSUIPC dialogue, which is completely irrelevant. You have not once said you programmed it for the same action for both press and release, as I suggested, and nor have you stated anything about any results of doing so. If the dialogue detects the Click turning the button it sees from off to on, as you say it does, then FSUIPC, whilst running normally, will most certainly also see the "on to off". It cannot actually detect one without the other -- you will notice that it is a logical absurdity for it to be otherwise. Therefore, if you have, as you say, "tried" something, it most certainly cannot be what I suggested you try. You say "that knob works perfectly on other add-ons...", and it sounds, from what you've said, that it will work perfectly in FSUIPC. It is just that, unlike most other add-ons, FSUIPC is much more flexible, providing more options -- in this case a separate capability for switching off to that for switching on -- , and these are evidently confusing you! I'm sorry that I only do support in English, as I feel sure that the problem here must be one of communication, and perhaps English is not your natural tongue? Regards Pete

Not with EXE files. Most all email systems will filter them. This is a first -- no one else has ever not actually been able to extract the EXE from the ZIP in the 11 years of WideFS! Are you also saying you cannot see the EXE in the ZIP of WideClient (only), in the downloads announcements above? If so there is something seriously wrong -- it sounds like you have a virus checking package which is interfering severely with your downloads and removing EXE files it doesn't like. Maybe it sees part of the binary as a virus, that has been known, yet all my modules and EXEs are codesigned and guaranteed secure and free or such infections. Regards Pete

The WideClient.exe file is most certainly present in the WideFS.zip on the www.schiratti.com/dowson page (of Enrico Schiratti, not "of Pete"). I have just double-checked this myself. Maybe you are not recognising it because you have windows hiding filetypes? There is also no difference in the two WideFS 6.75 zip files presented there -- it is duplicated in both the FSX and FS2004 section precisely because there is no difference. There is also an updated WideClient available in the Downloads announcements above. Regards Pete

You said, mysteriously "I had a look at the log, but couldn't find anything that would show me any error." Doesn't the above message suggest to you that something is seriously wrong at all? Something is clobbering your FSX SimConnect -- in that log it was fine until 2526 seconds (42 minutes) into your session, so i would guess that is is something building up. I'm sorry, I've no idea what. Once FSUIPC no longer sees the regular SimConnect messages it expects, after a certain time (5 seconds with no events at all), it assumes things have gone awry and closes the connection (hence the missing Menu entry) and attempts to re-connect. As you can see from that enormous log showing umpteen repetitions of the same failure, that didn't succeed -- though it managed to re-open it never saw and results in the 5 or so seconds it then allows, on every single subsequent retry. Maybe a SimConnect log will show you what is going on (see the FSX Help announcement above). It could be some other SimConnect client somehow hogging SimConnect too much, but I’ve never seen exactly that before. There was a serious bug in the original release of SimConnect which would cause SimConnect to sieze up on certain combinations of clients, initialising in a certain order, but Microsoft did do some revisions by SP1 to work-around that 9not solved, please note -- so it could be the same thing). I remeber FSCopilot was one of the prime add-ons involved in those problems, so maybe Microsoft's work-arounds aren't working too well for you. If you do get a SimConnect log, it will be huge, so don't post it here like you did all that repetitive stuff, please. Probably best to post it with a full description of the problem to tell_fs@microsoft.com, as they will need to fix this stuff for ESP and FSXI. I can take a look as well if you like, but it isn't something I'm likely to be able to do anything about I'm afraid. Send to petedowson@btconnect.com -- ZIP it first please! Possibly FSCopilot is still written to use the RTM or SP1 version of SimConnect, in which case one possibly area of problems is memory-filling with TCP/IP queued blocks. FSUIPC uses the SP2/Acceleration version of Simconnect if available, and, by default that should be using Named Pipes instead of TCP/IP which avoids that sort of congestion. However, it is just possible that you have a SimConnect.xml file which is preventing Named Pipes being used, so perhaps I should take a look at that. For experimentation I could maybe supply a version of FSUIPC which allowed the 5-seconds-with-no-contact interval to be elongated, especially when trying to reconnect, but really if it isn't getting messages on every single FS frame (which it is "promised" by SimConnect) something is already seriously amiss -- a frame rate of 0.2 fps isn't likely I hope! Incidentally, you also said: Now neither of those add-ons use FSUIPC at all, and are entirely unrelated to anything FSUIPC does. They would have also stopped working because they too became frozen out of SimConnect. They probably do not detect this like FSUIPC does and so sit there simply not working. Regards Pete

I know the pitch and bank holds worked pretty well, but i never did get the speed control workiing that well -- it always seemed to hunt too much on the aircraft I tried it on. Some of the parameters need adjusting to suit each aircraft, separately. Why doesn't Deamfleet's 727 have autothrottle? Weren't those models so equipped? I'll look at possibly re-instating the options, but maybe in a different form. watch for a future increment in the Announcements above. You'll need to test it out in FSUIPC4 as I doubt it has ever been used. Regards Pete

Yes, all that is exactly correct, and what you would expect for a knob which clicks once for "on to off" and again for "off to on". It doesn't matter at all how many times you have to click it to have it recognised in the dialogue! Why do you think that is of any relevance? Think of it like a toggle switch -- FSUIPC will see it when you toggle it on, but not when you toggle it off. The dialogue is designed to work that way to avoid false readings. All it needs to do is see it, and it IS seeing it as you just said! That doesn't mean you cannot program it for for "press" and "release" EXACTLY as i explained!! :-( Why didn't you just go ahead and do it instead of making life so complicated for yourself unnecessarily? Regards Pete

Assuming you really mean "serial IN" (for the GPS would need to RECEIVE data from the PC), you need to know that the "S" in "USB" does stand for "Serial", and it is probably the serial connection you need. On the PC USB ports have a strange name (not "COMn") which you'd need to determine -- I think there's an example in the GPSout docs. The usual problem is that the connection to the GPS on the PC will be taken up by an Active Sync or other program, installed to enable you to download routes & maps and upload tracks. I think you have to stop that running to free up the port. Regards Pete

Just the reference would have done, you know! :shock: Phew! That's really old stuff. Over three years since I did that, not touched it since. The bit that says "My testing facilities are still in place" was true then. Sorry, obviously I forgot to remove that. The testing facilities were only intended to be in place for a limited time, basically till I'd finished testing, maybe a wee time after. And this was on FSUIPC3 only. The testing facilities were there for testing, I naturally didn't expect folks to actually USE them for real, even then only to evaluate the facilities to see if they looked worth using for their programmed autopilots. I doubt they've ever been tested in FSUIPC4 as I don't know anyone who ever used them (till now, it seems). Checking my code I see this facility is still enabled in FSUIPC 3.81, but I'm not sure that it has ever been in FSUIPC4. Did you use it in FSX, and if so in which FSUIPC version? More to the point, did it still work? How and why are you using them? I can probably re-enable the testing facility, but if there's a genuine real use for the added controls as they stand I should be considering enabling them by default, not via a Debugging Test facility -- or at minimum by something sensible like "EnableAddedHoldControls=Yes" in the INI. Regards Pete

The default delta of 256 might cover any minor jitters. Modern digital joysticks on USB ports are a lot freer of jitter in any case. The main things which used to cause this (dirt, temperature, humidity, fluctuating power supply?) don't seem to affect the modern kit much. so it would be worth a try. To see exactly what your kit it doing, temporarily enable "Raw" mode in the Axis assignment and watch the input values. Regards Pete