Pete Dowson

Okay, so it is definitely either your stick or its drivers. Try without FF, maybe that is interfering. Regards, Pete

Ah, I see from your original message that you said "If I change aircraft I get it back....sometimes". That actually sounds suspiciously like ot might be something going on with the flight model. Does this happen with all aircraft? Can you look to see if you are actually getting full aileron and elevator movements (use spot view)? Pete

The axis certainly seems to be calibrated very lopsidedly in Windows. Re-calibrate there. FSUIPC doesn't allow reversed axes -- you can reverse them in FS I think. In FSUIPC a negative number is ALWAYS less than a poitive one. Have you yet tried with FF turned off? Otherwise I'm sorry, I can't think of anything else to try. Does it stay like that till you reload FS, or power the PC off/on, or what? When does it come back to normal? Pete

All I can offer is the FSUIPC SDK -- get it from http://www.schiratti.com/dowson. You can read all sorts of velocity and acceleration information (check offsets 3060-30B8 and 3178-31D0. Which of those you use and what you do with them is another matter though. Sorry, I don't know. And the hardware to convert signals from, say, a parallel or serial or USB connection into 3 amp currents is completely not my area of expertise -- I'd be looking at some of the harware add-on sites for such things. I expect EPIC do them, as I know R&R have implemented at least one motion platform. Regards, Pete

So it's okay one minute, unresponsive the next? Sounds like a problem either with the joystick itself or its driver, or some interference with the Force Feedback. I think you need to go through a process of elimination to see what it might be. Have you another, maybe simpler, joystick to try? Can you try without the FF? I'm not really an expert in joystick berhaviour I'm afraid. If no one else jumps in here you may need to find a more hardware-oriented forum. In other words the actual INPUT range goes from -16000 or something up to +10000, no further? That sounds like it isn't calibrated very well in Windows to start with. You should have roughly equal amounts either side of the nominal "centre" (0). -10000 to +10000 is kay. Even -100 to +100 is okay. But not -16000 to +10000. You'll get much coarser behaviour to one side compared to the other. See if you can recalibrate in Windows Game Controllers to get a more even result. Regards, Pete

I don't think anything you can do in FSUIPC will turn a sluggish joystick into a fast one. Is it the same with force feedback disabled, wherever you can do that? Check the FS sensitivities -- Options-Controls-Sensitivities. Set them higher. If all axes all read 16383 for output all the time then they won't be at all usable. In that case you have set them up wrong in FSUIPC. Press the button marked "Reset" for each axis so that FSUIPC doesn't do anything, then try them in FS. If you want to use FSUIPC to set more precise end zones and centering, please follow the instructions very carefully, step by step. The "bing" noise indicates as impossible setting you are trying to make. The calibrated numbers to the right of the INPUT and OUTPUT values need to go from lowest (most negative in this case) on the left, to most positive on the right. The two centre ones must be in between. FSUIPC won't allow you to set any other order. The gap between the two centre values controls how much central null zone you have, for a good centre. Regards, Pete

No, the timing you are referring to was the additional smoothing to stop any longer term "jitter" than the filter I had already incorporated (which was for less amplitude and only 150 mSec). Personally I saw no need for it, but someone else did and was happy with the result as far as I know. The new facility I put in is a "Throttle Sync" control as documented in the PFC DLL user guide. To quote the explanation there: "This toggles a facility to synchronise the settings of throttle, propeller pitch and mixture on all engines. Basically, when enabled, it uses the Engine 1 values for all the engines and ignores the inputs from the other axes. When toggled off, the current settings for the other axes are re-instated. This is not related to the “Prop Sync” switch fitted to some aircraft." To use it simple assign it to a button. The latter part seems to argue against the former part of this statement. I am at a loss to understand what is happening. How do you know it is due to the throttle quadrant then, or my presumed bad programming? Have you any other such controls to compare it with or to exonerate the FS programming or specific aircraft? When you say "always", you mean with all versions of FS, and with all connected controls? I'm getting a bit confused now, I'm afraid. There must be some way of determining WHAT it is that is causing the wobbles. You say the controls, graphically, seem to move smoothly and in concert, no apparent jitter there. Obviously the graphics may not have adequate resolution (though with only 40 steps I should have thought they would), but what about the instruments? Do they show any irregularity that could cause this? I'm not familiar with turboprop instrumentation so I can't tell you what to look for. The other thing you can do is use the Monitoring in FSUIPC to watch the prop and throttle values actually being used in FS. Go to FSUIPC options (Alt M F) select Logging page. On the right enter these: Offset 088C, Type S16 (this is Throttle 1) Offset 0924, Type S16 (Throttle 2) Offset 088E, Type S16 (Prop pitch 1) Offset 0926, Type S16 (Prop pitch 2) then check the "Adv Display" selection below and OK exit. You will get a window on screen where these values will be constantly displayed and updated as they change. See what happens, looks for too much fluttering, or differences where they should be similar. You can also see the Mixture values (offsets 0890 and 0928) but you can only see 4 values at a time. If there are always disparities between engines 1 and 2 when the levers appear to be together, this can mostly be corrected by better calibration in the PFC joysticks section. However, it is unlikely to get rid of them altogether. Maybe there are some points along the axes where the "linearity" is definitely different. It is this sort of thing where I'd hope to apply some of what has been suggested here earlier, to improve matters. However, I feel that the only sure way to get two or more levers reading exactly the same is to use the Sync facility I've provided for just that purpose. BTW how is it really achieved in the real aircraft? If they don't have some "sync" override, how can every lever guarantee the same setting at every equivalent position? It doesn't seem feasible. Wouldn't you even things up by checking the instruments, nudging one lever up, another down, to achieve parity? Or presumably do it all be feel when experienced enough? Not by simply lining up the levers, surely? (Unless it is fly-by-wire, but even then). Regards, Pete

Considering the step seems to be 3 out of the maximum (never achieved) range of 127, the resolution is more like 40 steps or a bit less than 6 bits. However, as far as I can see, this order of resolution is quite normal with the standard sort of pot and AtoD chippery in use. I just checked the throttle on a Microsoft Sidewider USB and its smallest increment (at FS's maximum sensitivity) is 542 out of a range of -16193 to +16192. That's 60 unique positions -- the benefit of optical decoders I think -- but that's still less than 7 bit. At the moment the only way to get that is to enable my PFC DLL logging. This would contain lots of stuff you wouldn't want, so need a lot of editing. And it would basically be a log of received (optionally decoded) data sent by the unit to the PC when IT wants to -- that's a regular sample every second, approximately, and only changes in values in-between. I can supply something with all that if you thought it was any use, but ... ... After your suggestions earlier I have been thinking of how to get regular 18 Hz readings so that I can apply your filtering. I've had a look at my code, and it is a lot more coding than I had been prepared for, but I have plans for how to do it. It isn't a quick change, though. I have to separate the code reading the data and that scaling it and acting on it -- storing the former and sampling it on a timer (actually an FS timer tick chain call) before filtering it, scaling it and acting on it. I will only apply this to throttle, prop pitch and mixture inputs. For aileron, elevator, rudder, spoiler, flaps and brakes I think it would be unnecessary and possibly give rise to delays and hence over control (in the main flght controls that is). But all of throttle, prop and mixture controls will be potentialy contributing to asymmetric thrust. This is why the "throttle sync" facility I added in version 1.80 applies to all three sets of axes. I'm now wonering if the new compalinant is actually using any of the additionas I made. Let me know what you want to see out of all this. I can't promise anything quick, mind. Regards, Pete

I am rather bemused by this sudden "attack". There was a long discussion on this several months ago which I thought was resolved. Have you looked through the other threads on this? Which PFC.DLL version are you using? The more recent versions have additional "filtering" in (quite crude, I admit) which can be adjusted for longer-term smoothing, and also include a Throttle Sync facility which operates also on other axes. That facility has been working well since version 1.80. The current version is 1.83. Have you used Throttle Sync in any of these? Since all this, back in October last year, I have heard no more until now. I don't know if that is because all the complainants have been on an extended holiday, or because whatever problems there were have gone away. Coming out of the blue, in attack mode like this, doesn't help anyone at all. If you would like to be more specific, in particular about what you are using, what options you have tried, and what still remains to be done, I am here to listen and to try to figure it out. The PFC throttles are the smoothest and most flexible I have used, and believe me I have been through many different sets (some of which are still in my junk box upstairs). For most every purpose they perform impeccably. If there is a specific problem in certain applications let's look at itbut I need information, not rants. As you'll see from the recent messages I now have some suggestions for a more "scientific" approach to flitering and smoothing, and evening-out differences between axes. I may well try these out. Perhaps you would like to volunteer as one of the test sites if I do? But whether this is useful depends upon what appears to be the causes of your problem. That is something I don't know at all at present. Regards, Pete

Oh, yes, I have records of all those, don't worry. They can write to me (privately) with their details. But they are very much in the minority of course. :wink: There are also those who got them from Enrico Schiratti, mostly Porject Magenta customers of course, and they should ask him. And, since late December, there will also be customers of InterCraft of Tokyo, Japan, who do a Japanese translation of the documentation and sell both FSUIPC and WideFS there. In each case, apart from the purchasers, the details and access keys are only known to the specific suppliers. I hope this is clear. There is no central database and I don't hold keys I didn't issue personally. Regards, Pete

Sorry, I don't deal with any of that. I do programming and technical support. Registration is dealt with by the retailers -- SimMarket mostly. If you bought it from SimMarket then I think you can get your key by going to http://www.simmarket.com and logging in to your account there. Otherwise contact their Customer Services. When you do get a copy, don't forget you need to enter the EXACT same name and email details as you used originally. I'd also advise either printing out the details and keeping it safe (much like anything else you might purchase), or backing up the FSUIPC.KEY file (on separate media to your HDD) after you have successfully re-registered. Regards, Pete

That's because it is called FSUIPC.LOG. If will be in the same folder as FSUIPC -- in other words, in your FS Modules folder. There will be 4 files there with FSUIPC as a name: The DLL itself, which is the program The INI file which vcontains all of its configuration settings The KEY file which contains your key details, and also those of any registered programs The LOG file, in which FSUIPC saves any details needed to answer problems. I don't know about a Beta version of Squawkbox, but certainly there's a Freeware key in the list for Squawkbox 2.3. That should be all you need for FS2002. For SB2004 I think you also need something called SBRelay in order to convert the multiplayer protocols. But this is not my subject so I won't confuse things further. No. COM1 is supported directly by FS itself. It doesn't need any additional modules. I don't know if that panel uses FSUIPC for anything else. You'd need to check the LOG file. Regards, Pete

That means you haven't registered FSUIPC yourself, and you are using a program which doesn't provide an access key automatically. If you do as the message says and look in the FSUIPC LOG file (in the Modules folder) there will be entries there which tell you the name of the culprit program. Well, part of that may be due to the program you are using not being able to talk to FSUIPC, but I thought the visual image part was dealt with by the multiplayer protocol. Perhaps there's a mixture of things going on there. :? I thought you said you had read the documentation? :wink: If you want to register FSUIPC in order to unlock all of its facilities you have to go to SimMarket and purchase the access key. All the details are there, within the first few pages of the User Guide. If all you want to do is run some freeware programs, then take a look at the list of Freeware Keys for applications provided in a sticky message near the top of this forum. Regards, Pete

Actually, after further thought, this might well be useful -- with something like e=6, as you say. I don't think necessarily that the levers will line up, but it make it easier for the pilot to get a constant symmetric thrust, as the lever positioning will be a little less critical. Of course there's more code that this, as I have to be able to cope with 2, 3 and 4 engines and throttle levers. Thanks again, Pete

I can't say I understand much of that. However, there is one problem, but probably easily dealt with. The PFC device provides values only once a second, unless they change. So there is no regular sampling from the PC -- the firmware is doing the sampling and all I see are the results. In order to "simulate" a sample rate of, say, 18.2Hz I would need to assume the previous last values seen, even up to a second earlier. Does this change your proposals? Presumably not. Okay, I can try this, though proving it's effectiveness will be difficult as very few folks seem to be having problems, and I am not one of them. Thanks! 2 lines of code per channel. That's not complicated, is it ? And it doesn't use branching, which is nice for your Pentium's pipeline. An optimizing C-compiler will also allow simultaneous execution of the addition and the multiplication on the FPU. Ah .... now this is a different subject. You seem to be assuming that the two separate potentiometers are identical in everything. I don't think they go to such expense. This is not a noise difference, it is a difference in the characteristics and linearity of two separate components. I don't see how anyone can expect 100% agreement -- even in the real aircraft I doubt it occurs between throttles due to slight differences in engine performance, in the connecting wires, leads, pulleys, whatever. Regards, Pete

Originally it was called RW transmit on/off, or similar , but since it also applies to AVC that seemed unfair, so it is now called PTT transmit on/off (RW or AVC). If others come along I shall probably drop the parenthesised part altogether. The PTT is "push to talk". Sorry for the confusion. So, look in the "p's" and you'll find it. Regards, Pete

Well the generic M magneto selector assignment doesn't actually operate the mags or starter switches, it only selects them. The + or - keys then turn the switch. For props the starting needs the start position to be held against a spring, so you hold the + key down till the engine starts. Jet starting is similar but I think it uses a different selector. There are hundreds of FS controls and I do not know exactly what they all do. I suspect some do nothing and are just left-overs from an earlier version, or possible new facilities which never actually made it into the code. Scrolling through the list in FSUIPC, looking for likely candidates to try, is not so easy and you can miss things. For each version of FS since FS98 I have published lists of the controls FS declares (I won't say supports for the above reasons. :) ). I used to try to explain what each one did and how to use it, where I knew, but I gave that up as an almost impossible task with all the other things I have to do. But the list, just as a bare list, may be useful to you in any case -- http://www.schiratti.com/dowson. Don't press them together. Press M first to select the Mags. I don't think the Dash7 has any does it? For jets I think you select the jet starter with a J. The + and - keys operate on the last thing selected, which could be almost anything -- by default when you load up, the view is selected, hence the Zoom operation. Regards, Pete

That was the algorithm actually implemented, and over a year ago now. It was originally specifically aimed at curing severe jitter on a user's system in Myanmar where the power supply was the jittery component. All I did more recently (last October/November) was add an extra layer and allow the time value to be set by the user -- one or two users had much longer term "drift" (a better term than jitter for something not quick! :) ). Yes, but the circuitry on the PFC controller board, and indeed its firmware, is supposed to deal with that. Here I hardly ever experience any jitter at all -- there are some specific positions of the levers which are, shall we say, "ambiguous" -- the value it wants to provide is half way between two of its measurements and it flutters a little between the two. That is the phenomenon my "filter" was designed to fix, and it works fine here. Values from PFC axes (provided by the PFC firmware) can only extend from 0 to 127, but that range is never fully achieved and it usually provides something like 10 to 110, for example. The "granularity" appears to be 3, so in fact there are only between 30 and 40 distinct positions measurable. I think your proposals need to go to PFC? Or are you saying implement a digital filter in my FS module? I would be a little concerned over the effects on FS performance if there were too much processing going on. After all, FS wants to use the processor too from time to time, and with up to 15 PFC axes all throwing values at me all the time I need to make their processing as fast as possible. Thanks. I'd like to understand this a little more. Like what are the values a2, a1 and a0 -- are they derived experimentally or is there some way of determining what they should be? And you say 'e' depends on the resolution -- is this my "3" for PFC axes? Oh, and isn't there some sort of elapsed time involved here someplace, or are these only ever concerned with the three most recent values read? If there's no time factor then I can see the long term "jitter" experienced by one of my correspondents still remaining. Thanks for your ideas. I am struggling a bit to see the need for such added complexity and programming within the FS process, and, in fact, don't have any jitter problems in any case with any of my PFC gear. I don't understand why some folks do (excepting the site in Myanmar with dreadful mains power), and was quite pleased that the updates I did provide late last year seems to answer their questions. However, I am always seeking to improve things, so if you could just elaborate on the simpler parts of your proposals I'd be interested to try them. Thank you, Regards, Pete

Yes, and I think the freeware arrestor cables should work -- it will unless it is deliberabately set to check version numbers. The reason that might be done is that I think it is now part of a commercial product. Ah .. that's the one! And I think it is advertised for both FS2002 and FS2004, is it not? Regards, Pete

No problem. Thanks for letting us know! Regards, Pete

It should work okay, provided it doesn't check for FS version number or FSUIPC version number. Certainly the things it does in FS2002 can also be done in FS2004. Maybe there's someone else here using it who can chip in? Regards, Pete

Are you sure it was actually working with the unregistered FSUIPC, or was that an older version of FSUIPC (before 3.00?). Which version of FS is this with? Take a look at the FSUIPC Log, see if it says anything about FSMetar. It sounds like either FSMetar is getting data from FS it doesn't understand, or it is now working "better" but the downloads it is getting are causing it grief. Regards, Pete

Shouting "start" through a mike doesn't sound so authentic :D . You should be using a spring-loaded partly-latching toggle switch for the starter, and for airliners another (latching) switch for the fuel. Even with a co-pilot you'd probably do one or the other. You could operate the starter yourself and shout out "fuel on engine one" when the N2% figure gets to the right value, so your "buddy" co-pilot does that bit. :wink: Regards, Pete

Ah, rightthanks. I still get so many messages I forget which is what! What about using the Engine Autostart keypress as I suggested? I think that's about as good as you'll get by voice if the program doesn't have separate press and release facilities. Regards Pete

You seem to have started a new thread, so it is a bit difficult to refer back. By "on" you mean "pressed" I assume? That is done by the software sending a "KEYDOWN" and holding it down until a "KEYUP" is sent. Unless Voice Buddy provides a method of interpreting a command as meaning do the KEYDOWN part only, and a way of giving it a KEYUP, then what you ask is just not possible. There is a "cheat" control provided by FS -- "Engine Autostart", assigned by default to CTRL+E. That will work with a normal voice-to-keypress setting. I think that's your only option. Regards, Pete