Pete Dowson

They can't be "ultrarapid" or you wouldn't be able to see the numbers change. Turbulence is ultra-rapid, wnd variance is a slower up and down change in direction, like gusts are in speed, over the specified range. No! I'm afraid you misunderstand completely! FSUIPC's wind smoothing, if left alone without these added simulations, would prevent all turbulence, all variance and all gusts, because it intercepts the wind values and controls them! That was why I had to then ADD simulation for turbulence, variance and gusts into FSUIPC. The values it uses to do this were carefully worked out and tested by folks with experience of such effects for real, but if you wish you can change the way they behave using parameters in the INI file -- see the Advanced User's document. Or, if you don't like them at all, you can check the options to turn them off in the Wind options tab. If you want FS's own such simulations then you have to turn FSUIPC's smoothing off, because FS's cannot get through that smoothing control. Regards Pete

Why not simply download them and read the user guides? WideFS uses FSUIPC in any case. WideFS merely extends the FSUIPC interface to other PCs on a network. With what applications running on the client PC (the one witthout FS running)? Most if not all of those will have to be connected to FS directly -- i.e. of the PC running FS. I have no idea why connecting "gadgets" causes any lag in FSX. It sounds as if something else is wrong. Maybe Saitek's software is bad or buggy? Have you checked with their support? Neither FSUIPC nor WideFS will halp with bad gadgets. Your idea of Client and Server is actually the opposite of the WideFs system. But if you are putting display hardware on a Client, not running FS, you'll need drivers which can drive them. Are you going to write those, or have you found some? Pete

And what was wrong? Looking back I see you said which is correct -- that's wind variance. Wasn't it between the extremes set in the parameters you saw? Okay, so Active Sky is setting it. Sorry, I really don't have time for such a test, nor should it be needed. if you still think soimething is wrong, please explain what it is you think is wrong, and save a flight at the very point when the thing you think is wrong is happeninig. Regards Pete

Unexpected? By you? If there is turbulence set, it will be implemented. You say LGAV METAR was active throught, but even a small distance away from the actual LGAV weather station LAT/LON, there will be interpolation. Are you using AS2012 in DWC mode (its default)? If so, then it is AS2012 which is interpolating. If not it is FSX. I see you've sent something by email. I won't have a chance to check this til tomorrow. What's a "kmz" file? What can I do with it? I was expecting you to save the Flight so i would be at the same location as you with the same weather. BTW it is always best to ZIP files as I suggested. They can be more easily placed here then ans well as sent more economically. Pete

You need to use the facilities in FSUIPC explicitly designed to cope with this. Please refer to the section in the User Guide -- the chapter ientitled "Keeping Track of Multiple Devices ("Joy Letters"). You'll see it listed in the contents page. Regards Pete

Ah, good. Thanks for the feedback. I'll update the document with your details. I think it is (or at least surely should be) oscillations in all three axes, If FSUIPC is applying this then it computes maximum deviations according to the absolute values and the turbulence grade, and varies horizontal direction and speed and vertical speed using a gaussian distribution.about the set value as a mean. I've no idea what FS does when it is doing it. Well, I'm not sure what it is you do not understand, but since the first of the 6 entries is the nearest, and it has its elevation at offset 0x0658 + 12, or 0x0664, and since it is provided in feet as a FLT32, you simply read it with ipc.readFLT(0x0664). What was the problem in understandng this? No. I've never seen it happen, unless you are just experiencing the higher levels of turbulence and variance you can get near the surface. If you are seeing that there is none (eg via WeatherSet read-outs), perhaps you should send me the saved FLT and WX files, etc, so I can see what you mean? ZIP and send to petedowson@btconnect.com. Regards Pete

If, in 2005, you purchased FSUIPC4, then that purchase and your registration is still valid. But are you sure it was FSUIPC4 (for FSX) and not FSUIPC3 (for FS9 and before)? I ask this because FSX and FSUIPC4 were not released until 2006. Maybe you have your dates wrong? The registration process is executed by the Installer. Re-installation does no harm. if the version installed is the same or later than the one in the installer it will make no changes in any case, so why are you concerned? Regards Pete

If you looked at the FSUIPC log file you would see why. The Lua code is not valid. The "if" statement takes the form if <condition> then You missed the "then"s off! When trying to do these things it is always a good idea to look at other examples, and plenty are provided in the ZIP file installed in your FSUIPC documents folder. There are also many examples in the User Contributions folder. Furthermore, FSUIPC will log any errors in trying to execute such things, and you can even turn on Debug logging in the FSUIPC logging options. Note also that even with the "then"s in place, your code is very inefficient: You are reading the LVar at least twice, and in the worst case three times. Why? Here, I've added comments. See? ipc.readLvar("L:G1000ComPushPFD") -- FIRST READ, result discarded!!! if (ipc.readLvar("L:G1000ComPushPFD") == 0) -- SECOND READ ipc.writeLvar("L:G1000ComPushPFD",1) else if (ipc.readLvar("L:G1000ComPushPFD") == 1) -- If it was Zero, THIRD READ! ipc.writeLvar("L:G1000ComPushPFD",0) end end [/CODE] And you have a spare "end" which is another error. Look at this: [CODE]X = ipc.readLvar("L:G1000ComPushPFD"[b])[/b] if X == 0 then ipc.writeLvar("L:G1000ComPushPFD",1) else ipc.writeLvar("L:G1000ComPushPFD",0) end[/CODE] Isn't that more logical? Or even this more compact version, which assumes L:G1000ComPushPFD is definitely always either 0 or 1: [CODE]ipc.writeLvar("L:G1000ComPushPFD", 1 - ipc.readLvar("L:G1000ComPushPFD")) [/CODE] That one-line version writes 1 - the current value, so 1-1 = 0 or 1 - 0 = 1. Right? Please check the Log for errors each time you get an unexpected result! Regards Pete

Something else has changed then because there's no relationship between the FSUIPC version and WideFS functioning. That's only half the story. Where's the WideServer.log from the FS Modules folder? Perhaps, since you think it is something to do with FSUIPC, you should also find and post the FSUIPC4.LOG? This indicates that no broadcasts from the Server are being seen. Have you referred to the WideFs documentation? Please check the network configuring section. Regards Pete

You fail to mention which version of FS or FSUIPC, but I'll assume you mean FSX. 3470, 3478, 3480 are populated from SimConnect's variables AMBIENT WIND X, Y and Z respectively, read in m/s and completely unmolested by FSUIPC. Whether SimConnect reports them accurately or not I'm afraid I've no idea. That's why they are documented with such a question in the FSUiPC4 Offsets Status list. 3518 is a derived value so if the original is wrong, it will be too. Have you tried the other wind component values in offsets 2DC8, 2DD0 and 2DD8? They don't refer to exactly the same things, but at least they have been confirmed as working, as the document shows. These are directly from the SimMarket variables AIRCRAFT WIND X,Y and Z, and are in ft/sec rather than m/s. If FS truly does simulate all those things then, yes, I would assume so too. The FSUIPC simulation of turbulence certainly asdds some vertical component but I'm not sure whether FS's does. And windshear may only be simulated by a sudden wind shift between two layers rather than the slow progression normally implemented. For FSUIPC4, only, Check the "nearest airport" offsets at 0658. These used to be unreliable but a way was found to fix that (by direct reading of tables in FSX memory). Regards Pete

Bad night? What bad night? You never actually mentioned what program you were talking about till now! The reason "latest version" is meaningless is because it only represents the latest version you've noticed, and that depends where you looked last! I've had folks say "latest version" when the one they were using was over a year and 12 versions out of date! The ONLY correct references are (1) name of program, and (2) version number. It isn't so difficult, really! Pete

You miss the point I fear. The controls normally used in the separate throttle calibration tab are those with a reverse range from -16k to 0 and forward thrust only from 0 upwards. The whole range is still applicable to all aircraft, it is just that aircraft wiithout reverse ignore the negative inputs. The calibration section does not know or care what aircraft you are calibrating for. You can of course make calibrations specific for particular aircraft by using the Profile or Aircraft Specific facilities, and adjust the way you calibrate accordingly. One of the main reasons FSUIPC has been used for calibration for a long time (since FS2000) by so many folks is precisely because it can provide reverse ranges on levers, whereas FS itself cannot. This was true for so long that it was not until relatively recently that the "no reverse zone" facility was added. Even then the main spur for that was the introduction of the Saitek quadrants which were fitted with a button operated reverse instead. Before the NRZ checkbox was added folks who didn't need or want a reverse zone simply calibrated the idle (centre) position at the full back position of the lever, which effectively does the same thing anyway. Before you "discovered" the NRZ you must surely have noticed that there were 4, not 2 calibration points? One for full thrust, two to define the idle area, and one for full reverse. They are actually displayed and labelled on screen, so surely difficult to miss? And if you bothered to follow the numbered steps to proper calibration listed in the User Guide you could not have failed to notice! Pete

Er, WHAT is the program you are talking about, of which you have the "latest version"? You need to actually say what you are talking about. If you mean FSUIPC4, then this is an FS module. It can only be installed into FS. Also please never just say "latest version" as it means nothing. Provide the version number. If you are wanting to extend the FSUIPC application interface onto other PCs on a Network, then you need to purchase WideFS. Then, as Andy says, it is only Wideclient.EXE which is run on the client PC. There is no installer for that, you simply place it wherever you want. Regards Pete

You are unfortunate to experience the SimConnect trust bug. Please see the thread " FSX fails to run after FSUIPC4 first installed" in the FAQ subforum. Regards Pete

Yes, Lua can do the actions you require. But I think you must be confused about some things. "Keysend" is a way of sending a key number (0-255) to a Client PC over the Network using WideFS. The Keysend number is then translated into an action on the Client PC via parameters in the WideClient.INI file. Since local panel variables (LVars) cannot be useful outside of FS and its panels, I can't see why you are considering "KeySend" at all. You write your small Lua plug-in and simply assign your button to that plug-in. eg name the plug-in ComSwitch.lua and assign the button to "Lua ComSwitch" in the drop-down. If you save the plug-in whilst FS is running you'll need to press the "reload" button on the Buttons & Switches tab to get the addition listed, first. If you check the Lua library documentation you will see you can read LVars by using the ipc.readLvar function and write them using the ipc.writeLvar function. Regards Pete

First of all, "readUB" is "read unsigned byte", and a byte only contains 8 bits (numbered 0-7). So you'll never get to bit 14. I think you'll find that Project Magenta's offset 04F0 is a 16-bit Word, so you need to read it with ipc.readUW. Second, to isolate and therefore test individual bits in a binary value you need to use the logical function "And". For your bit 0 you'd do if logic.And(psCMD1, 1) ~= 0 then ... end because bit 0 is 2^0 = 1. To isolate and test other bits you need the mask value (the 1 in the above And function). You could use hexadecimal values which makes it easier to visualise: 0x0001 for bit 0 0x0002 for bit 1 ... 0x8000 for bit 15 Please see the thread about bits and numbers in the FAQ subforum for more information. Regards Pete

The FSUIPC SDK contains "UIPC_SDK_JAVA.zip". I think that must be it. The SDK is always the first place to look. It is available in the same places as FSUIPC itself. Regards Pete

That protocol only applies to the MCP. PFC does not use it for their other serial port devices such as the centre console, the yoke and it buttons, nor the MIP or quadrant. You evidently misunderstood. I was never proposing adapting ProSim to handle the PFC hardware directly. Use my PFC.DLL or PFCFSX.DLL to handle the hardware and operate FS + Project Magenta via the standard PM offsets. Then simply configure ProSim to use the same PM offsets. There is no need to try to make ProSim connect direct to the hardware. If you do, then please don't ask me for support because then you will not be using my software at all. That "seven options" list is unknown to me, it is not my software and not my list. However, it seems to simply relate to the nature of a specific offset -- 8 bit unsigned, 16-bit signed, unsigned etc etc. It is a choice of format for an offset, nothing to do with hardware, and it can be different for each possible variable. For the type of value for each offset in FSUIPC you need the FSUIPC offsets list (in the FSUIPC SDK), and for PM you need the PM offsets list (on their website). I hope this won't offend you, but I'm afraid it looks like you are very confused about what is what. It looks like you are rushing into doing things without proper research and working out what you are doing first. If you want, as you imply, to make your own way of driving the PFC hardware then good luck to you, but I think you are going on the wrong course. Regards Pete

The -4096 represents maximum reverse thrust (based on the default 25% max reverse for aircraft which have this). Anything more negative is not useful in any case, and whatever it is is mapped to the max reverse value for the loaded aircraft in any case. I think you are misinterpreting something. If you don't want reverse on the same axis (as it sounds from your "controls only working in the top half" comment), simply check the "no reverse zone" option! If you do want reverse but on a smaller part of the axis, simply calibrate the centre or idle position where you want it. That's the whole point of the comprehensive calibration facilities provided! In fact you could calibrate the full off position of your lever to the idle/centre position in any case and avoid the reverse zone, but the NRZ option is more efficient. With the controls FSUIPC uses by default, the OUT range 0-16383 represents the complete range of forward settings which the ordinary controls deal with by -16k to +16k. This is what you fail to grasp it seems. The default FS controls do not have any reverse range at all! Please do read the User Guide some time. It will help. Pete

sorry, no, unless Intercraft in Japan can supply one -- they supply the Japanese market. Pete

1. Assign to both "press" and "release" -- most encoders send an on and off alternately. That would double your speed. 2. Use Offset Inc/Dec controls instead of the FS trim controls. See the example in the FSUIPC User Guide (the boxed section entitled "Offset Increment/Decrement Controls") which is actually the very thing you want and allows you to make it completely adjustable to your liking. Pete

That's only there to help with loading conflicts with other add-on DLLs and EXEs. in the DLL.XML or EXE.XML files. I don't know of any at present. If FSUIPC is not even being loaded then obviously such a parameter cannot even be read. If there is no INI file in the FSX Modules folder then FSUIPC has never even run. Did you delete the previous INI file? Possibly, though only the sP2 version of Simconnect would be relevant. Please see the FAQ thread about problems with FSUIPC not being loaded. It is almost always a timing issue between Smconnect and the Windows trust subsystem. It only affects a few systems, but it is annoying. Microsoft never managed to fix it. Regards Pete

What software? Sorry, I'm confused. What's "Ians software" and "Fly-elise"? I'm not seeing how these things relate to FSUIPC? Change what timing? If you are referring ot FSUIPC4.INI, that is always created, if it doesn't already exist, when FSUIPC runs. Same with the LOG file. If neither are there then FSUIPC is never being loaded. The problem lies either with SimConnect in FSX or with a corrupted DLL.XML file. Why's that? What motion platform system uses FSUIPC? I've never been asked to license such a thing that i recall. Pete

Ah, okay. Good. In fact FSUIPC is not there just to create the folder, it is actually the interface into FS used by all my other modules, so it is needed. With PFCFSX.DLL also installed and configured it can actually also be used for FS axis assignment and calibration, and for switch assignments too. But generally it is best to do this in the PFC module itself. Ah, yes. I remember that the older versions were "dual protocol". Okay. That's the information I needed. I'm surprised there are any numbers. The Elite protocol is rather different and PFCFSX doesn't understand it. You are probably seeing rubbish interpretations of stuff arriving, that is all. Yes, 64 would be pretty central, though not many actual units would be so accurately set. It sounds like something is wrong with the wiring or the pots themselves. Have you checked the "Test" tab in the PFC driver -- it should recognise and decode the rockers and buttons on the yoke. Check also that the port speed is correct. I don't know if the default for PFCFSX was always applicable to all models. There will be a line to configure that in the PFCFSX.INI file. Normally 9600 I think, but also try 4800 and 19200. When you say "Opening up com1 via putty,...", is that some sort of Port monitor? If so, can it display hex values as well as ASCII (there's no ASCII in either the PFC or Elite protocols). If so, show me what you get on COM1 for the axes. PFCFSX's test mode will give you the hex values as well as the decode. There s also a wealth of logging functions in PFCFSX.DLL which can help us understand what is going on. See the options bottom left on the "Test" tab. Hmm. There used to be a Support Forum, but I can't see any sign of it now. Contact with their Tech Support is difficult -- even for a PFC developer like me. My emails get answered, eventually, but it can take a week or two. They aren't a large company despite their extensive range of quality (and expensive!) products, and the limited number of staff are always busy and often off-site doing installation work and so on. However, you should always be able to get through on the 'phone to someone, even if they can't help directly. At least they could put you on a list. Good luck, Pete

Er, FSUIPC4 does not support PFC serial devices, and I have no idea how FSX is reading it on COM1 as FS doesn't have any serial port facilities. PFC serial devices are supported by my PFC modules -- PFC.DLL for FS9 and before and PFCFSX for FSX and later. I've no idea where you are looking to see these numbers, sorry. What s the "hidden" switch supposed to be doing? Ah, NOW you mention PFCFSX. So are you enabling the yoke and calibrating in PFCFSX as instructed? Have you referred to the user instructions at all? Why are you only referring to FSUIPC, which doesn't include PFC serial support except via the PFC drivers? The PFC DLLs have test modes for checking the switches as well. I suggest you refer to the user guide. If you want more help, be sure to mention the version number of PFCFSX too. You might want to check that it is up to date -- see Download Links subforum. Have you considered PFC support, as really it is their business? Regards Pete