Pete Dowson

I don't know "touchBuddy". What is your input (control) for this? It may be that the Level D software is reading the keyboard at a lower level than that provided by your TouchBuddy software. Not "mapping", just the different method used in LevelD to read the keyboard. Not to convert a keypress into another keypress. FSUIPC offers nothing like that. It can convert keypresses into FS control actions, but I doubt that any of those will operate the LevelD autopilot. The joystick button assignment facilities allow keypress assignments -- whether the latter would work with Level D I don't know, and it wouldn't help in any case unless your TouchBuddy software can provide button presses ... ... actually, I say that, but there is ONE possibility. It is a bit complicated though. If the TouchBuddy keypresses are seen by FSUIPC (which is another question), then you could assign them to internal FSUIPC controls (for offset byte bit set, clear or toggle) to "press" virtual buttons (FSUIPC offers 288 virtual buttons). Then if that works you could assign the virtual button press to a keypress to operate the Level D autopilot -- assuming of course that the Level D software accepted FSUIPC's keypresses, which is another big question. That's a lot of "ifs". There is one other possibility. If the LevelD autopilot is amenable to the recent Mouse Macro facilities in FSUIPC, and if FSUIPC does see your TouchBuddy keypresses, then you could use that facility (mouse macros). That's two more ifs. Not having either TouchBuddy of the LevelD aircraft I am afraid I can't really help further, unless you need more explanation of any of the above ideas to try them? Regards Pete

Thanks for the files. Your registration is dated 16th June 2008. Have you not used it for the last two or three weeks? Can you check the System date of your PC please? The files you sent are dated 04/02/2007 (4th February 2007). This is BEFORE 16th June 2008, which would render the registration invalid. Things aren't valid before they are issued! Regards Pete

Sounds like you have an invalid registration. Run it again, close FS, ZIP up the FSUIPC.LOG and FSUIPC.KEY files and send them to me at petedowson@btconnect.com. I'll check them for you. Pete

That may explain buttons doing the wrong things when you press them, but it certainly doesn't explain your problems with the axes misbehaving. Remember? You said this: Now throttle, pitch trim, rudder and ailerons are all axis controls. They can be influenced by buttons too, if so assigned, but only when you press them. You certainly shouldn't be getting anything happeining on its own. [That said, there was a fault on some early Saitek yoke systems which did cause random spurious button presses]. Normally it won't do this UNLESS you unplug the controls and plug them back in again -- FS will see them as new controls and try to assign them for you according to the information it gets from the units and from the data files it has on disk. Also check that you haven't got Windows set to do any power saving on your USB ports. If that's on it may be powering off the joysticks so they look like new connections when you start using them.. They certainly shouldn't be random, but according to what it knows about the controls and what it is told in its files. Check out the "Devices.CFG" file in your main FS folder. It lists the default assignments for each recognised joystick -- either by generic type, or by its actual name. I doubt whether it has Saitek stuff in there, so it may pick the closest generic set it can find. Regards Pete

That sounds like a lot more than jitter! Sounds definitely as if you've got the axes assigned twice via different routes. Try disabling the joysticks completely in FS. If the problem stops but you still have some movement it will be obvious you've gone and assigned them in FSUIPC and simply forgotten. Alternatively delete your FSUIPC INI file and start again. Easily the easiest way to start again when you make a mess of things. ;-) It isn't. It is dead easy. Too easy. It is evidently so easy you are probably forgetting what you've done! Pete

Well if the axes behave smoothly, they must operate smoothly. Where's this jitter (is it jitter?) coming from? If you are simply tending to over-control, if you calibrate in FSUIPc you can use the "slopes2 option to change the rsponse -- flatten the curve near the centre so that is is less sensitive. You also probably want to add that "STICK_SENSITIVITY_MODE=0" line to the [CONTROLS] section of your FS CFG file, as suggested in the FSUIPC user guide. In my opinion that always helps, no matter how you calibrate. Axes and buttons aren't related. What a complicated story! Sorry, I've no idea how all those changes managed to muck things up. That could only be the case if you have axes assigned in both places. Just delete anyy [Axes...] sections in the FSUIPC INI file -- that will make sure you've none assigned in FSUIPC. well I really don't know the saitek units. If they look like standard joysticks then no doubt Windows would pick them up via one of its default joystick drivers. But i wouldn't guarantee it. normally you need specific drivers for each specific hardware add-on. Yes, they can do. Bt doesn't Active Sky also provide limits? Regards Pete

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