Pete Dowson

Full guidance is provided in the Joystick calibration section of the FSUIPC User Guide. There are numbered steps giving full help, much more than I can give here. Please just follow them. I can look them up, of course, as can anyone who looks in the documentation provided in the FSUIPC SDK. But why do you want these? For FSX there is no FSUIPC.INI file, but an FSUIPC4.INI. And it is not supplied or installed, but generated by FSUIPC4 every time it is run. If you have FSUIPC files in places other than the FSX Modules folder you may have put them there yourself. Neither FSUIPC4 nor its installer does. Regards Pete

Okay. the problem appears to be that FSUIPC thinks you have an bad key, one made by a pirate hacked key generator. To prove this try removing your FSUIPC.KEY file from the FS Modules folder, to make FSUIPC unregistered -- I think you will find the red crosshair returns to AFCAD. if you believe you have a legitimate key, please ZIP up the FSUIPC.KEY and send it to petedowson@btconnect.com for checking. I do see a purchase made in your name (with a different email, which shouldn't matter) way back in August 2003, meaning you should have a good key, so I will need to check it out in any case. Is there any possibility you could have picked up a pirated registration file during your system's rebuild? Did you re-enter the registration yourself? Regards Pete

Thanks -- I think the issues I have with the 180.xx series of drivers must only apply to the 64-bit ones. I'm sure if there were such serious problems with the 32-bit ones they'd have been fixed by now, or there would be a mighty outcry from angry users! ;-) Regards Pete

I can't without more information. Does the FSUIPC.LOG file show any problem at all? Load FS, run it till ready to fly, then close it down. Paste the Log in a message here. Please also tell me the version of Windows in use. Regards Pete

You must have selected the option to Delete the previous registration, which is present to make it easy for folks who need to change one to match the other. The two other options are to enter new registrations, or merely to check them. And all three options can be bypassed by simply opting to cancel that specific offer. The installation will complete without touching or looking at any keys. In other words you have total flexibility. It only does what you ask it to do, no more and no less. There is no such message, and there have been absolutely no changes to the registration system or the keys between 4.28 and 4.40. In fact there have never been ANY changes whatsoever in registration apart from the movement of the place to register from the FSUIPC options to the installer. If your keys are no longer accepted it can only be because they have been explicitly withdrawn by request of SimMarket. If you believe this not to be the case, please ZIP your FSUIPC4.KEY file and send it to me for checking. Send to petedowson@btconnect.com. Unless you keep your version of FSUIPC4 up to date you will get no support. Regards Pete

I've had a lot of problems with the 180.xx series of drivers, so much so that I've changed back to my last really good set, 177.xx (can't recall the xx offhand). I've even had to swap out my GTX280 card for a 9800 GTX+ in order to do this. The symptoms of the problems with 180.xx drivers were Blue Screen of Death crashes in an nv....dll, infrequent but often enough to drive me up the wall, and, in full screen mode, black screen hangs in FSX when I used some of the menus, like aircraft selection. This was the same on two different systems, but both running Vista 64. I never had any problems till I moved to the 180.xx series drivers. I really don't know what nVidia are doing. :-( Regards Pete

SimMarket can sort it for you, or else you can send me all the details (both receipts, both sets of full registration details, and tell me which one you wish to use. Then I'll replace the other. Send to petedowson@btconnect.com. It may not get done till tomorrow night now. I'm away most of the day tomorrow (Thursday). Regards Pete

There's no "glitch", nor do you need very much intelligence! If you take the Heading as an UNSIGNED value direct from the offset, take the Magnetic Variation, direct from the offset, and scale it to match the units of the heading (i.e. shift left 16 bits to make it a proper unsigned 32-bit value) then subtract it from the heading, you end up with another unsigned 32 bit number which when converted gives you the magnetic heading. That way you never need to add or subtract 360. But either way, it surely isn't as matter of all that much intelligence to realise that -1 is the same as 359 when dealing with a 360 degree circle? Regards Pete

Correrct, though I normally calibrate the tiller to have a more forceful effect than the rudder (i.e. use a curve which increases effect quickly near centre). It seems to work quite well in my cockpit. Obviously if you are supplying the values directly you can do something similar. It still won't make a 747 turn on a sixpence, though! ;-) Regards Pete

Yes, and rudder next to it. They are read-outs for indicator gauges. Mainly the rudder one is used to allow checking of the rudder (deflection viewed on the EICAS or lower MFD) even though the real rudder control in FS is being 'stolen' by the tiller axis for steering on the ground. The steering tiller is not truly a nose wheel control but another rudder. The input is gradually blended with the rudder as ground speed is increased. This depends upon both rudder and tiller axes being calibrated in FSUIPC, as it is the calibration routines which do the blending. No. it's only a read-out. There'd be no point in any case. What would it do? Since all FSUIPC can do with a tiller input is send it on to FS's rudder, why not simply write direct to the rudder input at 0BBA? If your program also has control of the rudder axis you could do the same sort of gradual cross-blending yourself, as FSUIPC would do if both axes were calibrated in FSUIPC. FSUIPC has a "crossover" ground speed (defaulting to 60) at which rudder has 100% authority. At 0 knots the tiller has 100%. At 30 knots it is 50:50. the computation is easy enough. You should also check that the aircraft is on the ground, of course, else you ignore the tiller. Regards Pete

You use a 'Double'. Thanks Paul. not totally different from C/C++ then! ;-) Pete

Oh, I don't mind. don't worry. I try to explain everything when I see lack of understanding, so you should progress okay, hopefully. Sorry if I'm explaining things which you know in the process. But what's confusing still? Regards Pete

A heading of -1 is the same as a heading of 359. Look at the face of the compass dial if you don't understand why! Just normalise any result you ever get to lie in the range 0 to 359.9999... by adding 360 if it is less than 0, or subtracting 360 if it is greater than 360. Note that the same applies to time. If you added an hour to 23:30 hours you don't get 24:30 but 00:30. and An hour before 00:30 is not -00:30. This is merely application of everyday common sense! ;-) You need a programming reference for the language you are using. In C a 64-bit floating point number is a "double". I don't know what it is in yours, but you should be able to find out in the same way as you found out how to use the language in the first place. Regards Pete

It's subject to gyro drift (unless you switch that off). Pete

Oh dear. Please use the FACTORED column in FSInterrogator, so you can see the converted value, not the raw FS units! In any case you are mixing up signed and unsigned values. The heading is NEVER negative, it runs from 0 to 359.9999... and is therefore always positive. You are probably reading the correct data but treating it incorrectly. Going East the heading will be positive even if you are treating it incorrectly. Pete

0BE0 is merely a copy of the SimConnect variable "TRAILING EDGE FLAPS LEFT PERCENT", scaled to scaled to the FS98-compatible 0 to 16384 range. So, its potential resolution is 1 in 16384 for full flaps. That's 14 bit. Of course you won't be able to read it fast enough to get every possible value, and nor will FSUIPC receive every possible value because of the asynchronous data passing mechanism used by SimConnect. However, you should be able to read it often enough to give smooth enough values, and if you are driving servos the motion needs of the mechanism itself will surely interpolate the parts between. If you want to observe the values it is providing simply go to FSUIPC's Logging page, put 0BE0 in the first Offset slot on the right-hand sde, select type "U16", then check the "FS Window" option below. You will get a real-time readout on FSX's screen. There's no difference in offset 0BE0 in any version of FSUIPC4. I don't think FSX's SimConnect changed it in either of the SP1 or SP2 updates, and it is merely a read-out from the Sim's own value (from the Sim1.DLL engine). I only mentioned you were out of date because I do not support old versions. Regards Pete

4.30 is out of date. The current version is 4.40. When you ask about resolution you need to state which quantity you are talking about else I cannot possibly answer. Regards Pete

Okay. How have you done this? conditions for button press actions are possible, and documented in the Advanced User's guide. there is no equivalent for keypresses. As you don't tell me how you are accomplishing what you are doing I can't really add to it at present. You could also look at the Macro facilities, which allow any sorts of sequences of actions to be combined, whether instigated by button or keypress, and the Lua plug-in facilities, which allow you any amount of flexibility in what you do, as well as having actions depending on FS events. Check the Contents lists of the main two User documents regarding Macros. For Lua there are separate documents available describing this as well as examples to try or examine. You do need the latest FSUIPC release of course. Regards Pete

Assuming you do mean the "SET" button below the flap detente setting, i.e. the centre one, that's crazy. :-( I cannot see how it CANNOT copy the IN value to one of those two places (alternately) each time you press that Centre "SET" button. That is all that it does, it has no other finction except that! I think i would have to stand behind you whilst you are doing this to see what you are doing wrong. This facility is really quite simple and very reliable, and has been in use now in both versions of FSUIPC for some time (30+ months, as I mentioned), with never any trouble. That's not strange. It is caused by fluttering or jittering values on the axes you are seeing most. The FSUIPC routine merely shows the first axis which it detects changing. Wobbling values like that can be due to poor power supply (at the device, usually, so power from a USB port or hub), dirty pots, varying temperatures, moisture and so on. You can sometimes reduce or eliminate it by parking the axis at one extreme or the other, where the pot is less worn and the Windows driver makes a stable reading. In order to help deal with axes which never go quiet the Axis assignment dialogue is equipped with an "Ignore" button, which you can use to (temporarily) ignore the axis shown. If your Flaps axis is "spiking" (that is, not just fluctuating or jittering slightly, but actually occasionally sending extreme values, like your 16383) then that would more likely indicate a bad connection or dry joint and would be serious. Concievably this could be responsible for your flap setting problems, but I wouldn't expect it to be as consistent as you describe. You could test this by making a safe copy of your working FSUIPC.INI file, then removing the assignment of the flaps on the one you are using and then seeing if you can get the flap detentes set correctly using one of the other axes you are otherwise using and which don't appear to be jittering. Oh, one other thing to double-check (I didn't think of it before as it seemed too obvious -- but you never know), do go through all the assignments and make sure NO OTHER AXIS is assigned to Flaps, whether via FSUIPC or FSX. Regards Pete

FS itself doesn't simulate these things. Where an aircraft panel has them, their condition is determined by the logic local to the gauge maintaining the display itself. This is also why there are no FS controls for "pressing" those buttons and you have to resort to mouse emulation. If you are using a sophisticated add-on aircraft, like the Level D 767, then there's probably a way of accessing the status via the information in their SDK, or through interface programs written for this. The PMDG aircraft did have an SDK but it has only ever been made available, at a price, to hardware deveopers and I think it is withdrawn in any case at present. The more generalised add-on aircraft systems programs like Project Magenta and FlightDeck Software, and another I see recently, Sim-Avionics, do have interfaces via FSUIPC which you can use. If you are serious about building an airliner cockpit then you should really be looking at something like that for full flexibility in linking in and operating your indicators and switches. Otherwise you would have to resort to simulating the Master Caution condition yourself by checking all the conditions which can cause it to be lit. You could do this in a program interfacing to FSUIPC (or SimConnect, for FSX), or, in FSUIPC, you could consider writing a Lua plug-in to do the same thing. Regards Pete

Are you by any chance comparing a MAGNETIC heading with the TRUE heading provided in offset 0580? Is the magnetic variation wherever you are about 16 degrees? You need to be aware of these things. Please try using the tools available to check your own code. For instance, FSInterrogate will show you the TRUE heading and the Magnetic Variation (from offset 02A0). Alternatively, if you put your aircraft into slew mode and press the Space bar (or possibly Shift+Space or Ctrl+Space in FSX?), it will turn your aircraft to TRUE north and you can read the magnetic variation locally from the heading indicator. Regards Pete

Sounds like a video driver problem. Try running FS in Windowed mode instead of full screen. That usually gets around such quirks. Otherwise you'll need to find better video drivers. Regards Pete

Sorry, what documentation regarding what calculation? For a value which runs from 0 to 16384, the 100% value is represented by 16384, so a value of n is ((n x 100) / 16384). Simple arithmetic. Put another way, since "percent" just means "out of 100" or "proportion of 100" so converting a "proportion of 16384" to such means dividing by 16384/100. Pete

That's all very well, but it is the actual numbers which are important. That's all I need to see. FSUIPC will refuse to allow you to set impossible numbers -- i.e. numbers which make no sense in achieving what is needed. That is totally the opposite of what will work! Flaps Up is the MINIMUM value for flaps. "Minimum" means the least value, and must be lower than all the other values. Similarly Flaps down is the Maximum value for flaps (it has a higher flap number, a higher angle, remember?). With ANY axis, whether you set and calibrate in FS or in FSUIPC, you must ALWAYS first ensure that you have it going the right way! You CAN leave your Flaps going the wrong way if you wish, but then you have to remember to push away from you for more flaps, instead of towards you as in the real airplane. Note that the spoilers/speed brake axis is also reversed. If you look at a throttle quadrant, the one for your default 737, you will see that when everything is "off" or at "minimum", the left and rightmost levers are both as far away from you (top most) as they can get, whilst throttles are nearest or at bottom. This alone should suggest that those outer two are reversed relative to the others, right? Yes, of course. Clear everything (press Reset then Set is best) then select Rev, THEN do everything you did before. Regards Pete