Pete Dowson

Ah, I just asked thatyour message crossed with mine. Strange, as they are both emulated the same way, with the same code and same values. Only the test is different -- with wind turbulence it gets enabled by the turbulence value in the current wind layer, with cloud turbulence it's the same test but in the cloud layer. Sorry, wehat do you mean by "moving"? Where are you reading these "actual wind values"? And what is the difference with Cloud Turbulence? As I say, they are the same inside FSUIPC. It's supposed to do that with wind turbulence too. They are (or should be) the same. Even for mild turbulence you should seem some small variations in both direction and speed. I'll see what I can find. Probably not till next week some time now. Pete

I hope you mean the other way around, "0.5,2.5", else you would have increased the first one considerably! Hmmm. I'm stuck then. Before trying to get back to ASX SP2, why not try with FSX downloaded weather instead of ASX first. Might be easier. Try to find some with turbulence, or re-enable the random facility FSUIPC provides (but if you do that, you'd need to check the "change FS own weather" option before it will add the turbulence). Regards Pete

Well, I have them enabled... How are you testing? Pressing the ATC button on the Keyboard? (the '/@' key on mine)? It is really nothing to do with Radar Contact. FSUIPC only hooks into three routines in Window.DLL, diverting calls to them to itself. these are calls to display a window, put text into a window, and close the window. It checks whether the Window title is the ATC one (from Language.dll) and if so, it just returns to the caller without doing anything. Otherwise it passes the call on -- the same calls are used for lots of Windows. Pete

What values did you try? Did you try adding that parameter to the INI file as I suggested? Regards Pete

Hmm. I tried with the German language DLL and it still works fine here. I'm afraid I am none the wiser -- I've looked through the code and I really cannot see any way that it could be different. One small check, right-click on the Window.DLL (in the modules folder), select Properties - version, and see what version number it says. Mine is 9.1.0.40901, which is correct for a 9.1 version FS2004. Pete

I don't know the program "VAFS3", but the message it is producing is presumably a result of its own checking. Maybe it isn't getting enough time on an overloaded PC? I think you might be better off seeking help from whoever wrote or supplied that program. Only the Install log could show a successful install. The normal log should show more about FSUIPC running -- there should be a file "FSUIPC4.Log". Maybe you could find that and show it? Pete

Well, it's identical to mine, and mine works fine, so, yes, it is correct. I therefore don't understand why it doesn't work for you -- FSUIPC thinks it is working okay. FSUIPC gets the ATC Window name ("Air traffic Control") from the "Language.DLL" component of FS. This should enable it to see it being created and to stop it. Have you, by any chance, undocked the ATC window? That might make it miss it. I'm not sure i cope with both docked and undocked versions. If you save a flight, and look in the saved FLT file, you should find a section like this: [Air Traffic Control] Undocked=False ScreenUniCoords=1500, 1200, 5192, 2000 UndocCoords=0, 0, 0, 0 except yours will presumably have a German name for the section, as the section bears the Window name. Can you check? Maybe you can Zip up the Language.dll from your Modules folder and send it to me (petedowson@btconnect.com) to try here? That should be the only difference in versions. Regards Pete

Please check the FSUIPC.LOg. There should be lines like this: 38547 RemoveATC: Intercepting ATC window calls to prevent them appearing 38547 Patching ATC to recover ATC.DLL crashes at 000265f4 38547 Patching ATC to recover ATC.DLL crashes at 0001a961 38547 Patching ATC to recover ATC.DLL crashes at 0002a631 Let me know what you have. Pete

Sorry, no. And really, at this stage, I've no way of finding out. All that stuff is many years old now, but it all worked at the time. Maybe you haven't got the FS9.1 update installed? I think it only worked with that in any case. Can you look at the FSUIPC.LOG, please? There should be linesnear the beginning like this: 38547 RemoveATC: Intercepting ATC window calls to prevent them appearing 38547 Patching ATC to recover ATC.DLL crashes at 000265f4 38547 Patching ATC to recover ATC.DLL crashes at 0001a961 38547 Patching ATC to recover ATC.DLL crashes at 0002a631 Pete

Strange, as that's been perfect for weeks. However, it seems a lot of new stuff is happening since ASX SP3 was released. It instigates it. FSUIPC doesn't create any by itself unless you enable its random turbulence. If you are using ASX SP3 you may want to add the line "CustomWeatherRewrite=No" to the [General] section of the FSUIPC4.INI file, as otherwise there seems to be a lot more unwanted interaction going on. Sorry, what does that mean? Where are you looking? Unfortunately it seems folks are changing to 4.28 and ASX SP3 at the same time, even though 4.28 has been out there for 4 weeks with no weather problems at all reported until after ASX SP3 -- now suddenly I am getting "super fog" and "unmanageable turbulence" reported despite none of those areas being changed since 4.26. From what I've seen so far, and what I know about the 4.28 changes, I really must assume that the same things might arise with 4.26 + ASX SP3. Please do try reducing the turbulence parameters, to see if those help. If not I suspect something else is going on. Regards Pete

The main ATC crashes were due to a serious bug in FS's code which is patched, if possible by FSUIPC. It isn't related to Radar Contact -- it is provoked by having some coincidence of ATIS and control frequencies at different airports. Sounds like you are using an old version of FSUIPC. current is 3.81. The "RemoveATC" option was made to work on non-English versions of FS as long ago as June 2006. Regards Pete

The turbulence emulation has been thoroughly tested and approved by PMDG's own test pilot. There's been no changes at all in this since then. Obviously extreme turbulence is to be avoided. What level did you see? What vertical air added? You mean the the fix to the bug which prevents thermals and so on from operating? FSUIPC doesn't add any vertical component EXCEPT in turbulence, so for tubulence that changed nothing. In all levels of turbulence? I would expect severe turbulence to be unflyable, but that is very rare. Have you checked settings in your weather -- are you using ASX? That shows all turbulence suppressed. You can play with the turbulence emulation via the parameters TurbulenceRate=1.0,5.0 TurbulenceDivisor=20,20,40,40 Regards Pete

Yes, of course, but only with FSX. It doesn't work before FSX SP1. And it doesn't work for the APU, only engines 1 - 4. Why don'ty you simply try it, either via FSInterrogate, or by adding an FSUIPC control using Offset Byte Set or Setbits. Regards Pete

FSUIPC has nothing to do with transponders. You are misinterpreting some symptoms. FSUIPC is merely a tool for other programs -- it is perfectly possibly for a program to use FSUIPC to do things with transponders, but there is absolutely no active component in FSUIPC relating to them at all. You need to look elsewhere. One of the programs you are using is messing you about. Pete

Why are you using virtual ports? If you are connecting a real GPS you need a real port. How do you think you can connect a real device to a virtual port? Virtual means "not real". Virtual ports are for running a program in a PC whilst pretending it is connected on a serial port to the same PC. Pete

This seems to be a duplicate request. Please see the other answer. Pete

Only by using a second PC and the WideFS option. Unless you can find some electrical device which produces two Serial port signals from one output. Maybe having the Tx wires twisted together would be all that is needed (though I suspect you'd need diodes or something to prevent short circuits / overloads). There's no handshaking involved -- GPSout just slings the data out -- so it might work. Of course if the devices are USB that may not be so easy. The WideFS with a second PC or notebook would be favourite. On the main FS PC, if that's one with a GPS connected, you'd need to run WideClient alongside FS in order to receive the WideFS GPSout data too. To run Wideclient on the same PC as FS you have to set a class Instance, so that it uses a difference Window Class to FS. [LATER] Actually, I just thought. You could probably run more than one copy of wideclient, by using different class instances, on the same PC. Each could drive a GPS on a different port. Regards Pete

I don't know. You have the unit already? If so, why not check -- it should say in the manual what inputs it takes. Often they have a proprietary (Garmin) protocol for transsfer of software, maps, route data and the like, and maybe it has NMEA 0182 or "Aviation" or "400 Series" protocol for positioning -- it may have to go into a simulation mode to turn off the actual GPS receivers. You got me there. If it's only got a USB connection then it has to be connected to a USB port, but usually the software you installed on the PC for it will have included a "HotSync" program which takes it over as soon as you plug it in. I think in that case you have to somehow kill the Hotsync program so that the port can be assigned to GPSout, as a serial port. The serial port names for USB are a bit odd and I'm not sure how you find out -- there is an example in the data for GPSout. If it has a regular COM port as well, you'd be better off using a normal "null modem" serial cable, COM port to COM port. Or maybe Garmin supply a COM port cable which adapts the USB. I realy couldn't guess, sorry. Here are a couple of previous threads relating to GPSout on Garmin units: viewtopic.php?f=54&t=20878 viewtopic.php?f=54&t=21271 Maybe they'll be useful? Regards Pete

I'm sorry, but I don't know any of these programs -- "MatLab", "Simulink" or the "FS Interface box from AeroSim Toolset" at all. Is any one of these actually an FSUIPC application at all? What software is it which actually talks to FS? Maybe, if they are designed for FSX they use SimConnect? If whatever it is which connects to FS doesn't use FSUIPC then it cannot link via WideFS because all WideFS does is provide a Networked FSUIPC interface. Pete

I've just checked them on FS2004 -- the 0BB8 and 0BB4 values simply stick at their last manual value (they don't go to 0), but the deflection values at 2EA8 and 2E98 are working fine, and change correctly exactly as they do in FSX when on A/P control. Please check again. Use the Monitoring facilities (right-hand side of the Logging tab) or FSInterrogate. You must be doing something wrong if you only see zeroes. Don't forget those deflections are in Float64 format. Pete

The aileron and elevator position indicators (0BB8, 0BB4) should help. Or you'd need to use the actual deflection angles, 2EA8 for Aileron, 2E98 for elevator. All these work fine with the autopilot in FSX, and should be okay in FS9, though you'd need to check that. Regards Pete

Well, I seem to be talking to myself here, but in case anyone is still interested, after investigating these reports as much as I can (I cannot reproduce the actual problem), it appears to be something to do with interaction between the latest version of ASX (SP3 can out whilst I was on holiday) and the facilities in FSUIPC4 to apply filters and to attempt to automatically remove spurious wind and temperature layers. So, if this is indeed the case, the interim work-around is to do one of two things. Either 1. Turn off the option to update FS's own weather. With version 4.28 this does NOT stop the wind, pressure and temperature smoothing options -- it was precisely to allow this that they were separated! In fact the option is defaulted off in any case, but you wouldn't know that from an existing installation where you had to have it enabled for wind smoothing (4.26 and 4.25). Or 2. Add the line "CustomWeatherRewrite=No" to the [General] section of the FSUIPC4.INI file, leaving the option for changing FS's own weather enabled. This will remove most of the "own weather updates" when custom weather is in force -- e.g. when ASX is in charge of it -- but still attempt to sort things out for FSX's own weather downloads, and themes and global weather. I am going to remove that option and replace it by "CustomWeatherModify" which will automatically appear in the INI file and will default to "No". It will actually be a little more drastic than the "Rewrite" one, which doesn't prevent all attempts. Look out for interim version 4.282 early next week. Regards Pete

If the GPS accepts NMEA 0183 or Aviation format position information. None of my three Garmin models do. For FS9 or earlier you need to download GPSout. For FSX you need a registered version of FSUIPC4. Then refer to the documentation. Regards Pete

It sounds like they are on USB ports with "power management" enabled. When Windows has that option it removes some USB power from devices which appear to be "asleep" until they wake up again, and this causes erratic readings initially. Regards Pete

Well, I don't think really it is FSUIPC's job, but a nice project for a utility or gauge. FSUIPC provides the tools -- the brakes can be disconnected by FSUIPC and controlled by program. Did you look at Thomas Richter's work in this area -- I gave you a link? Regards Pete