Pete Dowson

You are mixing up "offsets" (which are effectively addresses of data in memory) with FS event or control numbers, which are simply numbers representing an action. ACTIONS are controls, which have names (as listed in the FSUIPC assignment drop-downs) and numbers (which is how they look internally). DATA, such as the current heading, is held in memory and identified in (FSUIPC only) by OFFSETS, which are hexadecimal numbers related to the data's original position in one of FS98's modules == it was in 1998 that FS still actually maintained such data areas! The whole notion of "offsets" dates from then. If you need to identify offsets you need the FSUIPC SDK, which includes a full list. If you need to identify FS control numbers you can use logging, as you have done, or you can simply look them up in the list installed for you in the FSUIPC Documents folder in FS Modules. Note that FSUIPC also adds its own set of "controls". These and their numbers are listed in the Advanced Users Guide. Regards Pete

Without resorting to a Lua plug-in for FSUIPC, which could do it, you could try calibrating in FSUIPC as normal, but then editing the numbers in the FSUIPC INI file. You find the lines in the JoystickCalibration section. For example, a default (not truly calibrated) entry would look like this: Aileron=-16380,-512,512,16380 If you increased the values of the numbers at either end of the range to values that you joystick cannot reach, the range you can achieve in FS will then be correspondingly less. For instance, in theory: Aileron=-32760,-512,512,32760 would stop them reaching more than 50% deflection. I say "in theory" because I have not tried this and don't recall whether FSUIPC allows values over 16384, which is the theoretical max in FS. Personally, I think this isn't the correct approach, though. First you might want to try using the "Slopes" option in FSUIPC calibration, after calibrating properly. You can flatten (lessen the response) quite substantially so that you need to move the aileron control say 80% of its travel to reach 50% deflection, just by selecting the flatter slopes. The remaining 20% of the control would then give a faster response in order to achieve 100% deflection, but I don't think that will matter in day to day flying. Another idea I've seen adopted by many is to put much stronger springs or elastic bands in the mechanism to stiffen it up. Regards Pete

FS can only offer what FSX provides. What specific controls were you expecting? There's a list of all of the FSX controls installed for you in the FSUIPC Documents folder in your FSX modules folder. If there are FSX controls provided for them, you can identify them by enabling Event logging in the Logging tab in FSUIPC options, then activating the function you want on screen. If that used an FSX control, it will be logged, and the name of the control that you can assign will be shown. If this gives no results, then there are only two other possibilities. One is that mouse macros would do the job -- there's a chapter on these in the User Guide. However, if this is a default Microsoft aircraft then I doubt very much that this route will be successful. The other method is by using local variables, or "L:Vars". If the gauge for the EICAS is written using XML this is more likely to be successful. [LATER] I've just checked. It uses L:Vars. The correct one for the EICAS screen selection is "L:EFIS Screen" and it takes parameters 0 to 5 to select between 6 screens. So you can make a macro for it as decribed in the FSUIPC Advanced Users manual. For example, for a cyclic increment you'd need a macro file, called say CRJ.mcro containing: [Macros] 1=L:EFIS Screen=Cyc In FSUIPC keys tab, assign to CRJ:EFIS Screencyc setting the parameter to 5, as the cyclic limit. Regards Pete

To recap, the value in offset 0504 is 0xABCD where A = Autopilots, B = thrust channel, C=vertical channel and D=horizontal channel. In other words, in the 16 bits, 4 bits are allocated to each. So if you are reading the 2-byte (16-bit) word, the masks for isolating each of the 4 bits are easy to see: 0xABCD AND 0xF000 = 0xA000 0xABCD AND 0x0F00 = 0x0B00 0xABCD AND 0x00F0 = 0x00C0 0xABCD AND 0x000F = 0x000D because hexadecimal "F" is 1111 in binary, making the logical AND select only those 4 bits, in each of the 4 positions. See? Having isolated the correct bits you probably need to move them so they make a normal integer number. To do that logically involves SHIFTS -- i.e. shifting bits left or right -- in this case right. However, doing it ARITHMETICALLY might be easier for your software. I don't know. But for this note that hex 0x10 = decimal 16, 0x100 = 16x16 = 256 and 0x1000 = 16x16x16 = 4096, so to shift right by 4 bits divide by 16, by 8 bits divide by 256 and by 12 bits by 4096. This is all simple logic or arithmetic. Much more basic and easy than understanding aircraft systems! ;-) Pete

Checking the trim settings should be first -- I've seen quite a few incidents like this where one of the lesser-used trims was way off. Easiest way to check is to save a flight and look in the FLT file. Search for RudderTrimPct=0 AileronTrimPct=0 If they are not zero, make them so in the File and reload: see if that helps. Regards Pete

To change an axis function completely depending on such a thing as when you are on the ground or in the air can only be done with a Lua plug-in. No offset is involved other than reading the one which tells you whether you are on the ground or not. You'd assign the axis to run the Lua program (much like assigning a button to run a lua program). You wouldn't assign it to either steering axis or spoiler in FSUIPC. The axis value from your device is passed to the Lua program as "ipcPARAM". Then that program would may process the value before sending it to FS as Axis Rudder Set (for steering) or Axis Spoiler Set (for spoiler) parameters according to the "on ground" flag read from the offset. I haven't tried this myself, and I'm not sure you'd be able to calibrate the outcome in FSUIPC (because FSUIPC is processing a different axis which may not be scanned when calibrating the "mapped" axis"). But it might be. I don't know anyone else who has tried it either. It would be an interesting experiment which I shall certainly try when I get some time -- maybe later this week. Regards Pete

The spoilers toggle and arm controls are those which are assigned by default to the / and shift+/ keys (or is is \and shift+\ ? I never remember). Have you never used the keyboard with FS? And anyway, why bother messing with your complex button arrangements to test things, when you can assign the same controls, for testing, to any of many key presses? Most more sophisticated setups would use an axis assignment for spoilers in any case. FSUIPC has calibration for the ARM point on an axis. Both "Spoilers set" and "Axis spoilers set" are axis controls, as I say, not really button controls -- unless you provide an appropriate parameter too. Regards Pete

SPOILERS SET is the older axis command. the more modern one is AXIS SPOILERS SET. Are you testing this on the ground? If so, don't! Get the aircraft in the air. FS has a quirk whereby it auto-activates the spoilers on the ground when armed, just as when landing. Regards Pete

Hmm. I thought some of those phases were intended to allow manual control. Okay. Those things are unknown to me, so I've never thought anything was wrong. I don't have a motorized throttle so I suppose it wouldn't have as much impact for me. Yes, I saw those demonstrated in Lelystad. Very nice. I really wish there was some way of fitting one in my PFC ready-built 737 cockpit, but alas it would be a major metal cutting and reworking job which would be beyond me. No no. AND is a logical operation between bit patterns. There are four main logic operations. Consider two binary values, 1100 and 1010 (hex C and A, or 12 and 10 in decimal): 1100 AND 1010 = 1000 in other words a 1 only where there is a 1 in both (this AND that in English) 1100 OR 1010 = 1110 in other words a 1 where there is a 1 in either (this OR that in English) 1100 XOR 1010 = 0110 in other words a 1 where there two are different. (XOR is "exclusive or") The 4th main one is NOT, so NOT 1100 is 0011 and NOT 1010 is 0101, i.e. just change all bits to their inverse. Using AND to select bits, as I am doing with the byte at 0505, is called "masking" and the 0x0F value I am using to select the bits is called the mask. Maybe the software you are using understands those terms instead of the logic operations. An alternative to masking, if the software only supports arithmetic operations and not logical, would be to divide by 16 and take the remainder. Regards Pete

Since FSUIPC does not care which aircraft you are using, and doesn't really know whether you have taken off or not, I'm afraid there is nothing that FSUIPC is doing which could possibly account for this. It therefore must either be some function of the LVD 767, or possibly of other software you have installed which is detecting the takeoff and changing the aircraft's configuration accordingly. If you want to assure yourself that FSUIPC is still responding correctly to your button settings just enable Button logging in the FSUIPC Logging tab. Then you'll find all the details in the Log file in the Modules folder. Regards Pete

WideFs handles the communication from and to FS via the FSUIPC interface. It does not have anything whatsoever to do with programs accessing files across the network. That is all handled by Windows Explorer and sharing files, or mapping folders as remote drives. I'm afraid I do not know how FSC does things. It should be documented in their manual. If not perhaps someone on their support forum can help. Regards Pete

"Thrust" you mean? No idea what FMA is. Okay. It just means that, seen in hexadecimal as: 0xABCD for instance, that A = Autopilots, B = thrust channel, C=vertical channel and D=horizontal channel. In other words, in the 16 bits, 4 bits are allocated to each. Read the offset, AND it with 0x0F00 to isolate the 4 bits for thrust, and shift the result 8 bits right (or divide by 256 which is the same). Or, more simply, read the 1 byte offset 0505 (the high byte) and AND it with 0x0F. Pete

You must set the Zulu time. That's the prime time conytrol I think. FSUIPC can't do much more than write these things for you. It doesn't control what FS does about it, but programs like FSRealTime seem to work fine by setting both sets of times. Regards Pete

"UseASEweather, etc."?. What's the "etc" part? And you shouldn't need to add UseASEweather, as it is defaulted to do so if ASE is in DWC (Direct Weather Control) mode. If it isn't using DWC there's really no need. That makes sense except in DWC mode, because in that mode ASE sets FSX into "global" weather mode, in which the weather is the same all over the world, with ASE changing it as you fly. That's the whole reason for the aSE link-up in FSUIPC! So are you saying you are NOT using DWC and that's why you added the UseASEweather parameter, to force the connection? That's actually a greater range than I thought you could receive ATIS broadcasts. Mostly I thought it was less than 80 nm. Er. Why? Surely for planning purposes you should be obtaining the predicted en route weather before even taking off. In the real world you'd get that in the planning room on or ACARS. In the Sim world you get it from ASE direct. You could do it by using the Weather request via offsets in the CC0x range. You'd be able to read the ATIS as an FSX-encoded METAR string in another offset. All the details you need are provided in the FSUIPC SDK. Yes, you could do it via a Lua plug-in. It's only a sequence of offset writes and reads. I actually get weather via "Its Your Plane". Usually it matches ASE. I assume they get the weather from similar Internet sites. Pete

Sorry, I don't know. Perhaps someone who knows the Saitek software will chime in. Pete

I'm pretty sure that the speed brake is operated by the normal FS controls for spoilers. Have you tried those? Pete

Is that the folder where GFconfig is installed? If so then it should already have been there from the GoFlight software installer. FSUIPC will not find it there unless the Registry points correctly to GFConfig in the same folder. If you installed the GoFlight software with their installer it should all happen automatically. At least this used to be the case. maybe they've changed things of late? It makes no difference to FSUIPC's Button assignments what aircraft is loaded. I suspect that FSUIPC is not, in fact, seeing GFDev.dll because the Registry does not point to it. Try putting it into the FSX Modules folder. Also please note that to FSUIPC the buttons are just buttons for assignment. The aircraft is a complete irrelevance. It does not care. Note that it does NOT handle the displays.. For that you'd have to use my freeware GFdisplay program, or program the device in a Lua plug-in. Actually I did mean to do a Lua program for the GF MCP Pro, as an example, but haven't had time. Not as far as FSUIPC's interface with GFDev.dll it cannot. There's absolutely no relation. It may just be that GFDev.dll is getting loaded later by the GF FSX driver. Since FSUIPC itself doesn't drive the GF displays I think this must again be another mixup with what the GF driver itself is doing. If you want to use FSUIPC with the GF MCP Pro you would really need to disable it in the GoFlight software, or stop its EXE running altogether. They can't work happily together trying to read the same buttons and operating the same A/P controls. There is an example for the GF MCP in the GFDisplay documentation, but not for specific aircraft, only to show it programmed for Project Magenta. It's an example only. Regards Pete

Correct. Regards Pete

The manual does actually say: and then the whole process of assigning detentes does start with If you don't actually have any on your lever, why would you mistakenly try to calibrate the detentes you don't have? Regards Pete

I can confirm that. Even threatening to prohibit FSUIPC use with Saitek connected gear (which I can do by reading the USB manufacturer code in software) doesn't move them. Regards Pete

Delete the INI file, which contains all your FSUIPC configuration settings, from the FS Modules folder. It is that simple. Pete

The FSUIPC log shows everything is working fine and it is properly registered. I think this is nothing to do with registration. Are you by any chance running FS "as administrator" but the IVAP program not? If so this will prevent them talking to each other, as they are at different protected privilege levels. If this is not the problem I am afraid you will have to ask the IVAP folks for assistance. But first please do try my own ancillary programs like WeatherSet and TrafficLook. If they cannot comminuicate with FSUIPC either then something else is wrong. Pete

Neither 3.93 nor 3.96 are supported. They are far too old. Download and install one of this year's releases (3.98 is valid) and we'll discuss any problems you may then have. Pete

I thought of a way to do this which might be a little simpler for you, using the virtual buttons I mentioned. Note that there are 288 of them, not 512 like I said earlier. Should be enough, though? ;-) There are some user-offsets available in FSUIPC. You could use one of them to send a number to FSUIPC, using HIDMacros.SetFSUIPCInt and have a Lua plug-in to convert that to a button press for assignment in FSUIPC. Save the following code as "ipcReady.lua" into your FS Modules folder: function sendmybutton(off, val) if (val >= 0) and (val < 288) then ipc.btnToggle(val) ipc.writeUW(0x66C0,-1) end end ipc.writeUW(0x66C0,-1) event.offset(0x66C0, "UW", "sendmybutton") Your HidMacros now only need to do something like: HIDMacros.SetFSUIPCInt &H66C0, 2, N where N is any number from 0 to 287 inclusive. Send a different value for each key. Then that Lua plug-in will convert the keypress to button events which you casn assign as usual in FSUIPC's buttons tab. By way of explanation, the "event.offset" call at the end of that little Lua program causes FSUIPC to call the function "sendmybutton" whenever offset 66C0 (an unsigned word = 2 bytes) changes. To make sure we see changes even if you press the same key more than once in succession (or allow it to repeat) we reset offset 66C0 to -1 initially and after each change we see. Okay? Note that I'm here assuming you want the keyboard(s) to behave like keyboards not like joystick buttons, so I'm "toggling" the button. If you want a Key press to press the button and a key release to release the button things get a little more complex. We'd have to flag the difference between press and release by sending a different range of numbers for each, and the function in the plug-in would then use ipc.btnPress and ipc.btnRelease instead of ipc.btnToggle. Regards Pete

So you never actually assigned to any control in the drop downs? Those are the 4 places BELOW the option you stopped at, to allow up to 4 assignments for each axis. If you don't assign an axis, how do you think FSUIPC will know what you want to do with it? selecting "Send to FSUIPC calibration" simply selects the METHOD of it being sent, not WHAT you are sending! Why not read a little more of the User Guide? It would help/ There are even some pictures illustrating things for you. Why ASSUME anything at all when it is all documented? Why skip most of the important parts of the document in order to frustrate yourself and come here to waste so much more time than you would spend by just looking things up? I don't understand. It is NOT an "extra step". You are omitting the MAIN step -- the actual assignment! I really don't understand how you could possibly miss it. This is the single most important step in assigning an axis -- the actual selection of the function to be performed! :-( It won't pick up anything if the axis is not assigned. :-( Pete