Pete Dowson

Is this with straight-forward use, assignment in FS and nothing in FSUIPC? Do the axes show this sort of irregularity in the Game controllers calibration? Have you actually calibrated them in Windows first? don't they need Saitek drivers t be recgnised by Windows? FSUIPC is not a joystick driver in any way shape or form. It simply reads the axis values either through FS assignments or assignments in its own "Axes" tab which (in FSUIPC3) uses Windows basic joystick interfaces. Active Sky provides a lot of options itself. You can use the FSUIPC ones as well -- the most useful normally are those which smooth the changes. I don't understand either. To me a joystick axis is simply a source of an analogue input signal. It should be providing smooth changes in values from one extreme to another, and calibration is merely the act of matching its range of values to those acceptable to the flight control you wish to apply it to. Unfortunately (or not, as it seems) I do not have any Saitek (nor CH) gadgets so I can't realy comment on them specifically. Maybe others here can contribute. I assume you've scanned the other threads on these units? Oh, one thing to note. Heading your thread "General help please" won't easily attract any specific help from those who might actually know Saitek stuff. It might be a good idea to re-post you real questions on your equipment with a title which reflects that Regards Pete

Hope you have better luck than I. I'm still trying to get the six-pack and re-fuellying options working for that. I assume you mean 0BDC not 0DB0? Yes, I modified my PFC driver to write 0-8 to that offset for flaps. Not got as far as testing that part yet. Nothing in any of my software stops you writing to that location. how are you actually determining that you are not writing to it? Did you enable FSUIPC IPC write logging to check? That offset is privately allocated to Thomas Richter, for him to use as he likes. As such nothing of mine prevent anything writing or reading it. So if it seems as if you are not able to change it, it is most likely that something else is also changing it, ruining what you are writing. Maybe it is a setting you have wrong in the TSR program itself -- that seems the most likely cause. You really need to deal with TSR support on this. Regards Pete

Unfortunately, like those in previous versions of FS, those EFIS controls in the default 737 are inaccessible by anything other than the Mouse, so you'd need something like Luciano Napolitano's "Key2Mouse". You'd then program your hardware to send keystrokes (possibly via button programming in FSUIPC), and have Key2Muse operate the mouse movement and mouse clicks for you. The only EFIS controls you can assign directly are Decrease decision height Increase decision height Kohlsman dec Kohlsman inc (these are for QNH setting) Barometric std pressure This is because these are all assignable FS controls. All of the other facilities are local to the code supporting the panel, and they are not even amenable to the recent Mouse Macro facilities added to FSUIPC. Regards Pete Regards Pete

LOL! I didn't think it was a competition! ;-) I'll make the same changes in FSUIPC4, in case you ever move to FSX! Pete

I think you simply log into your account and retrieve your key. thousands of others do this, no problem. All you have to do as far as I know is log into your SimMarket account, then navigate to your purchases and you will see your Key. It is all handled automatically in SimMarket and I've not known it to go wrong. If you still cannot do this (explain why, perhaps?), send me all the details privately, to petedowson@btconnect.com, and I'll see what I can do. I personally don't have anything to do with that side of things, I just do development and support. Regards Pete

Two things you have wrong there: 1. You do not buy a specific version of FSUIPC -- you buy either FSUIPC3 or FSUIPC4. Version 3.70 is very very old and completely unsupported. Do not use it. Download the current version, which is 3.81 (soon to be replaced by 3.82). 2. You never ever have to buy it again. When you buy either FSUIPC3 or FSUIPC4, you can use it for your own purposes on any computer you like anywhere in the world. Find all copies of FSUIPC on your PC and delete them all. Then go and download the current version. Pete

I don't see how anything has changed there As I said, all I changed was: (omitted), // -33.5 height of Geoid above WGS84 ellipsoid. Can't provide this. Should I provide 0.0? (omitted), // M metres -- maybe I'll try filling this in too (omitted), // 0.0 time in secs since last DGPS update. Could try 0.0 (omitted) // 0000 DGPS station ID number. Could try 0000 Weird -- it must be XCSoar which is messing up the altitude then as both versions will certainly be giving the same value. Maybe that "Geoid" value (the "33.5 metres" in your sample earlier) is being assumed as an altitude difference by XCSoar unless I actually fill a 0.0 in? That is stupid of it -- it should read an empty field as the same as a zero!! 33.5 metres = 110 feet, 867 + 110 = 977 :roll: :roll: :roll: No other moving map program I have tried gets this wrong. You should report the bug to the XCSoar folks. Of course the DLL knows the heading!!! It's the TRACK which is non-existent until it moves. If you want the HEADING (where the nose is pointing) you need your XCSoar to read and use a different sentence -- the VTG sentence provides Mag Heading as well as Track and Ground Speed. The RMA and RMC only contain track. This is by NMEA standards. BTW GPS's have no idea of your heading at all, ever. They measure direction from your movement -- i.e. track. heading needs a compass reading locally. It must get it wrong if it is providing Track when you aren't moving! There's no such thing then. Or maybe you should provide XCSoar with the VTG sentence -- maybe it uses Heading when there's no Track. Pete

Is that with the released version of GSPout, or the special one I gave you? If the latter could you please try the "official" one, as if that works I don't need to make a new release nor update the version of GPSout built into FSUIPC4. Thanks, Pete

Thanks. I browsed the site whilst I was there, and it seemed to show that a free program "Pocket FMS" would run on my HP Ipaq Pocket PC. So I went to PocketFMS, downloaded it (though it doesn't appear to be free after a 30-day evaluation. there's then an annual payment due!). But apart from getting it installed okay on the PC I can't get anywhere with it. I have no ActiveSync running (I closed it down when I last tried to talk to my Ipaq as a serial device) so I asked PocketFMS to prepare an SD card, which it did. Apparently, when inserting this into the Pocket PC is should run something to get some data, which allows PocketFMS, back on the PC again, to enable the whole shebang on the Pocket PC. Pah! Nothing would run from that CD. It is supposed to autorun something, which it doesn't. Then everything I tried to run manually simply said "PocketFMS is not a valid PocketPC application". I seem to remember I tried this way back when I first got the iPaq, and had to give up then. Maybe PocketFMS was free then, too Regards Pete

No, not at present. Only as described. Just one parameter of each of the three types, each with up to 8 strings listed of up to 16 characters each. e.g. SingleLine="string1","another","even more","et cetera" It's a bit of an emergency measure to deal with a newer version of FDC which for some reason add New Line characters to the ends of its progress messages and so gets them routed to the multiline window, destroying things like radar Contact's menus. I'm discussing possible better measures with RC's author at present -- this was an interim thing and added quite crudely. No Windows "profile" type INI file is ever allowed multiple lines with the same parameter name in the same section, it's the way the profile API works. This is why many INI and CFG files you see use ".1", .2" etc postfixes on the names, as in FS's Gauge lists in the Panel.CFG files. What is your application for this? Oh, are you the Sandy I did it for> Pete

Not seen that place before. There are in fact two examples with the wrong setting "Sentence". Someone should get them corrected. Pete

No. FSUIPC.DLL is the code, and it is code-signed against viruses and tampering. It never changes except when you update to a new version. All your settings are saved in FSUIPC.INI. Your registration is saved in FSUIPC.KEY. Any mouse macro files are saved in your own named .MCRO file. No. You want to save the INI, KEY and MCRO files. You can (and should) always get the latest copy of FSUIPC.DLL from the Schiratti site or here, in the "Other Downloads" announcement above. Pete

How do you "search for a problem"? You don't need to look for one in any case, you already have one. There is simply no data arriving at the Client from the Server. So it times out and reconnects. The Client log shows this, and the Server log shows that every single time it tries to send something it is totally blocked. This must be some sort of firewall or other protection system preventing the transfer. You need to find out what and either disable it or provide the appropriate permissions. Regards Pete

There's your problem. It is not and never has been "Sentence=" but "Sentences=". You are merely getting the default set, which consists only of RMC. Where did you get "Sentence" from? And, sorry, but I should have noticed that when you posted it before. I'd just assumed you'd just edited the supplied INI, not written your own with errors. :-( The file doesn't have to be "messy". Just delete all the duplicated and commented-out lines. Pete

Because the axis assignments facility was designed to allow folks to assign to all sorts of FS controls which take parameters (all axis types and lots of "SET" types which also can take an analogue or other value), all of those which cannot be assigned in FS itself. This is the "axis" equivalent, if you like, of the Buttons and Keys assignments, where the range of FS controls which can be assigned to far exceeds those provided in FS's own assignments. The options to go direct to the FSUIPC calibrations, bypassing FS altogether, was added as a more efficient alternative, but it only usable for those few axis controls for which FSUIPC calibration is provided. As an extra facility is has obviously come into much more use, of late, especially with FSX the way it is, but this was never the main purpose of the axis assignments facilities -- it was, as I say, for access to all possible axis controls, plus, of course, the possibility of different assignment for different aircraft. As such, really, when it was designed, I only thought it would be a minority of users using it -- cockpit builders or folks with sets of, say, helicopter controls on one side and aircraft controls on another, wanting to swap easily between them. I'd assumed folks simply wanting to use FSUIPC's calibration facilities would continue to use normal FS assignments -- those facilities have been in FSUIPC for many years whereas the axis assignments facilities are quite recent, relatively speaking. Regards, Pete

I still don't understand. The condition lever is operated by the mixture axis anyway, so there's no difference. You did actually say that you used FSUIPC to assign to the "Axis Mixture Set" control, which is exactly the control FS uses for its assigned mixture axisit would/should have worked exactly as it was before you started -- as I said, no difference. Maybe you had the sensitivity set low in FS assignments. FS does have a habit of doing that with the mixture axis for some unknown reason. Always double-check all sensitivity and null zone sliders (max and min respectively is desired). By using FSUIPC's assignments you simply by-passed those sliders, that's all. Regards Pete

Hmmm. Interesting idea! ;-) Good. So all set for some good flying now, eh? Regards Pete

Okay. I added values for those 4 fields. Get the updated DLL from here: http://fsuipc.simflight.com/beta/GPSout2607.zip Let me know, please. Pete

Since I didn't get a reply yet, I thought I'd just compare what I have programmed to provide in GGA with whay you see from your other device: $GPGGA,222401.813,4159.3274,N,09138.5490,W,1,03,26.5,203.1,M,-33.5,M,0.0,0000*77 With the 6 decimal position optio off I provide $GPGGA, nnnnnn.nn, // 222401.813 3 decimal places for seconds instead of 2? Didn't matter on RMC, so shouldn't here! nnnn.nnnn,N // 4159.3274,N same, ok nnnnn.nnnn,W // 09138.5490,W same, ok 1, // 1 same, ok 05, // 03, shouldn't matter (= number of satellites received) 0.0, // 26.5 horizontal dilution. 0.0 should be fine, can't invent a figure. n.n, // 203.1 altitude, okay, same, to 1 decimal place M, // M metres, same (omitted), // -33.5 height of Geoid above WGS84 ellipsoid. Can't provide this. Should I provide 0.0? (omitted), // M metres -- maybe I'll try filling this in too (omitted), // 0.0 time in secs since last DGPS update. Could try 0.0 (omitted) // 0000 DGPS station ID number. Could try 0000 If you like I'll supply a GPSout with those changes in BLUE above. I can't see what else I could possible do. I think your XCSoar program is being fussy beyond what the NMEA 0183 spec calls for. Regards Pete

Check FSUIPC 4.295 (or 3.814), now with REV axes treated appropriately. Seems okay here with two sets of toe brakes. Note that the change-over between one set and another can only occur when a new value is received -- a change over the "delta" so that jitter doesn't play a part. So if one pilot is depressing the brakes and then the other one fully depresses them and then releases them, they are released -- even though the first guy still holds them depressed. He'd have to wiggle them a bit to take control. I know this isn't realistic, but it is really about the best I can do without a lot more fiddling about in the code, and i really don't want to risk the inevitably unreliability this will cause in the short term. Regards Pete

The conflicts with LevelD were present in 3.75 and removed later. There was always an option which fixed it in any case, but it wasn't realised it was needed. I simply reversed the option so it is defaulted. The current (supported) version of FSUIPC is fully compatible with LevelD whilst 3.75 might not be (depending on parameters). There's never ever been a need to redo any setups when upgrading FSUIPC versions. Not ever. Pete

I assume the PSS 777 implements its own autopilot and doesn't use the FS values, then? There is no such thing as "compatible" or "incompatible" in that situation. You might as well say the PSS777 is not compatible with FS. Since FSUIPC interfaces to FS, it allows all sorts of things to be read/written in FS. If the PSS 777 does its own private thing with the autopilot, not using the FS values, there is nothing FSUIPC can do -- that is private to PSS. For control, maybe using the Mouse Macro facilities, if they work on the PSS cockpit. Check the documentation -- the mouse macro system works well on the PMDG cockpits. The only other possibility is to use any keypress shortcuts which might be defined for the PSS 777. See their documentation to see if that is possible. You are writing an interface program using offsets? The MCP isn't seen as a set of buttons and knobs? For reading the values from a private A/P implementation, whether PMDG or PSS, you'd need to get information from the Makers. I know PMDG sell an SDK (very expensive I think) for hardware to interface to their cockpits, but I don't know about PSS. You'd have to ask them. Regards Pete

My own freeware program "MakeRunways" does this too. It can provide the latitude and longitude of the runway centre and each threshold. Yes, I use this information. for KSEA 34R it is N47 25.89' W122 18.48' Where on 34R? The threshold, in the centre of the runway? It is important to say WHERE on the runway. They are quite long and often wide, you know. N47 25.89 is, in degrees, +47.4315 W122 18.48 is, in degrees, -122.3080 These are, to the accuracy of the Shift+Z display, IDENTICAL to the values you got from FSUIPC: ongitude read out by FSUIPC: -122,307998333126 latitude read out by FSUIPC: 47,4314848334006 The only difference is that the FSUIPC values are much, much more accurate. To the inch. They will be identical -- though the readout from FSUIPC will be much more accurate (to a few inches in fact). Both the Shift+Z readout and the FSUIPC readout use exactly the same data. To convert Degrees and minutes to just decimal Degrees just divide the minutes value by 60 to get the fraction (there are 60 minutes in each degree, as you must know). So 47 25.89 = 47 + (25.89/60) = 47.4315 and 122 18.48 = 122 + (18.48/60) = 122.3080 (then negated as FS treats West as -ve, East as +ve). Pete

Well, it just must be due to the REV setting. I've worked out a way of detecting that where I do the arbitration and will upload a test version for you to try, maybe later today -- otherwise tomorrow. Because there's no arbitration, so no inputs are discarded in favour of others. How many of the other axes, dual-assigned, are REVersed, though? Regards Pete

Well, the button must be programmed for that somewhere. It's just a matter of looking. If you want the windows sorted by Aircraft I think you can do all the work in the PANELS.CFG file for that aircraft -- not precise placement, but certainly general positioning (I think they divide the screen into 9 sectors and assign according to those). I really can't see any easy way that FSUIPC would be able to do it automatcally. Each aircraft has its own set of windows defined, and many of them may not be actually visible/extant at any one time. It can ennumerate all the windows in the system (being a child of FS isn't enough), and those which belong to FS can be identified (they are class "FS98CHILD" or "FS98FLOAT") but these can include all sorts of "Windows" which aren't necessarily meant to be part of the cockpit (though maybe those wouldn't matter). It would get pretty messy, though, not something I would want FSUIPC to get involved in. Maybe this would be a suitable subject for a separate add-on -- even one outside of FS could do it by ennumerating all the FS windows. Perhaps you should suggest it to one of the other add-on producers like Luciano Napolitano? Regards Pete